<p><br>
On Mar 30, 2012 3:38 AM, "Dave Reisner" <<a href="mailto:d@falconindy.com">d@falconindy.com</a>> wrote:<br>
><br>
> On Wed, Mar 28, 2012 at 11:30:08AM -0300, Gerardo Exequiel Pozzi wrote:<br>
> > On 03/28/2012 10:44 AM, Dave Reisner wrote:<br>
> > >>Is there any way to make something similar work with loop devices? You<br>
> > >>would need to disable the loop device before umounting the underlying<br>
> > >>file system. If we could solve this as well, then archiso probably<br>
> > >>wouldn't need its special shutdown hook anymore.<br>
> > >><br>
> > >sure, lsblk loudly declares loop devices to be type loop. Hrmmm, archiso<br>
> > >does a lot of weird stuff... in particular, the squashfs mounts are<br>
> > >confusing me and/or lsblk. I'll get myself a newer image and poke around<br>
> > >at what Gerardo is doing on setup...<br>
> > ><br>
> > >I'm sure it's possible, I just need to understand what's happening.<br>
> > ><br>
> > >d<br>
> > ><br>
> ><br>
> > Hello,<br>
> ><br>
> > The first step on "shutdown" for archiso is a mount --move, since<br>
> > /oldroot depends on things from /oldroot/run/archiso. This make it a<br>
> > bit special.<br>
> ><br>
><br>
> So, I need to understand more about this... why is this done? The<br>
> current shutdown hook that I have in my tree gets archiso's wacky setup<br>
> torn down properly sans loop devs. Add in a quick loop:<br>
><br>
>    # assume starting in /sys/class/block<br>
>    for loop in loop*/loop; do<br>
>        losetup -d "${loop%/loop}"<br>
>    done<br>
><br>
> And everything seems to be torn down properly because I'm lazily<br>
> unmounting everything.<br>
><br>
>  Unmounting all devices.<br>
>  Disassembling stacked devices.<br>
><br>
>  losetup: /dev/loop0: detach failed: Device or resource busy<br>
>  losetup: /dev/loop3: detach failed: Device or resource busy<br>
>  losetup: /dev/loop6: detach failed: Device or resource busy<br>
><br>
>  # findmnt<br>
>  TARGET  SOURCE FSTYPE   OPTIONS<br>
>  /       run[/initramfs]<br>
>                 tmpfs    rw,nosuid,nodev,relatime,mode=755<br>
>  |-/sys  sys    sysfs    rw,nosuid,nodev,noexec,relatime<br>
>  |-/proc proc   proc     rw,nosuid,nodev,noexec,relatime<br>
>  |-/dev  /dev   devtmpfs rw,nosuid,relatime,size=503104k,nr_inodes=125776,mode=75<br>
>  `-/run  run    tmpfs    rw,nosuid,nodev,relatime,mode=755<br>
><br>
>  # lsblk<br>
>  NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT<br>
>  vda    254:0    0     5G  0 disk<br>
>  |-vda1 254:1    0   100M  0 part<br>
>  `-vda2 254:2    0   4.9G  0 part<br>
>  sr0     11:0    1   200M  0 rom<br>
>  loop0    7:0    0  92.9M  1 loop<br>
>  loop3    7:3    0  34.3M  1 loop<br>
>  loop6    7:6    0    53M  1 loop<br>
><br>
>  # losetup -a<br>
>  /dev/loop0: [2816]:1930 (/arch/x86_64/root-image.fs.sfs)<br>
>  /dev/loop3: [2816]:1926 (/arch/x86_64/lib-modules.fs.sfs)<br>
>  /dev/loop6: [2816]:1414 (/arch/any/usr-share.fs.sfs)<br>
><br>
> Those three errors are something that archiso hides. So, as far as I can<br>
> tell, my hook is equivalent. Is there some serious problem with using<br>
> lazy unmounting that makes this non-desirable? I can't really find any<br>
> evidence of negative effects here.</p>
<p>Wouldnt this lead to races in case the lazy umount is not finished when you need it to be (either because the parent cant be dissssembled lazily, or because we switch the power off).</p>
<p>For once sceptical of lazines,</p>
<p>Tom<br>
</p>