debian-installer has a script[1] to add a line like
'co:2345:respawn:/sbin/getty hvc0 9600 linux' to inittab at the end of
the installation, when running under xen.
This no longer works because sysvinit-core is not installed by default.
It seems this should be perhaps moved to the sysvinit-core package, in a
way similar to bug #745260
Currently this line must be manually added by the user to get console
access.

[1]
http://anonscm.debian.org/cgit/d-i/finish-install.git/tree/finish-install.d/90console

Thanks,

Gedalya

Control: reassign -1 debian-installer

It's not for the sysvinit-core package to fix up the installer's handling of
consoles, when sysvinit-core is not installed.  Reassigning this to the
debian-installer package.

And how could it possibly be debian-installer's job to modify a file
that is part of your package, when the package is not installed?
I find your response incomprehensible. This bug is about making sure
inittab, part of sysvinit-core, supports the console on the platform is
is running on.
Currently sysvinit-core is defective in not doing so. My comment about
debian-installer was just so that you could see an example for code that
handles this, and it explains why the maintainers of this package
coincidentally haven't had to worry about this problem thus far.
One way or another, to reproduce this problem all one needs to do is to
install sysvinit-core on a xen VM, with debian-installer nowhere in sight.
I also don't understand why #745260 was fixed (exactly the same problem)
and this one somehow not.

Ok, I misunderstood what the bug was that you were reporting.  I thought you
were saying that the installer sets up /etc/inittab, but that this doesn't
cause the console to work on systems where sysvinit-core is not being
installed.

I think fixing bug #745260 in sysvinit-core is dubious; I really think that
the console setup should be done as part of the installer, not as part of
init's maintainer scripts.  However, since we are no longer installing
sysvinit-core, it's a legitimate question whether the installer should be
changed to create /etc/inittab on its own if it doesn't already exist, or if
the installer should entirely hand over control of this file to the sysvinit
package.

I think we should get input from the installer team on this.

I don't really see how it makes sense to create an /etc/inittab when
we're installing systemd (silently and without asking). Without
sysvinit, inittab doesn't belong there and doesn't make sense. The way I
see it, the only way the installer can be of help here is if it is
changed to prompt the user for his init system choice, which AFAIK
wasn't the decision so far.. though it would please me very much!
Otherwise we're sort of pre-creating a file for a hypothetical purpose..

Hi,

Steve Langasek <vorlon@debian.org> (2014-11-10):

let's pretend for a moment that I know nothing about inittab, and that I'm
focussing on installation scenarios only, not upgrades.

It looks to me that this is an issue different from yet similar to the
one described in [1], where systemd w/o dbus would lead to no console on
vt 2-6.

 1. https://lists.debian.org/debian-boot/2014/11/msg00127.html

Would it make any sense to have $something created by d-i, consumed by
both systemd and sysvinit to make sure consoles are available? If
maintainers of both systems can come up with something suitable for
everyone, let's do that? Maybe some kind of /etc/inittab.compat which
could be created by d-i and could be defaulted to by relevant packages
in case /etc/inittab is missing and yet needed?

Of course if I'm conflating issues that are orthogonal, please say so
and we'll track both issues separately.

Mraw,
KiBi.

I noticed that my last mail about 766187 being related to 768657
didn't actually go to the bug report. (which was about this bug being
related)
Anyway, both of these bugs seem to be about providing /etc/inittab in
one form or another.
Please see KiBi's last entry about providing it via D-I which has gone
unanswered.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768657
I'm only sharing this as it would appear there are two separate
conversations happening about the same problem. (and i'm assuming that
a solution should / would solve both)

I'm not sure to understand what the original bug report is about
precisely.  AIUI, it is about the following scenario:

1) install debian in a Xen domU, ending up with systemd installed by
default
2) install sysvinit-core to switch back to sysvinit boot
3) end up having to fix this and that to get sysvinit work properly

I am not very surprised that it does not work.  The various tuning that
d-i does usually only work on what gets installed during d-i, not on
what gets installed later on.  That's particularly the case for software
which doesn't provide nice hooks for d-i to use them.

I'm just wondering one thing: between steps 1) and 2), does the
installed system (using systemd) properly have a login banner on hvc0?
If not, then it's indeed a problem, but not related with sysvinit
and inittab. In the current logic, some more code should be added to
finish-install's 90console script to handle the systemd case.  I don't
have a Xen system offhand to easily test that.

Cyril Brulebois, le Mon 10 Nov 2014 20:51:28 +0100, a écrit :

It would make sense, but I'm not sure we can manage to write something
that both sysvinit and systemd can understand easily. "include" support
could be added to sysvinit, and /etc/inittab made to include the
d-i-generate bits, but it'd still be in inittab format, which AIUI
systemd wouldn't grok. So it would be something else, but then we would
have to make sysvinit aware of what a serial login is, which it has
never been made to, for flexibility reasons.

I actually haven't quoted the vt2-6 issue here because I don't think it
is related with d-i.

Samuel

"this and that" being very specifically one line added to inittab:
co:2345:respawn:/sbin/getty hvc0 9600 linux
Given the above scenario this needs to be done by hand.
As I understand the code, currently d-i would still add that for the
user, if /etc/inittab existed, and it doesn't because sysvinit-core is
not installed.
I'm not aware of any other issue.
It does. The problem occurs only after installing sysvinit-core. If the
user really depends on a console then they would need to add this line
before rebooting, and we can expect that they might not know to do so.

Gedalya, le Wed 03 Dec 2014 17:22:41 -0500, a écrit :
tunes packages which it has installed.  It doesn't tune much what could
potentially get installed later on.  And it should for sure not install
a complete /etc/inittab, that would only confuse people who were used to
configure things there.

What is new here is that sysvinit-core can now get initially installed
not from d-i.  And thus the tuning usually done by d-i can't work.

Also, we probably have to think about ping-pong scenarii: install
sysvinit-core, then switch back to systemd, purge sysvinit-core, and
drop /etc/inittab. Change one's mind again, reinstall sysvinit-core.
We still want to have a console on /dev/hvc0.  We're far from d-i, so
it'd rather be sysvinit-core which does the job of adding the console to
inittab.

Can't some of the logic in finish-install's 90console simply moved to
sysvinit-core's postinst?

Samuel

The bug I initially opened was against sysvinit, asking for exactly
this, and citing a case where this was already done, recently.

I believe it will, systemd probes for suitable console devices and
spawns getty's for them. I'm sure I've seen this in Debian guests using
systemd, although I've not gone and checked my recollection.

Something which might be helpful is
http://lists.xen.org/archives/html/xen-devel/2013-12/msg00805.html which
was posted on the xen-devel but redirected to the appropriate upstream,
since it isn't Xen specific. I wonder how that got on. Anyway, it would
allow all the various initsystems to just spawn one of these "smart
gettys" and get a getty on the console device, whatever that may be.

Ian.

Samuel Thibault <sthibault@debian.org> writes:
because having an /etc/inittab which does not do anything on systemd is
confusing I think moving this to sysvinit-core is the best solution.

Not reassing the bug right now to let others comment first.

Gaudenz