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 <[email protected]> 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
From: Christian Seiler <[email protected]>
Date: Mon, 05 Oct 2015 13:05:26 +0200
Subject: [PATCH] Don't create /etc/inittab
If vmdebootstrap creates /etc/inittab (in case sysvinit is not in the
initial package list), don't create it - because if sysvinit-core is
installed afterwards, this will break the boot process.
See Debian Bug #800910
---
diff a/vmdebootstrap b/vmdebootstrap
--- a/vmdebootstrap
+++ b/vmdebootstrap
@@ -828,6 +828,10 @@ class VmDebootstrap(cliapp.Application):
serial_command = self.settings['serial-console-command']
logging.debug('adding getty to serial console')
inittab = os.path.join(rootdir, 'etc/inittab')
+ # Don't create inittab, this will break boots if sysvinit-core
+ # is installed later on, see Debian Bug #800910.
+ if not os.path.exists(inittab):
+ return
# to autologin, serial_command can contain '-a root'
with open(inittab, 'a') as f:
f.write('\nS0:23:respawn:%s\n' % serial_command)
