FS#18213 - [mkinitcpio] 0.5.99.3 cannot mount root readonly
Attached to Project:
Arch Linux
Opened by xduugu (xduugu) - Sunday, 07 February 2010, 15:25 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 February 2010, 21:00 GMT
Opened by xduugu (xduugu) - Sunday, 07 February 2010, 15:25 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 February 2010, 21:00 GMT
|
Details
The new busybox based mkinitcpio generates images that
cannot mount my root readonly.
It says: Mounting Root Read-only [Fail] and after that there are lots of errors like ..... : Read-only filesystem. When it gets to the login prompt, I can only log in as root not as an user and according to mount, root is mounted rw (but I cannot edit any file) and /boot and /home are not mounted at all. I use lvm2 inside a luks container, all partitions are formated as ext4 and the kernel line is linux /vmlinuz26 cryptdevice=/dev/sda2:enc resume=/dev/vg/swap root=/dev/vg/root rootflags=data=writeback ro quiet There are lots of differences between the old and the new image as one would expect, but I could not find anything obviously wrong. It's the same for both 2.6.32 and 2.6.33, by the way. I'm sorry I cannot provide anything better for now. Is there an option to make the initscripts more verbose? |
This task depends upon
Closed by Thomas Bächler (brain0)
Sunday, 07 February 2010, 21:00 GMT
Reason for closing: Fixed
Additional comments about closing: Thanks for the good investigation, fixed in the next release.
Sunday, 07 February 2010, 21:00 GMT
Reason for closing: Fixed
Additional comments about closing: Thanks for the good investigation, fixed in the next release.
[2010-02-07 15:12] starting full system upgrade
[2010-02-07 15:14] removed klibc-udev (141-4)
[2010-02-07 15:14] removed klibc-module-init-tools (3.8-2)
[2010-02-07 15:14] removed klibc-kbd (1.15.1-2)
[2010-02-07 15:14] removed klibc-extras (2.5-5)
[2010-02-07 15:14] removed klibc (1.5.15-4)
[2010-02-07 15:14] upgraded device-mapper (2.02.60-2 -> 2.02.60-3)
[2010-02-07 15:14] upgraded cryptsetup (1.1.0-1 -> 1.1.0-2)
[2010-02-07 15:14] installed mkinitcpio-busybox (1.15.3-4)
[2010-02-07 15:14] upgraded mkinitcpio (0.5.30-1 -> 0.5.99.3-1)
[2010-02-07 15:14] upgraded lvm2 (2.02.60-2 -> 2.02.60-3)
Make sure udev and initscripts are up to date, but they should be as the old lvm/dm/cryptsetup versions did work fine (did you ever reboot with the versions that were previously installed?). Actually, once your root is mounted and init is started, there should be no difference to what you had before, unless I screwed up one of the lvm/device-mapper/cryptsetup packages.
I'd also like to mention that I have the exact same setup and it was my primary testing ground for these things.
--add start
# fix if udev initialises /dev/mapper/control
sleep 0.5
--add stop
if [ -e "/sys/class/misc/device-mapper" ]; then
it's worth to try i added this in archboot hooks some time ago.
/dev/vg (I think you meant this folder) and /dev/mapper looks the same in either case. There are symlinks to ../dm-[0123], the control file in mapper and the dm-* block files also exist in /dev.
However, I found out a bit more. Actually, I can log in as user, but it fails on tty1, because startx fails (it cannot create a temporary file). Apparently, /home (and swap?) is mounted and writable even if it's not in /etc/mtab. I guess because of the read-only root.
To sum this up:
/ (ext4) is ro
/home (ext4) is rw
/tmp tmpfs is ro
And when I try to remount / as rw I get:
$ mount -o remount,rw /
mount: / not mounted already, or bad option
But I can definitely see root.
In /lib/initcpio/init, line 161 looks like:
mount ${fstype:+-t ${fstype}} -o ro "${root}" /new_root
replace it with:
mount ${fstype:+-t ${fstype}} -o ro${rootflags:+,${rootflags}} "${root}" /new_root
As always, keep a backup of a working mkinitcpio file before regenerating the image. (Maybe we should also parse the ro/rw stuff, I will have another look at mount options.)
And yes, you cannot set the data= option with remount on ext3/4, and it will fail, I should have caught that.
> And yes, you cannot set the data= option with remount on ext3/4, and it will fail, I should have caught that.
So it does not make sense to have the data option in root's fstab entry, right?
Anyway, this should be fixed now: http://projects.archlinux.org/mkinitcpio.git/commit/?h=kill-klibc&id=ba97db07a5bcbc5c0db2241a2f8ac4117d05c8f3