On 05/17/2012 09:52 AM, Tomas M wrote: > Hello Ben, > > I am not following the list closely, but I noticed you are having > troubles unmounting your fs, which is an aufs branch. > > Here are few notes: > > - I think you're using aufs as root filesystem. A root filesystem > can't be unmounted, only remounted read-only (which is enough) > > - as Junjiro explained, you have to (first) remount all aufs branches > ro, and then all underlaying mountpoints ro
Yes, but this step fails..see below. > - if you reboot without remounting your USB ro, then you'll get data > corruption, as you probably experienced > > - a filesystem (any filesystem, including your /cow) can be remounted > readonly ONLY if there are no files open from it That seems to be the problem. > - if I remember correctly, aufs uses XINO file, which is a hidden file > on your first writable branch. If your first writable branch is your > /cow then even if you remount your aufs ro, the xino file remains open > and your /cow can't be remounted ro Yes, the xino is stored on the /cow. I think other things are probably using /cow as well since *any* modified files are automatically put on the /cow. Maybe after setting / to (ro), I should attempt to disable the xino file somehow? > > Suggestions: > > 1) when you mount your aufs, set XINO path somewhere in tmpfs in > memory, instead of on your /cow filesystem > > 2) If you have problems remounting /cow readonly, eg. your mountpoint > still remains rw even after remount, then you may use lsof to see > which files are open on your mountpoint, disallowing it to go > read-only. This will give you information why your mountpoint can't be > remounted ro. > > 3) if you are using /bin/init to startup your system on aufs, then > even the init binary may have some files opened on your aufs. In this > case you'll need to re-execute the init from somewhere else. This is > tricky part, I did it in Slax by switch_root. Let me know if you think > this is your case so I could perhaps explain in more detail if you > need. > > 4) do not use 2>/dev/null redirection of stderr output - rather > analyze the error output of your remount commands The /cow is definitely in use...for one thing, the modified 'umountroot' I was hacking on is saved on /cow. Init is probably using it as well. fuser shows no users on /cow, for what that's worth..but I assume it just doesn't understand what is going on... It would seem to me that we should be able to force aufs to take its /cow rw branch to ro, even if that means nothing can write after that. The system is shutting down, after all..and the aufs mount (/) is already set to (ro), so nothing should expect to write to the file-system anyway. Otherwise, it is basically impossible to safely use /aufs as root file system with persistent /cow storage, as far as I can see. Thanks, Ben > > > Tomas M > slax.org > > > > > On Thu, May 17, 2012 at 6:16 PM, Ben Greear<gree...@candelatech.com> wrote: >> On 05/17/2012 12:47 AM, sf...@users.sourceforge.net wrote: >>>> Ben Greear: >>>>> What is the proper way to clean this all up on reboot >>>>> so that /cow is properly flushed and un-mounted (and >>>>> thus clean for mount on startup w/out having to fsck it)? >>>>> >>>>> I tried hacking the 'umountroot' script that is supposed >>>>> to make / mounted (ro), by adding >>>>> >>>>> mount -o remount,del:/cow / after it was (ro), >>>>> but that doesn't seem to work. >>>> >>>> I am afraid you might be still misunderstanding. >>>> As well as you cannot unmount the root dir, you cannot remove last >>>> branch from aufs. >>>> Setting RO is the substitution of unmounting. If you set the aufs branch >>>> as RO, you don't have to unmount it anymore. >>> >>> I should be more precise. >>> "Setting RO" means both of these. >>> - for aufs, "remount,mod:/brabra=ro" >>> - for native fs, "remount,ro" >> >> I tried to set it ro in both ways, and it appears neither work. >> Here is the code I am using. When I do that last 'cat /proc/mounts', >> /cow is still mounted (rw), and if you fsck the backing store >> for /cow on the next bootup, it is dirty. >> >> I can upload an image that you can dd to a usb drive to >> test this yourself if you wish. >> >> MOUNT_FORCE_OPT= >> [ "$(uname -s)" = "GNU/kFreeBSD" ]&& MOUNT_FORCE_OPT=-f >> # This: >> # mount -n -o remount,ro / >> # will act on a bind mount of / if there is one. >> # See #339023 and the comment in checkroot.sh >> sync >> set -x >> auplink / flush >> mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / >> 2>/dev/null \ >> || mount $MOUNT_FORCE_OPT -n -o remount,ro dummydev / >> 2>/dev/null \ >> || mount $MOUNT_FORCE_OPT -n -o remount,ro / >> ES=$? >> sync >> [ "$VERBOSE" = no ] || log_action_end_msg $ES >> >> if [ -d /cow ] >> then >> # Remove from aufs >> # This doesn't actually seem to work. >> MOUNT_FORCE_OPT=-f >> mount $MOUNT_FORCE_OPT -n -o remount,mod:/cow=ro / >> mount $MOUNT_FORCE_OPT -n -o remount,del:/cow / >> mount $MOUNT_FORCE_OPT -n -o remount,ro /cow >> umount $MOUNT_FORCE_OPT -n /cow >> fi >> cat /proc/mounts >> >> # Give usb persistent storage a chance to calm down?? >> sleep 10 >> >> >> Thanks, >> Ben >> >> -- >> Ben Greear<gree...@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
