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): mkinitrd-4.1.18-2 How reproducible: always Steps to Reproduce: 1. edit /etc/fstab, replace 'defaults' with 'rw' 2. do something which invokes mkinitrd (e.g. install updated kernel) 3. reboot Actual results: initrd mounts / read-write, then 'fsck /' fails, and rc.sysinit drops you to the emergency shell Expected results: should boot without problems Additional info: 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 reconsider.
> 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 ?