Re: Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

2011-09-22 Thread Kalyuzhnyy, Ilya - Contractor
I`ll check it out, thanks.


Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

2011-05-13 Thread Goswin von Brederlow
Roger Leigh rle...@codelibre.net writes:

 On Thu, May 12, 2011 at 06:31:48PM +0200, Goswin von Brederlow wrote:
 Adam Borowski kilob...@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-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.

2011-05-12 Thread Goswin von Brederlow
Adam Borowski kilob...@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-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.

2011-05-12 Thread Roger Leigh
On Thu, May 12, 2011 at 06:31:48PM +0200, Goswin von Brederlow wrote:
 Adam Borowski kilob...@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.


signature.asc
Description: Digital signature


Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

2011-05-09 Thread Adam Borowski
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


Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

2011-05-08 Thread Amaya
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



Processed: Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

2011-05-08 Thread Debian Bug Tracking System
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.

2011-05-07 Thread Ted Ts'o
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



Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

2011-05-07 Thread Ben Hutchings
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.

2011-05-07 Thread Roger Leigh
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