Bug#616317: base: commit= ext3 mount option in fstab has no effect.
reassign 616317 initscripts quit Roger Leigh wrote: > On Sun, May 08, 2011 at 05:24:09AM +0100, Ben Hutchings wrote: >> Could we not have init remount root based on /etc/fstab? [...] > Also, with the version of initscripts in experimental, the domount > mount helper can remount filesystems with the options from /etc/fstab. I guess that means this bug was fixed by initscripts 2.88dsf-13.5. [...] >> I suppose the problem then is that some >> mount options can't practically be changed when remounting. (Worse, the >> failure to change them is silent in some cases. And that is definitely >> a bug.) That sounds like a separate bug, though probably an important one. Could you say more about it? For example, which package would have to be changed to fix it? lazily, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111017033708.ga6...@elie.hsd1.il.comcast.net
Re: Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
I`ll check it out, thanks.
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
Roger Leigh writes: > On Thu, May 12, 2011 at 06:31:48PM +0200, Goswin von Brederlow wrote: >> Adam Borowski writes: >> >> Should we try to make this work (at best badly) since a change in >> >> mount options in /etc/fstab would only take effect at the next >> >> mkinitramfs and/or update-grub invocation? Or should we just close >> >> out this bug and say, "tough luck, kid; if you want to change the root >> >> file system's mount options, you need to edit your kernel's boot >> >> options using whatever bootloader you might happen to be using"? >> >> Or the init scripts could "mount -oremount,commit=300 /". Most options >> can be altered throught remount. For the few remaining ones >> (e.g. data=writeback) editing the kernel's boot options is probably ok. >> >> The init scripts already do this for read-only / read-write. Why doesn't >> this work for commit= too? > > The initscripts /do/ already do this. See checkroot.sh and read_fstab > in /lib/init/mount-functions.sh. > > If it's not working for you, then it's possible that the fstab entry > for / doesn't match. Might be worth sourcing and running read_fstab > by hand to see if it's pulling out the options correctly. > > > Regards, > Roger Did you ment to send this to 616317-submit...@bugs.debian.org? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3jm3vfl.fsf@frosties.localnet
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
On Thu, May 12, 2011 at 06:31:48PM +0200, Goswin von Brederlow wrote: > Adam Borowski writes: > >> Should we try to make this work (at best badly) since a change in > >> mount options in /etc/fstab would only take effect at the next > >> mkinitramfs and/or update-grub invocation? Or should we just close > >> out this bug and say, "tough luck, kid; if you want to change the root > >> file system's mount options, you need to edit your kernel's boot > >> options using whatever bootloader you might happen to be using"? > > Or the init scripts could "mount -oremount,commit=300 /". Most options > can be altered throught remount. For the few remaining ones > (e.g. data=writeback) editing the kernel's boot options is probably ok. > > The init scripts already do this for read-only / read-write. Why doesn't > this work for commit= too? The initscripts /do/ already do this. See checkroot.sh and read_fstab in /lib/init/mount-functions.sh. If it's not working for you, then it's possible that the fstab entry for / doesn't match. Might be worth sourcing and running read_fstab by hand to see if it's pulling out the options correctly. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
Adam Borowski writes: > On Sat, May 07, 2011 at 10:43:29PM -0400, Ted Ts'o wrote: >> This isn't a bug in e2fsprogs; e2fsprogs has absolutely nothing to do >> with mounting the file system. >> >> Debian simply doesn't support the mount options for the root file >> system in /etc/fstab having any effect on how the root file system is >> mounted. The root file system is mounted by the kernel, and the mount >> options used by the kernel are specified by the rootflags= option on >> the kernel's boot command line. >> >> Should we try to make this work (at best badly) since a change in >> mount options in /etc/fstab would only take effect at the next >> mkinitramfs and/or update-grub invocation? Or should we just close >> out this bug and say, "tough luck, kid; if you want to change the root >> file system's mount options, you need to edit your kernel's boot >> options using whatever bootloader you might happen to be using"? Or the init scripts could "mount -oremount,commit=300 /". Most options can be altered throught remount. For the few remaining ones (e.g. data=writeback) editing the kernel's boot options is probably ok. The init scripts already do this for read-only / read-write. Why doesn't this work for commit= too? > It is really annoying to have to edit the same thing twice and face boot > failures if you forgot that. There are legitimate reasons you might want to > change boot options often. > > Would it be possible to ask the kernel what root fs options it received? > The line in fstab could then be changed to include only options that change, > without having to redundantly specify device, fs type, subvolume and the > like. /proc/mounts shows the current options. > Rationale: as you said, there are so many ways to configure kernel's command > line, the source for kernel's configuration might even be not present on the > system at all. Trying to update that configuration from /etc/fstab seems to > be impossible, but going the other way around seems relatively easy. > > With /etc/fstab no longer having authoritative data for the root fs, one > would have to change fsck and mount, but since there are few consumers of > /etc/fstab, that's not a show stopper. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei43g9sb.fsf@frosties.localnet
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
On Sat, May 07, 2011 at 10:43:29PM -0400, Ted Ts'o wrote: > This isn't a bug in e2fsprogs; e2fsprogs has absolutely nothing to do > with mounting the file system. > > Debian simply doesn't support the mount options for the root file > system in /etc/fstab having any effect on how the root file system is > mounted. The root file system is mounted by the kernel, and the mount > options used by the kernel are specified by the rootflags= option on > the kernel's boot command line. > > Should we try to make this work (at best badly) since a change in > mount options in /etc/fstab would only take effect at the next > mkinitramfs and/or update-grub invocation? Or should we just close > out this bug and say, "tough luck, kid; if you want to change the root > file system's mount options, you need to edit your kernel's boot > options using whatever bootloader you might happen to be using"? It is really annoying to have to edit the same thing twice and face boot failures if you forgot that. There are legitimate reasons you might want to change boot options often. Would it be possible to ask the kernel what root fs options it received? The line in fstab could then be changed to include only options that change, without having to redundantly specify device, fs type, subvolume and the like. Rationale: as you said, there are so many ways to configure kernel's command line, the source for kernel's configuration might even be not present on the system at all. Trying to update that configuration from /etc/fstab seems to be impossible, but going the other way around seems relatively easy. With /etc/fstab no longer having authoritative data for the root fs, one would have to change fsck and mount, but since there are few consumers of /etc/fstab, that's not a show stopper. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Processed: Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
Processing commands for cont...@bugs.debian.org: > reassign 616317 general Bug #616317 [base] base: commit= ext3 mount option in fstab has no effect. Bug reassigned from package 'base' to 'general'. > thanks Stopping processing here. Please contact me if you need assistance. -- 616317: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616317 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13048513041699.transcr...@bugs.debian.org
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
reassign 616317 general thanks In http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;bug=616317 you said: > So I'm going to do the cowardly thing, and choose the third option, > which is to reassign this back to base, cc'ing debian-devel. I'm not > sure what the right thing is to do here, since honoring this feature > request would require making changes to multiple different packages: > initramfs-tools, all of the bootloaders, etc. Well, "base" is for users that do not know where to report complex bugs like this. This is a perfect case for package "general", for the reasons you described, so I am reassigning. Thanks for the useful input on this bug, very clarifying!. -- .''`. Hate's no fun if you keep it to yourself : :' : -- The life of David Gale `. `' `-Proudly running Debian GNU/Linux -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508104135.GU3098@aenima
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
On Sun, May 08, 2011 at 05:24:09AM +0100, Ben Hutchings wrote: > On Sat, 2011-05-07 at 22:43 -0400, Ted Ts'o wrote: > [...] > > Should we try to make this work (at best badly) since a change in > > mount options in /etc/fstab would only take effect at the next > > mkinitramfs and/or update-grub invocation? Or should we just close > > out this bug and say, "tough luck, kid; if you want to change the root > > file system's mount options, you need to edit your kernel's boot > > options using whatever bootloader you might happen to be using"? > [...] > > Could we not have init remount root based on /etc/fstab? It already > handles remounting read-write. I suppose the problem then is that some > mount options can't practically be changed when remounting. (Worse, the > failure to change them is silent in some cases. And that is definitely > a bug.) See also: #520009 Also, with the version of initscripts in experimental, the domount mount helper can remount filesystems with the options from /etc/fstab. This is used to remount the filesystems mounted in the early initramfs with the options the sysadmin defined (if any). This could also be extended to do the same for the rootfs. The existing read_fstab could also be refactored to use the generic read_fstab_entry to pull out the entire set of mount options for remounting rather than just using the ro option. As both this and #520009 note, this won't work for all mount options such as data= for ext3, but it would allow any other options to from fstab to be applied to the root mount. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
On Sat, 2011-05-07 at 22:43 -0400, Ted Ts'o wrote: [...] > Should we try to make this work (at best badly) since a change in > mount options in /etc/fstab would only take effect at the next > mkinitramfs and/or update-grub invocation? Or should we just close > out this bug and say, "tough luck, kid; if you want to change the root > file system's mount options, you need to edit your kernel's boot > options using whatever bootloader you might happen to be using"? [...] Could we not have init remount root based on /etc/fstab? It already handles remounting read-write. I suppose the problem then is that some mount options can't practically be changed when remounting. (Worse, the failure to change them is silent in some cases. And that is definitely a bug.) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
reassign 616317 base thanks This isn't a bug in e2fsprogs; e2fsprogs has absolutely nothing to do with mounting the file system. Debian simply doesn't support the mount options for the root file system in /etc/fstab having any effect on how the root file system is mounted. The root file system is mounted by the kernel, and the mount options used by the kernel are specified by the rootflags= option on the kernel's boot command line. This is effectively a feature request, and I debated what was the best way to deal with this bug. I could close it, and say, "not a bug", since Debian has never worked this way, and I suspect it was deliberate. Or, I could assign it to initramfs-tools, since what some other distributions do is look in /etc/fstab, parse out the mount options in for the root file system in /etc/fstab, and then insert into initrd image the appropriate root mount options. The problem with this is, (a) it's a bit of a hack, (b) it only takes effect the next time you install a new kernel, or if you deliberately and explicitly run mkinitramfs, which has fairly baroque options that most users would never figure out, and (c) not all Debian installations use an initrd, so whether or not it works would depend on how the boot sequence was set up. If you don't use an initrd, you'd have to edit it into the grub's configuration file. But then, not all Debian systems use grub as their boot loader. Neither these seemed obviously the right choice. So I'm going to do the cowardly thing, and choose the third option, which is to reassign this back to base, cc'ing debian-devel. I'm not sure what the right thing is to do here, since honoring this feature request would require making changes to multiple different packages: initramfs-tools, all of the bootloaders, etc. Should we try to make this work (at best badly) since a change in mount options in /etc/fstab would only take effect at the next mkinitramfs and/or update-grub invocation? Or should we just close out this bug and say, "tough luck, kid; if you want to change the root file system's mount options, you need to edit your kernel's boot options using whatever bootloader you might happen to be using"? I have a slight preference for the latter, since it's a lot less complexity that won't really work right anyway, but let's see what other people think. Regards, - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508024329.ga15...@thunk.org