FS#23845 - [grub2][filesystem] root mounted rw after upgrade
Attached to Project:
Arch Linux
Opened by John Skopis (johnskopis) - Tuesday, 19 April 2011, 19:34 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 11 June 2011, 14:58 GMT
Opened by John Skopis (johnskopis) - Tuesday, 19 April 2011, 19:34 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 11 June 2011, 14:58 GMT
|
Details
Description:
After upgrading today, and rebooting, my system came up with / mounted rw. This caused the autofsck to complain that / was mounted rw and that performing the fsck was REALLY a bad idea. This is significant as some users might choose to fsck anyway. After digging a bit I realized this was caused because rootflags=rw was specified in my menu.lst. I do not remember specifying this so I want to blame the upgrade. (unconfirmed) After digging a bit more readwrite="no" was set because I passed 'ro' in grub; set in /lib/initcpio/init:50 This caused the mount options to actually be -o rorw This caused mount to mount / rw. This caused the fsck to failure. The only case I can ever think of mounting / rw would be with a livecd, or a diskless system...I could be wrong, but I think always mounting readonly, unless a "diskless" hook is in use is the way to go... Additional info: * package version(s) mkinitcpio 0.6.8-2 mkinitcpio-busybox 1.18.2-1 * config and/or log files etc. # (0) Arch Linux title Arch Linux root (hd0,2) kernel /vmlinuz26 root=/dev/disk/by-uuid/bb68a282-5ab1-4294-82f1-d8ac57b74146 rootflags=rw rootfstype=ext3 ro initrd /kernel26.img # (1) Arch Linux title Arch Linux Fallback root (hd0,2) kernel /vmlinuz26 root=/dev/disk/by-uuid/bb68a282-5ab1-4294-82f1-d8ac57b74146 rootflags=rw rootfstype=ext3 ro initrd /kernel26-fallback.img Steps to reproduce: 1) upgrade 2) configure grub as above 3) ??? 4) system boots, mounting / as rw |
This task depends upon
Closed by Tom Gundersen (tomegun)
Saturday, 11 June 2011, 14:58 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed released.
Saturday, 11 June 2011, 14:58 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed released.
more info @ https://bbs.archlinux.org/viewtopic.php?id=117257
Firstly, my guess at two fixes:
1) do not pass rw to grub, or
2) upgrade to the newest mkinitrd and initscripts from testing.
This is what happens:
During boot we remount / ro in order to fsck it. Usually this is not needed as root is already ro (if the right parameters were passed to grub, see above), and in the cases where root is rw it will only work if nothing is accessing the disc (in other words this remount is a bit missleading...). In your case you have something accessing disk (which should not happen) and you are right in thinking it is udev.
Udev is configured to put its runtime files in /run if and only if the folder exists and is writable. This folder was added recently to [filesystem] and the intention is that initrd or initscripts should mount a tmpfs on top of /run, so that udev can put its stuff there without writing to /. The bug is that the folder should have had permissions 0000, so that in case /run is not mounted as tmpfs udev will fall back to /dev/.udev and not write to /.
A proper solution would be to change the permissions in filesystem, but the problem should also be solved by upgrading to the most recent initscripts and mkinitrd from testing. In general I guess all folders that should alway be mountpoints should have permissions 0000 to avoid problems in the future.
FS#23884points out, this was caused by grub2 using "rw".Since the udev downgrade i did'nt had any problem.
my menu.1st
title Arch Linux LTS
root (hd0,0)
kernel /vmlinuz26-lts root=/dev/disk/by-uuid/52bc93aa-901d-4680-a05c-0c94daa850ba rootflags=rw rootfstype=ext4 ro quite
initrd /kernel26-lts.img
The question seems to be: How did rootflags=rw end up in your grub.cfg/menu.lst?
Also, can you confirm that the problem is gone with the latest packages (mkinitrd/initscripts) from testing?
to confirm.
My reason: The server is running on a old atom nettop laptop that i picked up from my sisters trashcan, the lcd screen
is broken i removed it and the external vga out doesn't work. If it brakes i have disassemble the laptop remove the
hard drive and connect to sata-to-usb adapter and connect to my desktop, fix it and put everything back again.
So far this happened twice after package upgrade and if it happens again bye bye my pink server.
What i like about it's the power usage only 7-10 watts.
@tomegun I honestly cannot remember if I added rootflags=rw to menu.lst, or it happened as part of a recent kernel upgrade.
Is there any good reason to mount / rw (on a regular system)?
No, this parameter is usually ignored. We always remount root as ro during boot, and then back to rw just before boot finishes. The problem occurred in the window between udev is started and when we remount root ro.
I will commit a fix to remount root ro very early in boot, so that a bug like this cannot happen again.
Thanks for reporting.