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
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by xduugu (xduugu) - Sunday, 07 February 2010, 15:31 GMT
Forgot to add that everything is up to date (lm2,device-mapper,cryptsetup).

[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)
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 15:58 GMT
Can you look inside /dev, please? I suspect that your /dev/vgname or /dev/mapper folder(s) lack the correct device nodes.

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.
Comment by Tobias Powalowski (tpowa) - Sunday, 07 February 2010, 16:21 GMT
just a guess, but could you try to add this to encrypt and lvm2 hook:
--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.
Comment by xduugu (xduugu) - Sunday, 07 February 2010, 16:28 GMT
udev and initscripts should be up-to-date (udev 151-2 and initscripts 2010.01-1) and yes, the previous lvm/dm/crytpsetup versions worked fine. I built several images and booted them.

/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.
Comment by xduugu (xduugu) - Sunday, 07 February 2010, 17:01 GMT
Adding sleep 0.5 after the modprobe line at the top did not change anything.

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.
Comment by xduugu (xduugu) - Sunday, 07 February 2010, 19:49 GMT
Just managed to find the culprit. Apparently, rootflags is not supported anymore. I found an init(?) message which said it mounted /dev/vg/root in ordered data mode instead of writeback. The problem was the fstab entry which also contained the data=writeback option and because of that root could not be remounted (bad option).
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 20:05 GMT
Oh. Okay - if rootflags was handled by kinit before, we need to respect that (shouldn't be hard). I was under the impression rootflags was handled by the kernel. Thanks for investigating, this might be a fix:

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.
Comment by xduugu (xduugu) - Sunday, 07 February 2010, 20:28 GMT
Your fix works, thanks.

> 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?
Comment by Thomas Bächler (brain0) - Sunday, 07 February 2010, 20:59 GMT

Loading...