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

Christian Seiler christian at iwakd.de
Mon Oct 5 16:38:44 UTC 2015


Am 2015-10-05 18:14, schrieb Neil Williams:
> On Mon, 05 Oct 2015 13:11:01 +0200
> Christian Seiler <christian at iwakd.de> wrote:
>> 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.
>
> Then why was there a need for a hardcoded replacement file in your
> original patch?

Because vmdebootstrap tries to write to sysvinit's configuration file
even if it's not installed. And since it doesn't exist, this causes
trouble. My hardcoded replacement was to make sure that the
configuration could be applied at a later point in time. Now you can
argue that it's not vmdebootstrap's job to do so, fine, but:

>> > 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.
>
> I don't see the breakage at this stage.

Creating an inittab with just the following contents (and nothing else)
is not breakage?

--------------------------------------------------------

S0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
--------------------------------------------------------

> It doesn't break systemd
> support and any change has to retain compatibility with wheezy.

Sure, and on Wheezy systems /etc/inttab exists, so os.patch.exists()
will return true, and inittab will be modified, so Wheezy continues
to work as before.

> Switching init system is a customisation step and not a direct
> operation for vmdebootstrap itself.

Sure. But vmdebootstrap should not create an incomplete, broken
conffile for a package that's not installed.

>> 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.
>
> ? It does boot - this is expressly how vmdebootstrap tests with 
> Wheezy.
> Maybe you are using the qemu -nographic option?

No. If you use vmdebootstrap to create a Jessie, Stretch or Sid VM,
tell it to create a serial console, boot that VM (with systemd), and
then run apt-get install sysvinit-core, the VM will not boot anymore,
because /etc/inittab will have the contents that I posted above. It's
one thing to say "look, switching init systems might require some
additional configuration for the new init system to activate all
required features in an environment", but I really do hope you agree
that apt-get install sysvinit-core on a Jessie/Stretch/sid system
should at *least* work as well as an uncustomized sysvinit, i.e.
bringing up all system services and starting a getty on tty1-6,
right? And not waiting for the user to enter a default runlevel,
because no defualt is configured, and not being configured to run
/etc/init.d/rc for runlevel changes, so no services get started, even
if you happen to enter a runlevel?

I'm not talking about Wheezy. I completely agree that Wheezy works
fine just as-is.

>> 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.
>
> Disabling the serial console like that makes this patch pointless. 
> The
> change for this issue can't simply disable existing support like 
> that.

It doesn't disable the serial console - it just doesn't configure the
serial console for sysvinit if sysvinit is not installed. On systemd
systems, the serial console is activated by the console=ttyS0 kernel
command line option automatically anyway, /etc/inittab doesn't play a
role at all.

So you have two scenarios with my latest patch:

Wheezy: /etc/inttab exists, will append the S0: line to it, serial
console works.

Jessie+: /etc/inittab doesn't exist after debootstrap, will not be
modified. systemd works anyway. Installing sysvinit-core later will not
enable the serial console on sysvinit, but at least the VM will boot.

Compare that to the current behavior:

Wheezy: works (see above)

Jessie+: /etc/inittab ONLY contains the serial console line (it's a
conffile). systemd works anyway (due to console=ttyS0 and not caring
about inittab) Installing sysvinit-core later will make the system
unbootable, because inittab will NOT contain the entries that it's
supposed to have but ONLY the serial console - which is useless,
because sysvinit will ask for the default runlevel at boot, because
no default runlevel is set in its config file.

> The refactoring of vmdebootstrap (in experimental but needs some 
> extra
> fixups) is looking to avoid assumptions within the codebase, so I 
> will
> look into /etc/inittab being related to sysvinit but that change must
> preserve Wheezy support, serial console support and not rely on extra
> hardcoded files.
>
> I don't see any need to change this in the master branch at this 
> stage,
> any fix for the assumed relationship between !systemd and 
> /etc/inittab
> and Wheezy (retaining all existing support) needs to go into the
> refactored branch which will likely form the basis of the next 
> unstable
> upload:
> 
> http://git.liw.fi/cgi-bin/cgit/cgit.cgi/vmdebootstrap/commit/?h=codehelp/modules

Ah, I was already wondering in which branch experimental was - I
couldn't find it.

I'd be happy to post my latest patch against that git branch, but
before that I'd like to ask if I've gotten across why I think this
is a real issue that needs fixing?

(Sorry for repeating myself multiple times, but I don't think I have
gotten my point across earlier.)

Regards,
Christian



More information about the Vmdebootstrap-devel mailing list