Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

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.
Comment by Jason (Meyithi) - Friday, 22 April 2011, 01:45 GMT
I have this problem as well

more info @ https://bbs.archlinux.org/viewtopic.php?id=117257
Comment by Faruk A (decaturguy) - Friday, 22 April 2011, 10:05 GMT
I have the same problem downgrading udev to 166-2 fixed it.
Comment by Tom Gundersen (tomegun) - Friday, 22 April 2011, 15:58 GMT
Interesting problem, I think I know the solution.

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.
Comment by Tom Gundersen (tomegun) - Friday, 22 April 2011, 16:09 GMT
As  FS#23884  points out, this was caused by grub2 using "rw".
Comment by Jason (Meyithi) - Friday, 22 April 2011, 16:15 GMT
Appears to effect grub-legacy as well "After digging a bit I realized this was caused because rootflags=rw was specified in my menu.lst"
Comment by Tom Gundersen (tomegun) - Friday, 22 April 2011, 16:27 GMT
Ah, I see. Strange. I cannot see anything in the udev package, nor git change log about messing with grub/grub2. Is grub.cfg/menu.lst changed automatically when you upgrade udev, or do you have to upgrade/update grub/grub2 as well?
Comment by Ronald van Haren (pressh) - Friday, 22 April 2011, 16:30 GMT
these files should not be changed by anything ones installed/created
Comment by Faruk A (decaturguy) - Saturday, 23 April 2011, 10:10 GMT
I forgot to mention this but this did'nt effected my desktop, it only effected my server running the LTS kernel.
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

Comment by Tom Gundersen (tomegun) - Saturday, 23 April 2011, 10:21 GMT
@Jason,Faruk,anyone else,
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?
Comment by Faruk A (decaturguy) - Saturday, 23 April 2011, 12:16 GMT
I don't know how it end up there, I really can't play around with this server I'll wait for someone else
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.
Comment by John Skopis (johnskopis) - Saturday, 23 April 2011, 16:30 GMT
Not specifying rootflags=rw in menu.lst solves the issue.

@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)?
Comment by Tom Gundersen (tomegun) - Saturday, 23 April 2011, 18:05 GMT
@johnskopis:
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.
Comment by Matthias Dienstbier (fs4000) - Saturday, 11 June 2011, 14:52 GMT
I think, this can be closed.

Loading...