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

[Ted Ts'o <tytso@mit.edu>]

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