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

[Christian Seiler]

Control: tags -1 - moreinfo
Control: tags -1 + patch

Am 2015-10-05 09:19, schrieb Neil Williams:
> On Sun, 04 Oct 2015 23:19:15 +0200
> Christian Seiler <christian at iwakd.de> wrote:
>> while using vmdebootstrap to create VM images for the use with
>> autopkgtest, I've stumbled upon the following problem:
>>
>>  - I want to do integration testing, and part of that is to test the
>>    package with different init systems.
>
> The most deterministic way to do that is to have separate images and
> change the test harness to match. Otherwise, you are not actually
> testing with different *clean* init systems, you are testing one 
> clean
> and one potentially dirty init system which would have vestiges of 
> the
> old one left behind.

I would consider that a bug (at least of severity 'important') in the
respective init systems if purging one doesn't properly remove it.

Also note that if you look at the release notes of Jessie, they
recommend to use the same command I am using to install sysvinit for
those people that don't want systemd. That means that there's the
official position that it's good enough for our users to do so (and
on debian-user@ and other forums, all the people that were complaining
about that aspect were told that this does not make a difference), so I
don't see how for testing there should be any different metric here.

> Put it this way, if you reversed the sequence, your tests could be
> rendered invalid.

How so?

> The way you are describing this, you are not actually
> testing against sysvinit, you are testing against a system which has
> been converted from systemd to sysvinit. The primary issue a lot of
> people want tested is to run on a system which was sysvinit, stayed
> as sysvinit and never had systemd installed as init.

Well no, not necessarily. Some people do upgrade their systems, but
others want a fresh installation with sysvinit. For example, let's say
somebody who really doesn't like systemd wants to install a new
computer they bought - in addition to their old one that was upgraded.
As I said above, the Debian project currently recommends the same
command I am using to switch to sysvinit after installation (preseeding
the installer does the same thing). Note that the images autopkgtest
uses are not images where lots of stuff was configured. It's basically
vmdebootstrap + a little bit of customization, so that tests can be
automated. Notthing else. It's basically a fresh install before the
tests are run (which in turn install all the packages that are required
for runnnig those tests - in an overlay that is thrown away after the
test ends).

To repeat myself: if we say for normal users that after a _fresh_
installation it's fine to just purge systemd-sysv and install
sysvinit-core, then that should be fine for test cases too - and if
there happen to be some problems, I would consider those to be bugs.

I will readily conceed that if you have a system that was in use for
quite a while, configured all sorts of things, and _then_ you switch
init systems, that the situation might be different - but we are
talking about fresh installs here.

> To do that, a
> second image built for wheezy with the shim package and then upgraded
> to jessie would be the only viable candidate for a valid test of the
> kind of system that users are actually running. You should not rely 
> on
> the purge being 100% effective (or else have a third image which has
> been converted - once - and then upgraded).

I completely disagree here: if someting goes wrong during the
replacement of the init system, then the CI tests in my package would
be a perfect canary to detect that early on. Testing like this doesn't
only help to make sure my package keeps working on sysvinit systems, it
also implicitly tests whether switching init systems can have adverse
side effects.




That all said, to get to the meat of the matter:

>>  - The default test is run with the default init system, systemd. 
>> That
>>    works fine.
>>
>>  - For testing sysvinit, I run
>>      apt-get -y --purge --install sysvinit-core
>>    inside the VM, then reboot the VM.
>>
>>  - After that, I would run that test again with sysvinit as the init
>>    system.
>
> Whatever process calls the apt-get command also needs to make the
> changes necessary - similar to how the customisation support works.

Ok, so if you really don't want to do this the way I suggested, then I
will work around this during in my tests.

> It's outside the scope of vmdebootstrap -
> unless the presence of absence of the file has any implication for 
> how
> the image itself is first built or first booted. If that is not a
> problem, then this bug report can be closed.

On the other hand, I _would_ like to see vmdebootstrap not create
/etc/inittab if it doesn't exist, because that behavior is definitely
broken.

Currently, /etc/inittab consists of _just_ the serial console after
installing sysvinit-core. That means that the VM will not boot at all
after installing sysvinit-core on a freshly vmdebootstrap'd system. If
you don't append the serial console line to /etc/inittab unless it
exists, this will at least make the system bootable (albeit without
serial console), which is a much better outcome IMHO.

I've attached a patch that does this.

Thanks,
Christian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Dont-create-etc-inittab.patch
URL: <http://lists.alioth.debian.org/pipermail/vmdebootstrap-devel/attachments/20151005/bf7eedcf/attachment-0003.ksh>