unionfs as rootfs - help please

ichbinsisyphos · Guru Joined: 08 Dec 2006 Posts: 547

yeah, i thought, since you only want to prevent corruption and i dont think many files are updated at boot, it might not be worth the hassle.

if you still have problems with checkroot and checkfs: you can create a file /fastboot. that way it skips fscking at boot time. you will need to create it everytime, since checkfs removes the file. its common to put

mem_gentoo · n00b Joined: 27 Apr 2007 Posts: 27

I did something like that, If i recall I just gutted the checkfs script (its all stubs) along with any other disk checking scripts that were giving me grief.

nativemad · Posted: Thu Jul 19, 2007 5:24 am Post subject:

ichbinsisyphos · Guru Joined: 08 Dec 2006 Posts: 547

casso · Posted: Wed Aug 01, 2007 10:28 am Post subject: Unmount notes about UnionFS

I thought I would have been notified about further updates to this post, but I was wrong. I wish I had have known earlier about RC_NO_UMOUNTS and RC_NO_UMOUNT_FS variables. These variables can be set inside of /etc/conf.d/rc (although they aren't listed) instead of editing /etc/init.d/halt.sh

The following is what I learnt from my experience with UnionFS when it came to reboots/shutdowns. I'm sorry if this is repeated, I just want to make it as clear as possible to others. Please note, my fstab line works just fine, and avoids any filesystem checks: "unionfs / unionfs defaults 0 0"

I originally had the following mounts as shown below. I also did not include unionfs userspace tools in my system because I didn't think I would need them. Newroot listed below becomes / when init is started.
MOUNTS INSIDE EARLY USERSPACE
/dev/ro_device /ro_root
/dev/rw_device /rw_root
mount -nt unionfs -o dirs=/rw_root=rw:/ro_root=ro unionfs /newroot

The script /etc/init.d/halt.sh is mainly concerned with unmounting filesystems, and remounting read-only those it cannot unmount. It does a few other things too, but lets concentrate on its unmount capabilities. By default, if we are a live-cd, then several mount points are listed in another script that will not be unmounted. If we are not a live-cd, then we default to /mnt/tmp/livecd and /newroot. This is stored in variable RC_NO_UMOUNTS. The variable RC_NO_UMOUNT_FS lists unionfs, proc and tmpfs (apart from others) as filesystems that will not be unmounted. These variables are subject to change, but it is a safe bet that /newroot will always be listed, as will unionfs. The script uses /proc/mounts to check which filesystems and mount points there are.

In my case, my /newroot directory will never be unmounted because it is unionfs for one, and because it is called newroot. However, the unionfs test is done using /sbin/unionctl (which may be a symlink to /usr/sbin/unionctl). If this binary is missing, you will notice at startup that Gentoo will attempt to remount your / filesystem read-only, and of course fail. It will also fail to check at shutdown if a filesystem is unionfs or not.

As for my other two mounts, the rw_root will not hurt if it is unmounted, since no more writing needs to be done. If however a file needed by the shutdown scripts (like sync) is required still, and it is not in the ro_root, it will fail. So far for me, things are okay. The ro_root directory contains all the running code needed to complete the shutdown, including all system libraries. Even though newroot and / will not be unmounted, ro_root at this point in the shutdown is just as good as / or newroot. The script just pulled the rug out from under itself by unmounting ro_root and the shutdown process failed.

My suggestions to avoid this would be:

This will save you having to make edits to any rc scripts to allow a successful shutdown. You can still change the RC_NO_UMOUNTS and RC_NO_UMOUNT_FS variables if you wish, this is just my input to avoid it while still being functional. If pivot_root is used, /newroot becomes /initrd/newroot, and you will most likely need to add the variable RC_NO_UMOUNTS to /etc/conf.d/rc with appropriate values listed
_________________
Need assistance with any of the following? Just PM me and I will see what I can do

LDAP, Kerberos , SSH, Samba, PPP, DHCP, NTP, autofs, CUPS

casso · Posted: Wed Aug 27, 2008 12:46 am Post subject: Testing this solution

Hi,
has anyone tested my suggestions for getting UnionFS and a production system working together? I would like to know and additionally ask the originator of this thread to mark it as solved if this solution works.

Regards,
casso
_________________
Need assistance with any of the following? Just PM me and I will see what I can do

LDAP, Kerberos , SSH, Samba, PPP, DHCP, NTP, autofs, CUPS