Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On Wed, 2014-12-03 at 23:12 +0100, 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 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? 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. 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. 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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417681985.2372.42.ca...@hellion.org.uk
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
Samuel Thibault sthiba...@debian.org writes: 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? From my POV as an infrequent d-i contributor: For the reasons above and 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 signature.asc Description: PGP signature
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
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 : Would it make any sense to have $something created by d-i, consumed by both systemd and sysvinit to make sure consoles are available? 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. Of course if I'm conflating issues that are orthogonal, please say so and we'll track both issues separately. I actually haven't quoted the vt2-6 issue here because I don't think it is related with d-i. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203221226.gf3...@type.youpi.perso.aquilenet.fr
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
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 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 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. 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? 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. 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 : Would it make any sense to have $something created by d-i, consumed by both systemd and sysvinit to make sure consoles are available? 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. Of course if I'm conflating issues that are orthogonal, please say so and we'll track both issues separately. I actually haven't quoted the vt2-6 issue here because I don't think it is related with d-i. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f8d31.8090...@gedalya.net
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
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 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 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. 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 inittab. Can't some of the logic in finish-install's 90console simply moved to sysvinit-core's postinst? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203224545.gi3...@type.youpi.perso.aquilenet.fr
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 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 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. 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 inittab. 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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f9fa4.9080...@gedalya.net
Re: Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
Hi, Apologies if this is just noise, but i believe this grave bug may be related to (or at least helped by) this discussion. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766187 runit: Fails to install runit after fresh install of jessie beta2 (because /etc/inittab is missing) Thanks Anthony -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calokicqcaeb-5wv4q7qhkdclsq-4dpuqxpvl9wh9+jwhs+z...@mail.gmail.com
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110184318.ge7...@virgil.dodds.net
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On 11/10/2014 01:43 PM, Steve Langasek wrote: On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: 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.. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546114e7.9090...@gedalya.net
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
Hi, Steve Langasek vor...@debian.org (2014-11-10): On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: 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. 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. signature.asc Description: Digital signature
Re: Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On Mon, Nov 10, 2014 at 02:41:27PM -0500, Gedalya wrote: On 11/10/2014 01:43 PM, Steve Langasek wrote: On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: 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.. Are there any other inits that use /etc/inittab? With the plethoors of inits that have showed up over the past decades, it wouldn't surprise me at all if some of them were compatible in this respect. Would it make sense to put /etc/inittab into annother package that sysvinit-core depends on? The way things look right now, with systemd being installed against their wishes, sysvinit users are being told to install sysvinit-core after installation, when they have finally booted the target system. This way, /etc/inittab would be installed for them at the same time. Any other inits could have the same dependency, as apropriate. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110204757.ga19...@topoi.pooq.com
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On 11/10/2014 02:19 AM, Steve Langasek wrote: 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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54606bb0.5020...@gedalya.net
