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: