[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Accessing the content of the layer-in-RAM with overlayfs (vs aufs)



Hi Thierry,

On Sat, 9 Sep 2017 23:46:49 +0200
Thierry <deblist@sagedebianlive.metelu.net> wrote:

> Hi,
> 
> i am upgrading from jessie to stretch, and it seems that live-boot
> moved from using aufs to overlayfs. With the older setting, i was
> able to access the content of the "last layer" (in RAM) of the
> overlay by unmounting /lib/live/mount/overlay once and then cd into
> it. This does not work anymore with overlayfs (it still works if i
> boot with "union=aufs" option). Is there still a way to access the
> contents of the "last layer" with overlayfs ?

The reason why you cannot access the overlay could be considered a bug
in live-boot, specifically in the setup_unionfs function in
9990-overlay.sh.  What happens there is the following:
* line 139: a tmpfs is mounted to /live/overlay
* line 262: another tmpfs is mounted to /live/overlay; this one is
  actually used for the overlay
* line 363: the tmpfs used for the overlay is unmounted; at this point
  the overlay tmpfs (contents of the "last layer") becomes permanently
  inaccessible 
* what remains is the tmpfs mounted from line 139; that one is moved
  to the correct location later (in 9990-main.sh, lines 135-143), but
  it's not the one we want

You can make the tmpfs holding the "last layer" accessible again by
removing lines 363 and 139 in 9990-overlay.sh (and then upgrade initrd,
etc), see attached patch.  I'm not confident enough that this won't have
side effects on other uses of live-boot though, so I'm reluctant to
suggest the patch for inclusion into live-build.

> Out of curiosity, what are the benefits of overlayfs over aufs ? Will
> aufs support be removed from live-boot ?

What I think is the most important one:  It's part of the mainline
kernel (aufs never left the kernel's staging area iirc) and being
actively maintained.

The technical difference that's most important for me is that it
supports extended filesystem attributes.  Apart from that, I think it
keeps some of the expected guarantees (e.g. that using `mv` is atomic
if src and dest are on the same mount point) that aufs violates (I'm not
sure I remember that correctly, don't quote me on that).

Regards
Lukas
diff --git a/components/9990-overlay.sh b/components/9990-overlay.sh
index d1b9cef..ae1939b 100755
--- a/components/9990-overlay.sh
+++ b/components/9990-overlay.sh
@@ -136,7 +136,6 @@ setup_unionfs ()
 	# tmpfs file systems
 	touch /etc/fstab
 	mkdir -p /live/overlay
-	mount -t tmpfs tmpfs /live/overlay
 
 	# Looking for persistence devices or files
 	if [ -n "${PERSISTENCE}" ] && [ -z "${NOPERSISTENCE}" ]
@@ -360,5 +359,4 @@ setup_unionfs ()
 	# ensure that a potentially stray tmpfs gets removed
 	# otherways, initramfs-tools is unable to remove /live
 	# and fails to boot
-	umount /live/overlay > /dev/null 2>&1 || true
 }

Reply to: