* - Tong - mlist4suntong@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-