Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Carsten Hey [2012-04-30 02:00 +0200]: * Roger Leigh [2012-04-29 23:19 +0100]: I was just thinking, is there a way to detect if the system was bootstrapped with grml-bootstrap compared with plain debootstrap? If that was the case, we could put a specific check for that in, and clean up the fstab if so. It would mean everyone else would get the configuration preserved, and only the broken ones get updated, which I think would be a reasonable compromise if possible. grml-debootstrap copies files into the chroot that is being created: cp $VERBOSE $CONFFILES/chroot-script $MNTPOINT/bin/chroot-script cp $VERBOSE $CONFFILES/config$MNTPOINT/etc/debootstrap/ ... If you choose this way of solving the issue, please drop us a mail so that we can look up if tests like the above would work with all relevant grml-debootstrap versions. This still holds, if you think detecting grml-debootstrap'ed systems is the way to go, please drop us a mail previously. This would of course not fix other systems with such a buggy fstab entry. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. For current systems, I think it's useful to know what systemd and upstart are doing. systemd is simple enough to test on Debian; for upstart we can look at Ubuntu. Part of the reason for the mount changes was to align the mount options with those used in the initramfs (copied both ways, but mainly updating the initramfs with the initscripts defaults), and also with systemd so that we have consistent behaviour across all init systems and boot methods. So if all the others choose to not respect noauto for specific mounts, that's a point in favour of doing that. Being consistent to other init systems in Debian makes sense. I'll send an other mail after knowing this. I installed Fedora 16 (uses systemd as init and was released in November 2011) and the just released Ubuntu LTS (uses upstart) into a KVM container and added a noauto sysfs line for /sys that matches (besides noauto) their default mount options to /etc/fstab on both systems. On both systems, /sys was mounted despite the noauto sysfs entry. I don't know if upstart and systemd on Debian behave differently than on their native distributions, but if they do, then I'd tend to consider this derivation to be buggy unless there is a valid reason for it. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
On Sat, Apr 28, 2012 at 11:16:48PM +0200, Carsten Hey wrote: [ Dropping hmh from Cc, I was not sure if he's one of the uploaders and thus should receive the mail anyway - but I looked it up now. ] * Roger Leigh [2012-04-28 20:17 +0100]: On Sat, Apr 28, 2012 at 06:21:58PM +0200, Carsten Hey wrote: * Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]: The correct thing to do would be to fix the broken /etc/fstab, then... There is only one reliable way to do so: in initscripts' preinst. But if it does not need to be that reliable, then postinst ... initscripts can't fix this problem /at all/ by altering /etc/fstab. ... So the correct thing could, besides doing it manually, only be done in a maintainer script of an essential package, but as you explained, doing this would be wrong. I think we agree that there is no clean way to remove the line automatically. I was just thinking, is there a way to detect if the system was bootstrapped with grml-bootstrap compared with plain debootstrap? If that was the case, we could put a specific check for that in, and clean up the fstab if so. It would mean everyone else would get the configuration preserved, and only the broken ones get updated, which I think would be a reasonable compromise if possible. If the admin deliberately configured a mount with noauto, Is there any valid use-case to configure a sysfs mount to /sys with noauto? If so, was there an according bug report before doing so had this effect? Not that I am aware of for the host system. we would be deliberately trashing their configuration. A regression leading to unbootable systems sounds like a bug to me, even if the previously working configuration is considered to be buggy. It's a bug. And we should not break any systems if we can help it. But the change in behaviour is only exposing a latent bug originating elsewhere. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. For current systems, I think it's useful to know what systemd and upstart are doing. systemd is simple enough to test on Debian; for upstart we can look at Ubuntu. Part of the reason for the mount changes was to align the mount options with those used in the initramfs (copied both ways, but mainly updating the initramfs with the initscripts defaults), and also with systemd so that we have consistent behaviour across all init systems and boot methods. So if all the others choose to not respect noauto for specific mounts, that's a point in favour of doing that. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Roger Leigh [2012-04-29 23:19 +0100]: On Sat, Apr 28, 2012 at 11:16:48PM +0200, Carsten Hey wrote: So the correct thing could, besides doing it manually, only be done in a maintainer script of an essential package, but as you explained, doing this would be wrong. I think we agree that there is no clean way to remove the line automatically. I was just thinking, is there a way to detect if the system was bootstrapped with grml-bootstrap compared with plain debootstrap? If that was the case, we could put a specific check for that in, and clean up the fstab if so. It would mean everyone else would get the configuration preserved, and only the broken ones get updated, which I think would be a reasonable compromise if possible. grlm-debootstrap copies files into the chroot that is being created: cp $VERBOSE $CONFFILES/chroot-script $MNTPOINT/bin/chroot-script cp $VERBOSE $CONFFILES/config$MNTPOINT/etc/debootstrap/ Removing a part of them has been added in a commit after the fstab has been fixed, but I don't know if this clean up was always (or rather in the four years the fstab error existed) missing in grml-debootstrap or if it has been deleted whilst refactoring, but this can be looked up. Users might delete either /bin/chroot-script, /etc/debootstrap/ or both after installation. Normally I don't delete any of them, but I don't know how others handle this or if others even know that there are still files needed during installation on their system. Possible ways to detect 'grml-bootstrap'ed systems include (given that the files have not been deleted manually and that there are no relevant changes grlm-debootstrap in the relevant timeframe): $ fgrep -q -x done /etc/debootstrap/stages/fstab 2/dev/null $ test -x /bin/chroot-script $ [ -x /bin/chroot-script ] grep -qx '^# Purpose:.*executed.*via grml-debootstrap$' /bin/chroot-script Unlike the second line, the third will not wrongly return 0 if a user created an unrelated script with the same name. One way to raise the probability of a correct result in case the user deleted either the directory or the file is to combine the first and the last line. If you choose this way of solving the issue, please drop us a mail so that we can look up if tests like the above would work with all relevant grml-debootstrap versions. If the admin deliberately configured a mount with noauto, Is there any valid use-case to configure a sysfs mount to /sys with noauto? If so, was there an according bug report before doing so had this effect? Not that I am aware of for the host system. I assume the reason for these questions is obvious; without a valid use case for this, both options seem to be reasonable for me, and with a valid use case only initscripts' current behaviour would have been reasonable. we would be deliberately trashing their configuration. A regression leading to unbootable systems sounds like a bug to me, even if the previously working configuration is considered to be buggy. It's a bug. And we should not break any systems if we can help it. But the change in behaviour is only exposing a latent bug originating elsewhere. I fully agree. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. For current systems, I think it's useful to know what systemd and upstart are doing. systemd is simple enough to test on Debian; for upstart we can look at Ubuntu. Part of the reason for the mount changes was to align the mount options with those used in the initramfs (copied both ways, but mainly updating the initramfs with the initscripts defaults), and also with systemd so that we have consistent behaviour across all init systems and boot methods. So if all the others choose to not respect noauto for specific mounts, that's a point in favour of doing that. Being consistent to other init systems in Debian makes sense. I'll send an other mail after knowing this. Regards Carsten P.S.: No, you are not the only one. The current situation is more or less an evolution of what started years ago. If needed, I think there is a large enough community to provide alternatives before people become completely insane and create a tightly integrated Gnome distribution (what btw. already has been proposed) based on Linux core. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
On Wed, 25 Apr 2012, Carsten Hey wrote: * Roger Leigh [2012-04-24 16:31 +0100]: On Tue, Apr 24, 2012 at 02:55:55PM +0200, Michael Prokop wrote: * Carsten Hey [Mon Apr 23, 2012 at 01:07:17 +0200]: Please ignore noauto sysfs entries in fstab. Not mounting sysfs to /sys if such a line is present in fstab leads to udev not starting. If this bug is not fixed, this problems will show up after upgrading to Wheezy on some systems. [...] FTR: According to my tests, bootstrapping wheezy with grml-debootstrap 0.49 fails WRT /sys mounting and bootstrapping whezzy with grml-debootstrap 0.50 (just released and uploaded, it does not add a noauto sysfs line any longer) succeeds. So does this problem still need addressing in initscripts? The problem is that installing Squeeze via grml-debootstrap perfectly works and after upgrading to Wheezy udev will not start. A wrongly generated /etc/fstab can't be fixed for existing systems by releasing a fixed version of a tool that is only run once during installation. The correct thing to do would be to fix the broken /etc/fstab, then... initscripts is currently respecting what you obviously *think* are the wishes of the admin. Since /sys is nowadays mounted on most or all Which means we're following the principle of least surprise... And you can mount /sys more than once, in weird places for whatever reasons. Those could conceivably be noauto, so we'd have to ignore noauto only on lines that attempt to mount the special filesystems where we'd expect them to be mounted in the first place. In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear The other distros ignore noauto? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
* Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]: On Wed, 25 Apr 2012, Carsten Hey wrote: The problem is that installing Squeeze via grml-debootstrap perfectly works and after upgrading to Wheezy udev will not start. A wrongly generated /etc/fstab can't be fixed for existing systems by releasing a fixed version of a tool that is only run once during installation. The correct thing to do would be to fix the broken /etc/fstab, then... There is only one reliable way to do so: in initscripts' preinst. But if it does not need to be that reliable, then postinst would be fine too in case you'd like to keep the preinst scripts of essential packages (and their dependencies) as small or as simple as possible. initscripts is currently respecting what you obviously *think* are the wishes of the admin. Since /sys is nowadays mounted on most or all Which means we're following the principle of least surprise... In general, I don't consider changing a programs behaviour without a reason to do so to match the principle of least surprise. Not starting udev because of this change (not mounting /sys in Wheezy with the same config that works in Squeeze) doesn't make the situation any better. And you can mount /sys more than once, in weird places for whatever reasons. Those could conceivably be noauto, so we'd have to ignore noauto only on lines that attempt to mount the special filesystems where we'd expect them to be mounted in the first place. I agree, and I don't think that this would be a problem. Alternatively fstab entries could be ignored entirely if the file system is sysfs, the mountpoint is /sys and the options contain noauto; and similar for /proc. In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear The other distros ignore noauto? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. I'm neither sure about the answers to your questions not about their intention. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
On Sat, Apr 28, 2012 at 06:21:58PM +0200, Carsten Hey wrote: * Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]: On Wed, 25 Apr 2012, Carsten Hey wrote: The problem is that installing Squeeze via grml-debootstrap perfectly works and after upgrading to Wheezy udev will not start. A wrongly generated /etc/fstab can't be fixed for existing systems by releasing a fixed version of a tool that is only run once during installation. The correct thing to do would be to fix the broken /etc/fstab, then... There is only one reliable way to do so: in initscripts' preinst. But if it does not need to be that reliable, then postinst would be fine too in case you'd like to keep the preinst scripts of essential packages (and their dependencies) as small or as simple as possible. initscripts can't fix this problem /at all/ by altering /etc/fstab. If the admin deliberately configured a mount with noauto, we would be deliberately trashing their configuration. Second-guessing what the admin /might have wanted/ is a road that we really don't want to go down, IMO, since it always comes back to bite eventually. In general, I don't consider changing a programs behaviour without a reason to do so to match the principle of least surprise. Not starting udev because of this change (not mounting /sys in Wheezy with the same config that works in Squeeze) doesn't make the situation any better. So I think I'm probably responsible for this change in behaviour. The old mountkernfs/devsubfs/... scripts had tons of duplicated code, and the same code was also duplicated to support mtab generation. I refactored all this into a domount function in /lib/init/mount-functions.sh. This made everything more readable, consistent and maintainable, as well as fixing a number of bugs. It also made respecting various mount options such as noauto consistent across the board. However... I really don't think the new behaviour is buggy or broken. If anything, it's a big improvement over the old code. I'm not sure I think this is a bug in initscript at all, really. It's breaking on a file generated by a buggy grml-debootstrap, but I don't think that is in any way initscripts' responsibility. In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear The other distros ignore noauto? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. I'm neither sure about the answers to your questions not about their intention. It sounds quite straightforward to me: how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670106: [Pkg-sysvinit-devel] Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
[ Dropping hmh from Cc, I was not sure if he's one of the uploaders and thus should receive the mail anyway - but I looked it up now. ] * Roger Leigh [2012-04-28 20:17 +0100]: On Sat, Apr 28, 2012 at 06:21:58PM +0200, Carsten Hey wrote: * Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]: The correct thing to do would be to fix the broken /etc/fstab, then... There is only one reliable way to do so: in initscripts' preinst. But if it does not need to be that reliable, then postinst ... initscripts can't fix this problem /at all/ by altering /etc/fstab. ... So the correct thing could, besides doing it manually, only be done in a maintainer script of an essential package, but as you explained, doing this would be wrong. I think we agree that there is no clean way to remove the line automatically. If the admin deliberately configured a mount with noauto, Is there any valid use-case to configure a sysfs mount to /sys with noauto? If so, was there an according bug report before doing so had this effect? we would be deliberately trashing their configuration. The admin relied on undocumented and undefined behaviour if a sysfs mount to /sys with noauto was deliberately configured, and this configuration attempt was never successful in any stable Debian release. In general, I don't consider changing a programs behaviour without a reason to do so to match the principle of least surprise. ... ... This made everything more readable, consistent and maintainable, as well as fixing a number of bugs. It also made respecting various mount options such as noauto consistent across the board. However... I really don't think the new behaviour is buggy or broken. If anything, it's a big improvement over the old code. Well, better code and consistent behaviour (over different mount options or over different releases) are not necessarily the same. I'm not sure I think this is a bug in initscript at all, really. It's breaking on a file generated by a buggy grml-debootstrap, All but producing the same fstab entries as the debian-installer would is in my opinion a bug in any alternative installer. but I don't think that is in any way initscripts' responsibility. That initscripts does not fix bugs introduced by other packages is not a bug in initscripts. initscripts responsibility in this case is in my opinion that it should not render systems that worked well under an previous stable release to be unbootable after upgrading to an new release. A regression leading to unbootable systems sounds like a bug to me, even if the previously working configuration is considered to be buggy. In my opinion, the underlying problem is that there is no clear and distribution independent semantic of noauto when used in a fstab entry for those standard virtual file systems. If there would be such a clear The other distros ignore noauto? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. I'm neither sure about the answers to your questions nor about their fixed typo here ^ intention. It sounds quite straightforward to me: Yes, the question is indeed straightforward. how do other distributions handle noauto in this situation? Do they respect it, ignore it, or not look at fstab at all? I know that at least some switched from requiring an /sys fstab entry to not requiring it, but I do not know what others do if there is still such a line. This is what I meant by not being sure about the answers. By not being sure about the intention I meant this: Since Debian Squeeze handles such lines different from Debian Wheezy, we already got two major distributions (stable and testing) that assume a different semantic. If we would check how other distributions handle this, we would (independent of the result) get at least two different behaviours in major distributions and I don't see which conclusion could be drawn from some do this and others do this. Even if all would assume the same semantic, due to a lacking standard like document or reference implementation, no one could guarantee that some distributions do not switch to a different behaviour the next day (even with a standard no one could guarantee this, but then we at least would know that they are broken and how to do it correctly). Anyway, you seem to consider this questions to be important. If you think that they are that important that the outcome of this discussion depends on it, I think the behaviour of other distributions can be investigated, it just will need some time. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
