Live boots without dm snapshots

Live boots without dm snapshots

[Major Hayden]

Hello there,

I'm working with a large environment where one of our design goals is to live boot systems from images we generate within our company.  We've been stuffing a filesystem image into a squashfs so far (following Fedora documentation) and dracut handles it well.  However, when the device mapper snapshot fills, we're stuck with a server that needs a hard reboot.  I've tried a direct filesystem image boot and that works but I'm still stuck with a snapshot.

Through some awful shell hacking last night, I disabled do_live_from_base_loop and set up the loopback device as writeable:

diff --git a/modules.d/90dmsquash-live/dmsquash-live-root.sh b/modules.d/90dmsquash-live/dmsquash-live-root.sh
index 5705e8d..38d20e0 100755
--- a/modules.d/90dmsquash-live/dmsquash-live-root.sh
+++ b/modules.d/90dmsquash-live/dmsquash-live-root.sh
@@ -182,5 +182,5 @@ if [ -n "$FSIMG" ] ; then
     BASE_LOOPDEV=$( losetup -f )
-    losetup -r $BASE_LOOPDEV $FSIMG
+    losetup $BASE_LOOPDEV $FSIMG

-    do_live_from_base_loop
+    #do_live_from_base_loop
 fi

I was then able to boot the filesystem image as read/write and that system has been running well overnight.

Obviously, this hack is ugly and needs significant work.  I'm interested to know if the direction I'm going makes sense or if I'm totally off base.  Ideally, I'd like to use a union filesystem or btrfs seed device to handle the read-only volume and COW, but that will take a lot more work.

Thanks in advance for any input you can provide!

--
Major Hayden

Re: Live boots without dm snapshots

[Harald Hoyer]

On 01.08.2014 14:33, Major Hayden wrote:
> Hello there,
> 
> I'm working with a large environment where one of our design goals is to live boot systems from images we generate within our company.  We've been stuffing a filesystem image into a squashfs so far (following Fedora documentation) and dracut handles it well.  However, when the device mapper snapshot fills, we're stuck with a server that needs a hard reboot.  I've tried a direct filesystem image boot and that works but I'm still stuck with a snapshot.
> 
> Through some awful shell hacking last night, I disabled do_live_from_base_loop and set up the loopback device as writeable:
> 
> diff --git a/modules.d/90dmsquash-live/dmsquash-live-root.sh b/modules.d/90dmsquash-live/dmsquash-live-root.sh
> index 5705e8d..38d20e0 100755
> --- a/modules.d/90dmsquash-live/dmsquash-live-root.sh
> +++ b/modules.d/90dmsquash-live/dmsquash-live-root.sh
> @@ -182,5 +182,5 @@ if [ -n "$FSIMG" ] ; then
>      BASE_LOOPDEV=$( losetup -f )
> -    losetup -r $BASE_LOOPDEV $FSIMG
> +    losetup $BASE_LOOPDEV $FSIMG
> 
> -    do_live_from_base_loop
> +    #do_live_from_base_loop
>  fi
> 
> I was then able to boot the filesystem image as read/write and that system has been running well overnight.
> 
> Obviously, this hack is ugly and needs significant work.  I'm interested to know if the direction I'm going makes sense or if I'm totally off base.  Ideally, I'd like to use a union filesystem or btrfs seed device to handle the read-only volume and COW, but that will take a lot more work.
> 
> Thanks in advance for any input you can provide!
> 
> --
> Major Hayden

Frankly, just copy, rename and modify the dmsquash-live dracut module and run
your own version, if it's of use in your company.

I don't know, if we can come up with a full generic version, which fits all use
cases for the upstream dracut module.

That said, the direction should probably be the opposite and move the
specialized modules to the tools, which use it, like the LiveCD-tools of Fedora
in this case, which generates these images to be consumed by this module.