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

[Neil Williams]

tag 800910 - patch
tag 800910 + moreinfo
thanks

On Sun, 04 Oct 2015 23:19:15 +0200
Christian Seiler <christian at iwakd.de> wrote:

> Package: vmdebootstrap
> Version: 0.11-1
> Severity: normal
> Tags: patch upstream
> 
> Dear Maintainers,
> 
> 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.

Put it this way, if you reversed the sequence, your tests could be
rendered invalid. 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. 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).

>  - 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.

> 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)

It's not about making changes in vmdebootstrap to change how the system
works after a successfully built image has booted successfully.
Changing the init system is a specialised task, it's up to the test
harness to ensure that that kind of task actually works *and* that it
represents real systems. 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.

Rejecting the patch - there is no justification for vmdebootstrap to
carry a hardcoded init file in this way. There are enough problems with
the extlinux support doing it.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/vmdebootstrap-devel/attachments/20151005/e13d25e2/attachment-0002.sig>