Created attachment 411386 [details, diff] openrc-0.17_sysfsaufs-empty.patch On poweroff server with aufs-enabled kernel, if no aufs mounts exists at the time localmount service stops openrc produces the following error message (quoted example for modular build): > sed: can't read /sys/fs/aufs/config/br[0-9][0-9][0-9]: Not a directory > * Failed to remove branch from aufs The bug can be easely confirmed by: 1. Building aufs-supported kernel; 2. Boot into it (loading aufs module if needed); 3. Enable rc logging; 4. Reboot. After that you can analyse rc.log and see quoted (or similiar) error message. Attached patch fixes this issue. P.S. One more question: may be it isn't right to include into openrc's localmount service support of all local filesystems? This bug shows that it's enough to include just standard ones. Extending script just when needed, by appropriate USE flags or maybe USE_EXPAND. For particular example, adding support of aufs (sys-kernel/aufs-sources or sys-fs/aufs4 +kernel-patch) should require including aufs support in openrc (rebuilding sys-apps/openrc with proper setting of USE or USE_EXPAND).
(In reply to Sergey S. Starikoff from comment #0) > After that you can analyse rc.log and see quoted (or similiar) error message. When aufs is built as module, the quoted error will be displayed _always_ (on each power-off cycle with loaded aufs module).
@jlec: This bug is part of the below commit [1]. I could apply the above patch, but I have heard another opinion that this commit is not necessary at all for OpenRC and can be reverted since it does not provide any benefits during shutdown. Since you are the aufs maintainer, I am asking your opinion. Should I revert, or does OpenRC need special support for aufs? If OpenRC needs this support, is the correct action for me to apply this patch? Thanks, William [1] https://github.com/openrc/openrc/commit/ad770d73
confirmed here as well.
1. Why was the original patch needed at all? 2. I can confirm the problem. The original patch has the flaw that it assumes some mount point present. 3. the new patch looks good and works around the problem 4. Really needed, depends on 1.
Created attachment 412064 [details, diff] revert-aufs.patch This is the patch I would apply if we determine that the original was not needed. AUFS users: please apply this patch and let me know what it breaks, or why the original patch is needed.
(In reply to Justin Lecher from comment #4) > 1. Why was the original patch needed at all? from looks of it to remount with noxino option and to remove any branches on it. > 2. I can confirm the problem. The original patch has the flaw that it > assumes some mount point present. It assumes that /sys/fs/aufs/ contains directories but that's not the case if you don't boot with the aufs kernel option, so the first patch fixes this by checking for existence of directories in /sys/fs/aufs > 3. the new patch looks good and works around the problem New patch is not perfect since it still suffers from an assumption that /sys/fs/aufs/si_*/ contains directories like br1,br2,...,br100 but in the minimal iso case there are only br0 through br1. Either way, using br[0-9][0-9][0-9] is not going to evaluate anything br[0-9] so that's why we see the output as br[0-9][0-9][0-9] while shutting down. The only way I see getting around this and checking if br{0-100} is present is by using bashism or awk but I don't believe we allow this in openrc. > 4. Really needed, depends on 1. @Zero_Chaos I know you added br[0-9][0-9][0-9] for use in pentoo since lots of branches might be created that are greater than br[0-9] but for when it's not it doesn't work as expected. see attached screenshot. If we remove the extra two [0-9][0-9] it works but that is not what we want in the end.
Created attachment 412082 [details] shutdown screenshot. sed: can't read /sys/fs/aufs/si_5ec2677a/br[0-9][0-9][0-9]: No such file or directory.
From the comments in this bug, it sounds like this change supports a pentoo-specific configuration of aufs which does not work as expected in the general case. If that is the case, I don't feel it belongs in OpenRC upstream, so if folks do not object, I will revert this change. @zero_chaos: If you need this specifically in Pentoo for some reason, I'll help you come up with a way to do it. @jlec: You might want to work with @zero_chaos and go over how he is using aufs to find out why he needs this. What does everyone else think?
I received the same warning while shutting down a live Gentoo. I think that this cannot be done in "localmount", expecially if root is on aufs. I adapted the "cleanup" script from Slax to manage the shutdown sequence. I removed "mount-ro" and added my "unmountall" that calls my last script "cleandie" (cleanup renamed)[1]. The idea behind this is to build a tmpfs root, pivot_root there and then use "telinit u" to free init image on the real root: the new init image will be the script itself, and init will be fooled. After rexecuting as PID 1 it can unmount every mounted fs. I used a simple tac on /proc/mounts, assuming that inverting the order would be sufficient to avoid nested mount dependency. Andrea Zuccherelli [1] http://sourceforge.net/p/lxlivescripts/code/ci/zlive/tree/initrd/cleandie
(In reply to Andrea Zuccherelli from comment #9) > I received the same warning while shutting down a live Gentoo. > I think that this cannot be done in "localmount", expecially if root is on > aufs. > > I adapted the "cleanup" script from Slax to manage the shutdown sequence. > I removed "mount-ro" and added my "unmountall" that calls my last script > "cleandie" (cleanup renamed)[1]. > > The idea behind this is to build a tmpfs root, pivot_root there and then use > "telinit u" to free init image on the real root: the new init image will be > the script itself, and init will be fooled. > After rexecuting as PID 1 it can unmount every mounted fs. > I used a simple tac on /proc/mounts, assuming that inverting the order would > be sufficient to avoid nested mount dependency. > > > Andrea Zuccherelli > > [1] http://sourceforge.net/p/lxlivescripts/code/ci/zlive/tree/initrd/cleandie That sounds interesting. Could attach a working init script or code snipplet which work for Gentoo?
(In reply to Andrea Zuccherelli from comment #9) > I received the same warning while shutting down a live Gentoo. > I think that this cannot be done in "localmount", expecially if root is on > aufs. AFAIR / is the last unmounted FS, so I'm not shure you are right. Could you show aufs mounts before shutting down? $ mount | grep aufs
(In reply to Sergey S. Starikoff from comment #11) > > AFAIR / is the last unmounted FS, so I'm not shure you are right. > > Could you show aufs mounts before shutting down? > $ mount | grep aufs Attached will be a minimaliso boot with default boot options and one with "aufs" appended to kernel line. You'll notice that "/" is in fact mounted as AUFS and this is why we don't have a clean umount. I haven't looked at the script posted above but it might be what will be required for AUFS mounted /'s. When shutting down with a livecd that boots with "gentoo aufs" the output is: * Remounting remaing filesystems read-only ... * Remounting /mnt/aufs-rw-branch read only ... * in use but fuser finds nothing * Remounting /.unions/memory read only ... * in use but fuser finds nothing * Remounting /mnt/cdrom read only ... * in use but fuser finds nothing * ERROR: mount-ro failed to start Notice that the last 3 lines above are what you get even when "gentoo aufs" is not used. We really do need a clean umount of the aufs / mounts.
Created attachment 412096 [details] with 'gentoo aufs' boot option
Created attachment 412098 [details] without 'aufs' boot option
Created attachment 412126 [details] unmount-all: mount-ro replacement This is the last script i use to replace mount-ro. Note that this just calls cleandie which does the real root unmount and shutdown.
Created attachment 412134 [details] cleandie: old cleanup script from Slax rewritten This is the script I use to shutdown the live Gentoo. This differs from the one on the repository: I added some lines to make console output more verbose.
Created attachment 412136 [details] unmount-all: shutdown screenshot #0 This is the first of three screenshots that shows shutdown sequence using unmount-all and cleandie. No patch to localmount applied. Here you can see the output of "mount|grep aufs" added to cleandie before root pivoting. There is no "aufs boot option": the live system is booted through a fork of Linux live scripts that I borrowed from Slax about four years ago.
Created attachment 412138 [details] unmount-all: shutdown screenshot #1 This is the second of three screenshots that shows shutdown sequence using unmount-all and cleandie. Here you can see the output of "cat /proc/mounts >/dev/console" (cleandie line 90). This outputs a lot of noise due to the many aufs branches composing my root. Each branch uses a squashfs mount from a *.lzm file. Note that the root has been pivoted: the old / resides now in /memory/union.
Created attachment 412140 [details] unmount-all: shutdown screenshot #2 This is the last of three screenshots that shows shutdown sequence using unmount-all and cleandie. In the screenshot look at the lines after "Cleandie: after unmounting these are my mounts". Again this is the ouptput of "cat /proc/mounts >/dev/console" but later (cleandie line 112), after old aufs root branches have been unmounted, any loop device that was used has been closed, and at last "/memory/union" the old aufs root unmounted. Here there is only one real fs left to unmount: /dev/sda1, the USB stick where *.lzm resides. The script tries to unmount this (any fs under /memory), check that there is anything else last to unmount and then poweroff or reboot.
(In reply to Fernando (likewhoa) from comment #6) > @Zero_Chaos I know you added br[0-9][0-9][0-9] for use in pentoo since lots > of branches might be created that are greater than br[0-9] but for when it's > not it doesn't work as expected. see attached screenshot. If we remove the > extra two [0-9][0-9] it works but that is not what we want in the end. So do we really need to do it that way? How about simply "..../br*"?
Thanks Andrea for this lengthy explanation and description. I have the feeling, that we should move the whole unmounting on live cd to an extra package and not including this option into standard openrc. Perhaps you can work together with the livecd and ZeroChaos to make some sort of package out of it.
(In reply to Justin Lecher from comment #21) > Thanks Andrea for this lengthy explanation and description. I have the > feeling, that we should move the whole unmounting on live cd to an extra > package and not including this option into standard openrc. Perhaps you can > work together with the livecd and ZeroChaos to make some sort of package out > of it. This might fit best inside genkernel as the revelant AUFS code is included in there. It would not fit in livecd-tools or aufs-utils afraik, so only other place would be it's own package but that seems overkill. Going to be testing this on my minimal iso now.
(In reply to Andrea Zuccherelli from comment #19) > Created attachment 412140 [details] > unmount-all: shutdown screenshot #2 > > This is the last of three screenshots that shows shutdown sequence using > unmount-all and cleandie. > A few issues with this which prevents us from testing. 1. The script sources "/usr/lib/liblinuxlive" which seems to related to the SLAX distribution. 2. You have a variable called "$INITRAMDISK" which is not available to us. 3. init script assumes $INITRAMDISK/initrd/bin is available With regards to the cleandie script, I see a several issues as well. 1. /mnt/live is not available and thus script will fail to cd into this directory since it assumes the directory exists 2. The telinit command probably is a function inside /usr/lib/liblinuxlive 3. The script should be using while loop differently. i.e 'while read line; do ...;done < <(command)' instead of 'command | while read line; do ...;done' 4. the command "losetup -a | cut -d : -f 1 | xargs -n 1 losetup -d" can be replace with "losetup -D" 5. /memory/data is another non-existing directory 6. findsubmnt is another function provided by /usr/lib/liblinuxlive maybe. This is just a quick assessment of the script which needs some coding style changes and integration of missing functions, either way it would need to be ported for it to work with out current environment and AUFS layout.
(In reply to Justin Lecher from comment #20) > (In reply to Fernando (likewhoa) from comment #6) > > @Zero_Chaos I know you added br[0-9][0-9][0-9] for use in pentoo since lots > > of branches might be created that are greater than br[0-9] but for when it's > > not it doesn't work as expected. see attached screenshot. If we remove the > > extra two [0-9][0-9] it works but that is not what we want in the end. > > So do we really need to do it that way? How about simply "..../br*"? We can't use /sys/fs/aufs/*/br* because some are named br[a-z] so we actually just want anything br[0-100] which is actually what will work instead of using br[0-9][0-9][0-9] which will not evaluate when br[0-1] is available. Attached is with this change.
Ignore my last comment regarding br[0-100] as this will only show br{0,1},br{10..19} and br100. The only way i see it working is with extglobs enabled. i.e shopt -s extglob && for i in /sys/fs/aufs/*/br*([0-9]); do ...;done but this is not something we can include in openrc.
(In reply to Fernando (likewhoa) from comment #23) > (In reply to Andrea Zuccherelli from comment #19) > > This is just a quick assessment of the script which needs some coding style > changes and integration of missing functions, either way it would need to be > ported for it to work with out current environment and AUFS layout. I think that genkernel or an adhoc package is not a good idea. Mounting and unmountig should be init scripts job or not? I wrote those scripts because Gentoo openrc could not cleanly unmount AUFS. But the fact that is AUFS or any other fs type should make no difference. Hence I tried to keep them fs type agnostic, with no AUFS dependency. I remeber to have read this short article by Tomas (Slax) some years ago: http://www.slax.org/lt/blog/18797-Cleanup-script-updates.html The ideas are not just my own and this is not all my own work. Now, for the first set of issues: 1. /usr/lib/liblinuxlive: This file is the a set of functions written by Tomas M. for Slax. It is copied by linuxrc in the initramfs to the the live system before it starts. You can find it here: http://sourceforge.net/p/lxlivescripts/code/ci/zlive/tree/tools/liblinuxlive 2. $INITRAMDISK: This is defined when liblinuxlive is sourced. Its value should be mnt/live. 3. mnt/live/initrd/bin is created by linuxrc. For the second set: 1. Instead of /mnt/live I could have used /$INITRAMDISK but in ash I had some problems to source liblinuxlive. 2. /sbin/telinit belongs to sys-apps/sysvinit. My version is 2.88-r7. This package is required by openrc if kernel_linux use flag is true. 3. /bin/ash is run through busybox. The link is created by unmount-all. Trying: "busybox ash -c '(while read LINE; do echo $LINE; done)< <(cat /proc/mounts)'" gives: "ash: syntax error: unexpected redirection" where: "bash -c '(while read LINE; do echo $LINE; done)< <(cat /proc/mounts)'" works as expected. 4. I would like "losetup -D", but busybox losetup applet has no such option. 5. I think you can ignore /memory/data. This is used to define $DEVICE, that is the USB stick/CDROM where the live system started from: if DEVICE is a CDROM it is ejected. 6. findsubmnt: http://sourceforge.net/p/lxlivescripts/code/ci/zlive/tree/initrd/rootfs/bin/findsubmnt You can find the root of the repository here: http://sourceforge.net/p/lxlivescripts/code/ci/zlive/tree/
Ping, where are we on this bug? Should I revert the aufs handling we currently have in OpenRC (comment #5)? Is there something else I should apply to OpenRC instead?
(In reply to William Hubbs from comment #27) > Ping, where are we on this bug? Should I revert the aufs handling we > currently have in OpenRC (comment #5)? Is there something else I should > apply to OpenRC instead? I would reserve it as it's not working 100%. We now just need to implement the SlaX code in a new package or implement it in an existing package like perhaps genkernel or aufs-utils. discuss?
until we have something better, I suggest we keep this code in openrc. I also really do not like putting it in livecd-tools as aufs can be used outside of a livecd. If anything, we can create a new package perhaps?
(In reply to Rick Farina (Zero_Chaos) from comment #29) > until we have something better, I suggest we keep this code in openrc. > > I also really do not like putting it in livecd-tools as aufs can be used > outside of a livecd. If anything, we can create a new package perhaps? A new package sounds like a good idea but it would have to implement some of the code above.
Concerning unmounting why AUFS would be so different from any other fs to deserve its own package? I cheer to remove old Linux school remounting read only philosophy (mount-ro) from OpenRC. In the beginning nothing was mounted so unmounting all it's better!
(In reply to Fernando (likewhoa) from comment #28) > (In reply to William Hubbs from comment #27) > > Ping, where are we on this bug? Should I revert the aufs handling we > > currently have in OpenRC (comment #5)? Is there something else I should > > apply to OpenRC instead? > > I would reserve it as it's not working 100%. We now just need to implement > the SlaX code in a new package or implement it in an existing package like > perhaps genkernel or aufs-utils. discuss? I'm with you on this, it seems to only be written for a specific use case.
(In reply to Andrea Zuccherelli from comment #31) > Concerning unmounting why AUFS would be so different from any other fs to > deserve its own package? > > I cheer to remove old Linux school remounting read only philosophy > (mount-ro) from OpenRC. > > In the beginning nothing was mounted so unmounting all it's better! I have always wondered why we remount everything read-only at the end. Is there some reason we do it that way? If not, I would be open to removing mount-ro.
(In reply to William Hubbs from comment #33) > > I have always wondered why we remount everything read-only at the end. Is > there some reason we do it that way? If not, I would be open to removing > mount-ro. It's a safety measure to avoid file system corruption, and should not be removed. (If unmounting fails, at least flush all buffers and set filesystem ro. Then it will be clean on reboot.)
(In reply to William Hubbs from comment #33) > I have always wondered why we remount everything read-only at the end. Is > there some reason we do it that way? If not, I would be open to removing > mount-ro. Nothing wonderful. $ which umount /bin/umount So, using umount utility remount read-only is the only safe thing we can do at least for / on ordinar installation (skipping errors check is not a right thing). Also I guess, that without specially prepared initramfs image this umount will be the last thing we can do. So, this (clean umount for everything) could be used only at live CD image. I'm wondering about those, who uses live CD's doesn't matter about aufs handling: It _is_ writebale. But on each power-off cycle all possible changes are lost. So, live CD users should either care about proper check changes and update of source image (so, aufs should be handled by some special init script) or use something like shuashfs for / (write access is needed only for /var, /tmp and /home, workaroud in usind aufs for complete / is the easiest, but not completely right thing).
(In reply to Sergey S. Starikoff from comment #35) > (In reply to William Hubbs from comment #33) > > I have always wondered why we remount everything read-only at the end. Is > > there some reason we do it that way? If not, I would be open to removing > > mount-ro. > > Nothing wonderful. > $ which umount > /bin/umount > So, using umount utility remount read-only is the only safe thing we can do > at least for / on ordinar installation (skipping errors check is not a right > thing). > Also I guess, that without specially prepared initramfs image this umount > will be the last thing we can do. > > So, this (clean umount for everything) could be used only at live CD image. > > I'm wondering about those, who uses live CD's doesn't matter about aufs > handling: > It _is_ writebale. But on each power-off cycle all possible changes are lost. There are two advantages of using a union style filesystems with a livecd, one is that you're able to write on top of the read-only squashfs or any other read-only image and the other is to allow these changes to persist on reboots hence why we need a clean unmount of all union fs style branches. > So, live CD users should either care about proper check changes and update > of source image (so, aufs should be handled by some special init script) This is the plan to create a new package that will have a custom shutdown script which will perform a clean shutdown on all union filesystems not just aufs but also overlayfs etc. > or > use something like shuashfs for / (write access is needed only for /var, > /tmp and /home, workaroud in usind aufs for complete / is the easiest, but > not completely right thing). I don't see anything wrong with using a union filesystems for / as this will allow users who download our media to modify it as they please. I.E install missing packages on the fly and or enable a certain kernel module or update one like I had to do with current livedvd in which I updated the ZFS modules. What we need is to possibly get rid of the mount-ro init script or (which was agreed upon above) implement the SlaX clean shutdown method for use with our livecd media. I am not sure about the former.
(In reply to Fernando (likewhoa) from comment #36) > (In reply to Sergey S. Starikoff from comment #35) > > (In reply to William Hubbs from comment #33) > > > I have always wondered why we remount everything read-only at the end. Is > > > there some reason we do it that way? If not, I would be open to removing > > > mount-ro. > > > > Nothing wonderful. > > $ which umount > > /bin/umount > > So, using umount utility remount read-only is the only safe thing we can do > > at least for / on ordinar installation (skipping errors check is not a right > > thing). > > Also I guess, that without specially prepared initramfs image this umount > > will be the last thing we can do. > > > > So, this (clean umount for everything) could be used only at live CD image. > > > > I'm wondering about those, who uses live CD's doesn't matter about aufs > > handling: > > It _is_ writebale. But on each power-off cycle all possible changes are lost. > > There are two advantages of using a union style filesystems with a livecd, > one is that you're able to write on top of the read-only squashfs or any > other read-only image and the other is to allow these changes to persist on > reboots hence why we need a clean unmount of all union fs style branches. > > > So, live CD users should either care about proper check changes and update > > of source image (so, aufs should be handled by some special init script) > > This is the plan to create a new package that will have a custom shutdown > script which will perform a clean shutdown on all union filesystems not just > aufs but also overlayfs etc. I do not at all have a problem with having a clean shutdown script in OpenRC that works for all union file systems. If it can't be generic, I would prefer to support overlayfs over aufs since overlayfs is part of the Linux kernel. > > or > > use something like shuashfs for / (write access is needed only for /var, > > /tmp and /home, workaroud in usind aufs for complete / is the easiest, but > > not completely right thing). > > I don't see anything wrong with using a union filesystems for / as this will > allow users who download our media to modify it as they please. I.E install > missing packages on the fly and or enable a certain kernel module or update > one like I had to do with current livedvd in which I updated the ZFS > modules. > > What we need is to possibly get rid of the mount-ro init script or (which > was agreed upon above) implement the SlaX clean shutdown method for use with > our livecd media. I am not sure about the former. It looks like we have some concern about getting rid of mount-ro (comment #34 and this message [1]). Another option would be for me to configure things in the shutdown runlevel so that mount-ro can be turned off. (While I'm at it I'll probably do the same with killprocs). [1] https://archives.gentoo.org/gentoo-dev/message/c1e0235dec7b08ed994217ef26296036
(In reply to William Hubbs from comment #37) > I do not at all have a problem with having a clean shutdown script in OpenRC > that works for all union file systems. > > If it can't be generic, I would prefer to support overlayfs over aufs since > overlayfs is part of the Linux kernel. it is likely important to note that genkernel supports aufs at this time and not overlayfs. Also important to note that the gentoo livedvd uses aufs. tl;dr don't kill aufs, let's work on fixing it or obsoleting it.
(In reply to Rick Farina (Zero_Chaos) from comment #38) > (In reply to William Hubbs from comment #37) > > I do not at all have a problem with having a clean shutdown script in OpenRC > > that works for all union file systems. > > > > If it can't be generic, I would prefer to support overlayfs over aufs since > > overlayfs is part of the Linux kernel. > > it is likely important to note that genkernel supports aufs at this time and > not overlayfs. Also important to note that the gentoo livedvd uses aufs. I get the impression that it wouldn't affect the Gentoo livecd if I revert this, especially since @likewhoa is also recommending that I revert (see comment #28). Also, @jlec, the aufs maintainer doesn't seem to think this belongs in OpenRC (see comment #21). > tl;dr don't kill aufs, let's work on fixing it or obsoleting it. I'm not advocating killing aufs. I am advocating that either a generic unionfs solution goes in OpenRC, or overlayfs support goes in OpenRC. If I were developing a LiveCD, I would probably look heavily into using overlayfs since it doesn't require an out-of-tree module.
(In reply to William Hubbs from comment #37) > Another option would be for me to configure things in the shutdown runlevel > so that mount-ro can be turned off. (While I'm at it I'll probably do the > same with killprocs). This is already possible. On a live media, you can create an entirely custom shutdown runlevel if you want by removing the OpenRC default services from the shutdown runlevel and adding your own.
(In reply to William Hubbs from comment #40) > I get the impression that it wouldn't affect the Gentoo livecd if I revert > this, especially since @likewhoa is also recommending that I revert (see > comment #28). Also, @jlec, the aufs maintainer doesn't seem to think this > belongs in OpenRC (see comment #21). Gentoo livecd doesn't use aufs, gentoo livedvd (from likewhoa) does. Wouldn't it be vastly more proper to fix this with the original patch rather than revert the handling entirely due to a minor bug? https://bugs.gentoo.org/attachment.cgi?id=411386
(In reply to Rick Farina (Zero_Chaos) from comment #41) > (In reply to William Hubbs from comment #40) > > > I get the impression that it wouldn't affect the Gentoo livecd if I revert > > this, especially since @likewhoa is also recommending that I revert (see > > comment #28). Also, @jlec, the aufs maintainer doesn't seem to think this > > belongs in OpenRC (see comment #21). > > Gentoo livecd doesn't use aufs, gentoo livedvd (from likewhoa) does. > > Wouldn't it be vastly more proper to fix this with the original patch rather > than revert the handling entirely due to a minor bug? > > https://bugs.gentoo.org/attachment.cgi?id=411386 See comment #6. Likewhoa points out that the original patch has issues.
(In reply to Rick Farina (Zero_Chaos) from comment #41) > > Gentoo livecd doesn't use aufs, gentoo livedvd (from likewhoa) does. > > Wouldn't it be vastly more proper to fix this with the original patch rather > than revert the handling entirely due to a minor bug? > > https://bugs.gentoo.org/attachment.cgi?id=411386 The minimalcds won't suffer from this since AUFS is not part of the builds, but the livedvd will since you'll run into the sed error shown on comment #7 even with patch which checks for "si_*" directories, so patch is not totally fixing the issue just avoiding the sed error on non aufs kernels.
(In reply to William Hubbs from comment #42) > See comment #6. Likewhoa points out that the original patch has issues. Don't forget to verify the opinion. (In reply to Fernando (likewhoa) from comment #6) > It assumes that /sys/fs/aufs/ contains directories but that's not the case > if you don't boot with the aufs kernel option, so the first patch fixes this > by checking for existence of directories in /sys/fs/aufs Neither more than current stable release of OpenRC with booted sys-kernel/gentoo-sources kernel without sys-fs/aufs{3,4}[kernel-patch] module. The aufs-specific patch code works inside the following condition: /etc/init.d/localmount: … if [ "$RC_UNAME" = Linux ] && [ -d /sys/fs/aufs ] ; then … and only here works code from patch. Althoug it leads to more common question of openrc handlink booted-kernel unknown filesystems.
(In reply to Sergey S. Starikoff from comment #44) > The aufs-specific patch code works inside the following condition: > > /etc/init.d/localmount: > … > if [ "$RC_UNAME" = Linux ] && [ -d /sys/fs/aufs ] ; then > … > and only here works code from patch. > > Althoug it leads to more common question of openrc handlink booted-kernel > unknown filesystems. The above condition can be avoided "CONFIG_AUFS_FS=y" is build as a module otherwise the statement is true.(In reply to Sergey S. Starikoff from comment #44) > (In reply to William Hubbs from comment #42) > > See comment #6. Likewhoa points out that the original patch has issues. > > Don't forget to verify the opinion. > > (In reply to Fernando (likewhoa) from comment #6) > > It assumes that /sys/fs/aufs/ contains directories but that's not the case > > if you don't boot with the aufs kernel option, so the first patch fixes this > > by checking for existence of directories in /sys/fs/aufs > > Neither more than current stable release of OpenRC with booted > sys-kernel/gentoo-sources kernel without sys-fs/aufs{3,4}[kernel-patch] > module. > The aufs-specific patch code works inside the following condition: > > /etc/init.d/localmount: > … > if [ "$RC_UNAME" = Linux ] && [ -d /sys/fs/aufs ] ; then > … > and only here works code from patch. > > Althoug it leads to more common question of openrc handlink booted-kernel > unknown filesystems. Yes but even when the above condition is true, the code fails at "for x in $aufs_si_dir/br[0-9][0-9][0-9]; do" because this only evaluates for br{100..999} when in fact it should work for br{0..999}. $ touch br{0..10} $ ls br0 br1 br10 br2 br3 br4 br5 br6 br7 br8 br9 $ for x in br[0-9][0-9][0-9]; do echo $x;done br[0-9][0-9][0-9] $ touch br{10..100} $ for x in br[0-9][0-9][0-9]; do echo $x;done br100 $ touch br{100..105} $ for x in br[0-9][0-9][0-9]; do echo $x;done br100 br101 br102 br103 br104 br105 For the livedvd and for the minimalcd by default it will only have br0 and br1 branches but genkernel has support for more branches so if we want to support them we need to fix the patch as a whole not just have it working half way because now we still run into the original sed error that started this bug report which causes a dirty shutdown when using a aufs supported kernel. I do agree that we need to have generic support for union filesystems and not just AUFS but also overlayfs since that's in the mainline kernel. I will work on adding overlayfs support soon enough into genkernel.
s there a way to tell what the aufs branches are from the contents of /proc/self/mounts?
Ian found a way to clean up the aufs branch checks so that they work for all branches that have one to three digits in their names. His patch is in commit b86d170. This will be in openrc-0.18.
I have not tested the patch yet, but reading AUFS man page about branch del option: "If a process is referencing the file/directory on the deleting branch (by open, mmap, current working directory, etc.), aufs will return an error EBUSY. In this case, a script ’aubusy’ (in aufs-util.git and aufs2-util.git) is useful to identify which process (and which file) makes the branch busy." At least the init process uses some of the branches and removing such branches will fail. After that remounting the AUFS root RO will succeed, but what about the still mounted CD or USB stick? Will it be be safe to eject/remove then?
