opi2a back! init system variations?

[Holger Levsen]

Hey,

On Wed, Oct 05, 2016 at 08:42:17PM -0700, Vagrant Cascadian wrote:
> opi2a is back!

and now also been added back to the build network, with 3 new builder
jobs for a total of 60 (running on a total of 20 armhf boards).

 Not sure how to rearrange build jobs off the top of my

> For some reason, systemd wasn't starting consistantly, hanging on
> systemd-logind. Oddly, it worked well enough to still run build jobs,
> but restarting daemons and upgrading some packages would hang.
> 
> With some effort, I switched to sysvinit from a debug shell, finished
> some pending upgrades, of which were several systemd related. After the
> upgrade, it's been working consistantly using systemd ever since...  So
> I don't *really* know why it's working now... but it is. Best guess is
> it crashed in the middle of a upgrade (maybe disk full?) at some point
> and corrupted some relevent file(s)?

hehe, nice workaround!
 
> The whole ordeal did trigger a thought about adding init system
> variations to the builds... at least could do systemd and sysvinit at
> the moment without a *huge* amount of trouble, unless we're relying on
> some init-specific features for the builders?

well, we ideally want deterministic (and easy to spot) variations, to ease
debugging of unreproducible issues.

For the "easy to spot" part, the armhf network is sadly not really
suited. With our amd64+i386 nodes (due to their low number) it's trivial
to guarantee that exactly one of the two builds will be done on a host
with a variation, while the other build is not.

On our armhf nodes, it's impossible (for this kind of variation). 

On Fri, Oct 07, 2016 at 01:59:29PM -0400, Daniel Kahn Gillmor wrote:
> fwiw, i imagine that the choice of what is pid 1 (much like the choice
> of what is /bin/sh) could be a significant factor in some builds.  I'd
> be happy to see this variation added to the list of things we'd like to
> eventually test.

sadly I tend to agree and have added this to our TODO list…


-- 
cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161010/762536f1/attachment.sig>