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

Bug#773881: live-boot: Fails to boot with union=overlayfs



Control: reopen -1
Control: found -1 5.0~a1-1

Hi,

intrigeri@debian.org wrote (24 Dec 2014 13:56:26 GMT) :
> Boots fails and I get dropped into the initramfs emergency shell, for 
> various reasons:

>   * first, "mount -t overlayfs" is called, while it should be
>     "mount -t overlay"
>   * second, we try to mount the "${UNIONTYPE}" (aka. "overlayfs")
>     device, which fails: it should be "overlay"

These two problems are indeed fixed in 5.0~a1-1.

I experience a new blocking bug, though: in 9990-overlay.sh, we check
if the chosen union filesystem's functionality is available in
/proc/filesystems before we load its kernel module, so I always hit:

                panic "${UNIONTYPE} not available."

This is fixed for me by the attached (naive?) patch.

Long-term wise, a better fix might be to load the module iff.
/proc/filesystems doesn't know about it, and then check
/proc/filesystems again. And then it would be good to avoid code
duplication by reusing the is_supported_fs function we already have,
and to improve that function a bit to use the stricter (`cut -f2 |
grep') check that's currently used in 9990-overlay.sh. Thoughts?

>   * third, the call to mount lacks the workdir= option.

This one hasn't been fixed, and I get:

  mount: mounting overlay on /root/ failed: invalid argument
  + panic mount overlay on /root/ failed with option -o noatime,lowerdir=//filesystem.squashfs/,upperdir=/live/overlay/

Indeed, Documentation/filesystems/overlayfs.txt reads:

   mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
     workdir=/work /merged

   The "workdir" needs to be an empty directory on the same filesystem
   as upperdir.

Note that in future versions of overlayfs (see the overlayfs-next
branch in Miklos Szeredi's repository [1]), upperdir= becomes
optional, and in that case workdir= is optional too, but then the
overlay will be read-only. So, my understanding is that for Debian
Live systems to work fine, we will still have to pass workdir=.

Now, since Daniel closed this bug, I'm wondering if I did something
wrong, so just to clarify: Daniel, did you ever see live-boot 5.0~a1-1
work for you with union=overlay?

[1] git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git

Cheers,
--
intrigeri

>From d2c32b277296f17a9b0e1f0fec2b563a2afeda6e Mon Sep 17 00:00:00 2001
From: Tails developers <amnesia@boum.org>
Date: Sun, 25 Jan 2015 10:02:40 +0000
Subject: [PATCH] Loading chosen union filesystem's kernel module before
 checking for its functionality to be available in /proc/filesystems.

Otherwise, with union=overlay, we always hit:

		panic "${UNIONTYPE} not available."
---
 components/9990-overlay.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/components/9990-overlay.sh b/components/9990-overlay.sh
index 92d0355..9282276 100755
--- a/components/9990-overlay.sh
+++ b/components/9990-overlay.sh
@@ -8,13 +8,13 @@ setup_unionfs ()
 	rootmnt="${2}"
 	addimage_directory="${3}"
 
+	modprobe -q -b ${UNIONTYPE}
+
 	if ! cut -f2 /proc/filesystems | grep -q "^${UNIONTYPE}\$"
 	then
 		panic "${UNIONTYPE} not available."
 	fi
 
-	modprobe -q -b ${UNIONTYPE}
-
 	# run-init can't deal with images in a subdir, but we're going to
 	# move all of these away before it runs anyway.  No, we're not,
 	# put them in / since move-mounting them into / breaks mono and
-- 
2.1.4


Reply to: