[Grml] Linux Live on the roadmap?

[Michael Prokop]

* - Tong - <mlist4suntong at yahoo.com> [20070826 20:07]:
> First of all, thanks for the previously answering my sata/scsi disk
> partition number limit question.

You are welcome.

> On Mon, 20 Aug 2007 10:52:46 +0200, Michael Prokop wrote:

> > Yes, would be great to have a grml2hd version which could install grml
> > directly from a chroot (so you don't have to boot it at all ;)). But
> > currently I don't have the time to implement the relevant changes for
> > grml2hd on my own. I welcome any patches of course

> I'd love to help! The only thing that stops me is the /UNIONFS thing, I.e.,
> I don't quite understand where is the most appropriate place to copy files
> from. This brings me to something I'd like to ask for quite a while:

> Have you ever considered downloading/"outsourcing" the live system detection
> part to linux-live (http://www.linux-live.org/)? Is linux-live somewhere on
> grml's roadmap?

I know linux-live and even talked to Tomas M.

> I guess the answer is "no", so I'll try my best to sell the idea here
> below. :-)

> The following was the reason that drawing my attention away from grml
> several months ago:

> - aufs is used instead of unionfs, brings great stability and features

grml already uses aufs! :) Unionfs ist available as well, but by
default we already use aufs starting with the latest stable releases
(grml 1.0, grml64 0.1, grml-small 0.4). It's named /UNIONFS in the
live mode because we don't want to break any existing scripts - so
no matter wheter you use aufs or unionfs on grml you'll find
/UNIONFS available.

> - squashfs is patched with LZMA compression, so compressed filesystems
>  are 30% smaller

Yes, we are aware of the LZMA feature and we really like it. But:

- we want to make sure that we don't leave the Debian way of live
  too early (so we would like to see LZMA in Debian's squashfs as
  well before switching to it)

- we have to make sure the upgrade path for users working on
  their own grml version is as clean and easy as possible

> I remember that you said you were waiting for aufs to settle down (get
> stabled) to replace the current unionfs implementation. I can assure you
> from my personal experience that aufs is quite stable now. I've been using
> slax/wolvix for several months now, and I use slax's modularity feature to
> plug-in and unplug my modules all the time - I was constantly building and
> testing my modules, ie, the building blocks of aufs file systems. I have
> never experience any problem. Moreover, I've been closely watching slax's
> forum for quite a while, never ever was a single post regarding the
> stability of aufs.

Yes, I'm aware of this. In regards of stability I meant something
different as well: I don't want to write tools *for* aufs/unionfs
before they have a stable API/way-to-go. It looks like unionfs might
hit mainline kernel in the future and this would improve the process
of integration (especially when considering new architectures) a
lot. So currently there is not an exclusive unionfs *or* aufs for me
but a "the solution should work with both".

> Moreover, don't you think the LZMA compression, the >30% extra space gained
> is very appealing?

Definitely. Stay tuned. :)

> What's important, the linux-live isn't meant only for slaxware. It is build
> for any running linux system. slax is only a living demo for linux-live
> which happens to be slaxware based.

> Please consider seriously downloading/"outsourcing" the live system
> detection part to linux-live, because in doing so, grml will surely
> be "standing on a giant's shoulder" -- linux-live has been actively
> progressing to make live detection better and better, so you can
> concentrate on grml specific part. I sure think it is a win-win
> situation. 

> I understand that grml specific things is your major focus, so aufs or LZMA
> compression might not get onto the top of todo list, neither will be
> persistent home and persistent root, which I've been requesting ever since I
> joined grml party. I'm not blaming you for neglecting my requests :-), On
> the contrary, I think you should focus more on grml specific things and do
> the "outsourcing".

Trust me: those features are (with some other things) on the top of
our todo list. I just delayed implementation because I wanted to
make sure the API/way-to-go - as written above - is pretty stable
when we roll out the feature.

> More on persistent root, quoting Tomas:
> http://forum.live-developers.org/index.php/topic,112.0.html

> __________________________________
> "Saving of modifications / settings is the most important thing for a Live
> distro. If you can't save your modifications, you'd need to setup your
> desktop the way you like it every time you start the live distro, again and
> again. This is not any problem for a liveCD developer (as he knows how to
> build a module from /mnt/live/memory/changes), but it may be a big trouble
> for your user."
> __________________________________

Yeah, I'm, aware of that.

> Translate into grml domain, grml is built the way grml developer like, but
> it might not be the way grml user would like to set/use. this may be a big
> trouble for grml users :-).

> Mika, I believe you understand how important of saving modifications /
> settings for a Live distro is, but just can't stretch your focus far enough
> onto it, so let's try to have linux-live handling it, shall we?

> FYI, currently, linux-live (Tomas) is, as always, leading the live distros 
> into another round of excellency. I.e., when the Live distro (for example
> Slax) is started from USB Flash, then all changes will be stored back to
> USB, on the fly, consuming only the free space from the Flash Key which is
> really needed, by mounting the 'changes' filesystem as the WRITABLE BRANCH
> of aufs, so all files you modify are COPIED-UP and then modified.
> http://forum.live-developers.org/index.php/topic,112.0.html

Yeah, nice feature.

> And more interestingly, even MP3 players, or digital cameras that impose FAT
> only filesystem can be used to host the live distro and save changes. What
> about the POSIX features (symlinks, hardlinks, chmod), you may ask -- the
> 'changes' directory will be overmounted by POSIXOVL filesystem, and
> "voila, we can use this as well!"

Nice.

> Mika, as you can see, grml will really be "standing on a giant's shoulder" 
> if you download the burden of implementing above in grml to linux-live. 
> Do you think it is a good idea to give it a try? 
> I really hope so.

This weekend I met Thomas Lange (FAI) and Klaus Knopper (Knoppix) at
Froscon and we together talked about live-initramfs and the
different approaches using initrd vs initramfs and unionfs/aufs.

Currently there just does not exist a solution which does exactly
what *I* need. IIRC(!) linux-live also mounts unionfs/aufs over /
and therefore we can't use stuff like losetup anymore (IIRC due to
lack of the sendfile implementation in the overlay filesystem), the
same applies to live-initramfs as well.

But I'm investigating on that issue - I'm in the process of
evaluation and be sure that I'll consider linux-live as well, please
stay tuned. :)

regards,
-mika-
-- 
 http://grml.org/            # Linux for texttool-users and sysadmins
 http://wiki.grml.org/       # share your knowledge
 http://grml.supersized.org/ # the grml development weblog
 #grml @ irc.freenode.org    # meet us on irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20070827/b06e1998/attachment-0004.pgp>