[Vmdebootstrap-devel] Bug#800910: vmdebootstrap: creates /etc/inittab even if sysvinit is not installed

[Christian Seiler]

On 10/05/2015 02:31 AM, Antonio Terceiro wrote:
> On Sun, Oct 04, 2015 at 11:19:15PM +0200, Christian Seiler wrote:
>> I've attached a patch that does the following:
>>
>>  - if /etc/inittab exists, nothing changes
>>
>>  - if /etc/inittab doesn't exist, /etc/inittab.tail is created instead,
>>    and an init script is installed that will update /etc/inittab
>>    and append the /etc/inittab.tail file once it's booted under
>>    sysvinit for the first time (will do nothing under systemd)
>>
>> I've successfully tested it on my system.
> 
> I do not think vmdebootstrap should carry this kind of complexity. Is
> there a reason why you can't just test your package against different
> images, each with its own initial setup? If you do this, even your test
> code will be simpler and you don't need to do this dance.

Well, the problem is the way autopkgtest works: you don't get to define
your image. If you look at the spec [1], you add a file called
debian/tests/control, where you define which tests exist. Some tests
may require a higher isolation level, which you can specify as a
requirement. If you specify isolation-machine, your tests get started
in a VM. You don't control the image and its configuration, that's part
of the external testing environment. You can, however, control what's
going to be installed in that system (i.e. which packages should be
there).

Now I could of course work around this by manually fixing stuff inside
the test, but I don't think that's something I should do. The test only
wants to install the other init system (sysvinit-core in this case),
then reboot and perform the test itself. The test _can't_ really know
what kind of configuration the VM is supposed to have to properly talk
to the test environment, that's not the test's job.

On the other hand, the test environment can't know that a test installs
sysvinit-core inside the VM, so it can't really know that it needs to
do something to make it work.

The root cause I see here is that sysvinit doesn't support drop-ins
a la /etc/inittab.d/ (similar to /etc/network/interfaces.d/). If that
were the case, vmdebootstrap could simply just drop in a configuration
snippet there and it would just work. The problem here is that I just
don't see that anyone is really interested in improving sysvinit, so
I wouldn't get my hopes up that this might be a reality.

Whereas on the other hand vmdebootstrap advertises that it can make the
VM use a serial console. But then you suddenly install a widely used
package and on the next boot the serial console is just gone. (I'm
going to assume that you agree not to create the file if it doesn't
exist.) I don't think that's what people would expect. I would argue
that it's the responsibility of the program making configuration
changes to make sure they are robust. In an ideal world, that'd be
something like /etc/inittab.d/serial-console - but that doesn't work,
so we've got to work with what we've got.

Of course, alternatively vmdebootstrap could write out a full
/etc/inittab in case it doesn't exist yet. Then the problem would also
go away.

Btw. I had attached a wrong patch to the bug report (old version), I've
added the correct one for the record.

Regards,
Christian

[1] http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Defer-modification-of-etc-inittab-until-sysvinit-is-.patch
Type: text/x-diff
Size: 3138 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/vmdebootstrap-devel/attachments/20151005/06e09a5e/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/vmdebootstrap-devel/attachments/20151005/06e09a5e/attachment.sig>