Talk:Early Userspace Mounting

Should this be expanded to include /usr on LVM on kernel raid? or is the original author of the opinion that such an initramfs would no longer be basic?

I'm offering to do the required edits when I update my system to udev-181 again. I've already been there once and broke it.
 * Please do. You can even remove 'basic' from the title if you want. The main goal was to provide a manual and concrete way to solve a specific problem. /Netfab 09:08, 20 March 2012 (UTC)


 * Should maybe note that the unoffical wiki has a Initramfs article that's just gold. /Ni1s 21:53, 19 March 2012 (UTC)
 * Yeah true. You may notice it is linked at the end. But this page seems also somewhat complex for someone who never heard about initramfs. /Netfab 09:08, 20 March 2012 (UTC)
 * How about Early Userspace Mounting? This may be a "basic" initramfs article, bit I'm pretty sure the article already goes beyond the "basics" of linux fiddlage. /Ni1s 16:54, 20 March 2012 (UTC)
 * Maybe. But the initramfs could also mount /var. /Netfab 11:17, 27 March 2012 (UTC)

static busybox ?
@Ni1s: In your previous modification, you changed the article by saying that static busybox is required. But no. static busysbox is not required. If you emerge it with the static useflag on, the generated initramfs is even bigger : most of the required libraries for a dynamically linked busybox are anyway required by /sbin/fsck{.ext4}. /Netfab 11:17, 27 March 2012 (UTC)
 * True, its not required to use a statically compiled busybox. I though simplicity was preferred there over the initramfs size. But as you say, if they are needed anyway, busybox might as well use them.

blkid and busybox mount and who should fsck
1) You don't need that if [ $type == "LABEL" ] with busybox mount. You can just use mount LABEL=abc /abc. The mount command will handle LABEL=abc just as it would /dev/sdaXX. (it's logical of them to handle it, since busybox also has the blkid command in it).

I think it's simpler and more data-driven having an ad-hoc fstab with only /, /usr and /var and then just doing: fsck -A mount -a

2) I really came here searching for ideas. I would like to avoid having fsck.ext4 in the initramfs to have an initramfs with a longer life. I wish I could just mount /, /usr and /var readonly and then Gentoo's init scripts would do the rest. Unfortunatelly, /etc/init.d/root really handles only root and localmount does not remount the file systems read only.

Wouldn't it be nicer and more generic if localmount would remount any file system which was already mounted to match the options in the fstab, instead of root being a special case?

Thanks anyway, you confirmed my impression that I really had to embed fsck.ext4 in the initramfs for now.


 * see bug #401573 and corresponding git commit : this will be the case in >=openrc-0.9.9, but I'm just waiting for this package to be stabilized to make the changes (btw I'm in stable tree). /Netfab 11:02, 1 April 2012 (UTC)

I think there is a reference to an uninitialized variable
I came across this when I needed an initramfs system to mount /usr as my /usr always resides on a separate (LVM) partition on my gentoo system - works very well with a few minor changes to cater for my LVM system.

Now my question is about the following line after the comment that suggests to use "our own fsck": /sbin/fsck ${fsck_args--p} $fsck_opts $1

I guess because fsck_args is actually never initialized throughout the script it could be dropped from the command line which then could just read as follows: /sbin/fsck -p $fsck_opts $1
 * Thanks for catching this, I removed fsck_args. /Ni1s 22:42, 10 April 2012 (UTC)

Adding lvm on raid?
It seems like a long time ago now, I offered to add lvm on raid to this page. However, I've ended up with someting quite different. The systems I've tested on are all 64 bit /no-multilib/. Large chunks of this article would need to be rewritten and then it won't work on 32 bit systems. For now, my setups are on the forums at http://forums.gentoo.org/viewtopic-t-920644-highlight-.html. I may xmlify that post and put it on my devspace but if someone with more wiki skills than me wants to do a merge, please do.--NeddySeagoon 10:22, 22 April 2012 (UTC)

Wait period and retrying uuidlabel_root?
I noticed that this worked flawlessly out of the box on 3.4.2 but failed miserably on 3.5.4 during boot. I suspect perhaps it has something to do with me fiddling with the timer_res ? In any case, the /dev/sda1 device is not created quick enough so that when uuid_labelroot is called, it will fail miserably as mount cannot mount the nonexistant device /dev/sda1 to /mnt/root. However, shortly after dropping into a rescue shell, the device is created. I fixed this by trying uuid_labelroot and if it fails, to sleep for 5 seconds and try again for a maximum of 5 tries before dumping into a rescue shell.