Red Hat Bugzilla – Bug 154768
mkinitrd creates broken ramdisks if /etc/fstab contains 'rw'
Last modified: 2014-12-01 18:08:13 EST
Description of problem:
system won't boot with an initrd image, if it was created when /etc/fstab
contained 'rw' in the root filesystem options
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. edit /etc/fstab, replace 'defaults' with 'rw'
2. do something which invokes mkinitrd (e.g. install updated kernel)
initrd mounts / read-write, then 'fsck /' fails, and rc.sysinit drops
you to the emergency shell
should boot without problems
problem lies with one command in the generated ramdisk
mount -o rw --ro -t ext3 /dev/root /sysroot
which mounts in rw mode, instead of ro mode.
Can be difficult to figure out if several months pass between 1. and 2.
You can either fix nash, so that '--ro' will have higher priority
than '-o rw', or enhance mkinird to do s/rw/defaults/.
Why is it set to "rw" in /etc/fstab? I think this shouldn't be a supported
thing to do, but if you've got a good reason, I'd like to hear it so I can
> Why is it set to "rw" in /etc/fstab?
No particular reason. I was editing /etc/fstab by hand, and "rw" is
easier to type than "defaults".
> I think this shouldn't be a supported thing to do...
mount(8) says "defaults -- Use default options: rw, suid, dev, exec,
auto, nouser, and async".
So, IMHO, system should behave exactly the same no matter if /etc/fstab
contains "defaults", "rw", "rw,suid,dev", "suid,async", or any other
subset of default options.
Consider also the reverse of your question - is there a good reason why
user should not be allowed to put "rw" into /etc/fstab ?