FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-08-2011, 02:43 AM
Ted Ts'o
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508024329.GA15585@thunk.org">http://lists.debian.org/20110508024329.GA15585@thunk.org
 
Old 05-08-2011, 04:24 AM
Ben Hutchings
 
Default 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.
 
Old 05-08-2011, 05:38 AM
Roger Leigh
 
Default 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.
 
Old 05-08-2011, 10:41 AM
Amaya
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508104135.GU3098@aenima">http://lists.debian.org/20110508104135.GU3098@aenima
 
Old 05-09-2011, 10:01 AM
Adam Borowski
 
Default 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.
 
Old 05-12-2011, 04:31 PM
Goswin von Brederlow
 
Default Bug#616317: base: commit= ext3 mount option in fstab has no effect.

Adam Borowski <kilobyte@angband.pl> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ei43g9sb.fsf@frosties.localnet">http://lists.debian.org/87ei43g9sb.fsf@frosties.localnet
 
Old 05-12-2011, 06:39 PM
Roger Leigh
 
Default 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 <kilobyte@angband.pl> 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.
 
Old 05-14-2011, 01:47 AM
Goswin von Brederlow
 
Default Bug#616317: base: commit= ext3 mount option in fstab has no effect.

Roger Leigh <rleigh@codelibre.net> writes:

> On Thu, May 12, 2011 at 06:31:48PM +0200, Goswin von Brederlow wrote:
>> Adam Borowski <kilobyte@angband.pl> 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-submitter@bugs.debian.org?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3jm3vfl.fsf@frosties.localnet">http://lists.debian.org/87d3jm3vfl.fsf@frosties.localnet
 
Old 09-22-2011, 04:35 PM
"Kalyuzhnyy, Ilya - Contractor"
 
Default Bug#616317: base: commit= ext3 mount option in fstab has no effect.

I`ll check it out, thanks.
 
Old 10-17-2011, 03:37 AM
Jonathan Nieder
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111017033708.GA6157@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111017033708.GA6157@elie.hsd1.il.comcast.net
 

Thread Tools




All times are GMT. The time now is 07:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org