[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab

On 12/03/2014 05:45 PM, Samuel Thibault wrote:
Gedalya, le Wed 03 Dec 2014 17:22:41 -0500, a écrit :
On 12/03/2014 05:12 PM, Samuel Thibault wrote:
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
2) install sysvinit-core to switch back to sysvinit boot
3) end up having to fix this and that to get sysvinit work properly
"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
Well, yes.  But this does not seem surprising to me: again, usually d-i
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.

I'm just wondering one thing: between steps 1) and 2), does the
installed system (using systemd) properly have a login banner on hvc0?
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.
Well, changing the init system is not something trivial indeed.

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

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

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

Reply to: