Hi,
I used to use grml2hd after booting off grml, but today I tried the grml2hd from the chroot. I think nobody has ever done this before. I'm just trying to see if I can get it working. If so, I could do the Grml HD installation then system customization from within my current system, so that I could have almost zero down time.
Here are some issues/questions regarding grml2hd.
- I think the document (http://grml.org/grml2hd/grml2hd.html) is not up-to-date with the script. E.g., I didn't find the switch "--noninteractive" documented.
- I saw that the script is trying to duplicate the whole /dev directory. Is this still necessary? -- this is not a question but a request for explanation, because I thought udev would take care of populating the /dev directory on the fly.
- now to the issue of using grml2hd from the chroot itself. It didn't work for me. It almost failed to copy over anything:
cp: cannot stat `backups': No such file or directory cp: cannot stat `boot': No such file or directory cp: cannot stat `cdrom': No such file or directory cp: cannot stat `dev': No such file or directory cp: cannot stat `etc': No such file or directory cp: cannot stat `floppy': No such file or directory cp: cannot stat `home': No such file or directory cp: cannot stat `initrd': No such file or directory cp: cannot stat `lib': No such file or directory cp: cannot stat `media': No such file or directory cp: cannot stat `mnt': No such file or directory cp: cannot stat `none': No such file or directory cp: cannot stat `opt': No such file or directory cp: cannot stat `root': No such file or directory cp: cannot stat `sbin': No such file or directory cp: cannot stat `selinux': No such file or directory cp: cannot stat `swap': No such file or directory cp: cannot stat `usr': No such file or directory cp: cannot stat `var': No such file or directory
UTSL reveals that it might cause by the 1st line, "cd /UNIONFS", in the copy_files function. Can we do something about it? I mean do something to make it chroot friendly? Further, my currently grml was first grml2hd'ed from grml ver0.7, and there is no /UNIONFS mount point or directory in my current system. I guess I can't use grml2hd to dupe my currently grml to another HD as well, can I?
thanks
* - Tong - mlist4suntong@yahoo.com [20070820 01:35]:
I used to use grml2hd after booting off grml, but today I tried the grml2hd from the chroot. I think nobody has ever done this before. I'm just trying to see if I can get it working. If so, I could do the Grml HD installation then system customization from within my current system, so that I could have almost zero down time.
Nice idea! :)
Here are some issues/questions regarding grml2hd.
- I think the document (http://grml.org/grml2hd/grml2hd.html) is not up-to-date with the script. E.g., I didn't find the switch "--noninteractive" documented.
Thanks, I updated the docs (it's "-i"/GRML2HD_NONINTERACTIVE=1) according to what's shipped with grml.
- I saw that the script is trying to duplicate the whole /dev directory. Is this still necessary? -- this is not a question but a request for explanation, because I thought udev would take care of populating the /dev directory on the fly.
As we support a 'noudev' bootoption we want to make sure you always have a valid /dev present. It shouldn't hurt anyone this way.
- now to the issue of using grml2hd from the chroot itself. It didn't work for me. It almost failed to copy over anything:
cp: cannot stat `backups': No such file or directory cp: cannot stat `boot': No such file or directory cp: cannot stat `cdrom': No such file or directory cp: cannot stat `dev': No such file or directory cp: cannot stat `etc': No such file or directory cp: cannot stat `floppy': No such file or directory cp: cannot stat `home': No such file or directory cp: cannot stat `initrd': No such file or directory cp: cannot stat `lib': No such file or directory cp: cannot stat `media': No such file or directory cp: cannot stat `mnt': No such file or directory cp: cannot stat `none': No such file or directory cp: cannot stat `opt': No such file or directory cp: cannot stat `root': No such file or directory cp: cannot stat `sbin': No such file or directory cp: cannot stat `selinux': No such file or directory cp: cannot stat `swap': No such file or directory cp: cannot stat `usr': No such file or directory cp: cannot stat `var': No such file or directory
UTSL reveals that it might cause by the 1st line, "cd /UNIONFS", in the copy_files function. Can we do something about it? I mean do something to make it chroot friendly? Further, my currently grml was first grml2hd'ed from grml ver0.7, and there is no /UNIONFS mount point or directory in my current system. I guess I can't use grml2hd to dupe my currently grml to another HD as well, can I?
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 - but if you want to see that implemented by myself you'd have to wait a little bit.
I've added it to our BTS (see http://bts.grml.org/grml/issue270) so we don't forget it.
regards, -mika-
First of all, thanks for the previously answering my sata/scsi disk partition number limit question.
On Mon, 20 Aug 2007 10:52:46 +0200, Michael Prokop wrote:
I used to use grml2hd after booting off grml, but today I tried the grml2hd from the chroot. I think nobody has ever done this before. I'm just trying to see if I can get it working. If so, I could do the Grml HD installation then system customization from within my current system, so that I could have almost zero down time.
Nice idea! :)
. . . 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 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 - squashfs is patched with LZMA compression, so compressed filesystems are 30% smaller
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.
Moreover, don't you think the LZMA compression, the >30% extra space gained is very appealing?
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".
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." __________________________________
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
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!"
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.
thanks
* - 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-
On Mon, 27 Aug 2007 11:01:30 +0200, Michael Prokop wrote:
. . . please stay tuned. :)
Thanks for sharing your view. It's very interesting to know that you've talked to Tomas M, met with Thomas Lange (FAI) and Klaus Knopper (Knoppix) in person. In window$ scenario, you'll be die hard competitors, but in Linux world you all share your envisions to make Linux better. That's phenomenal!
Also glad to know that those exciting features are going on in grml as well. I'll wait for LZMA in Debian's squashfs then...
cheers
Teilnehmer (2)
-
- Tong - -
Michael Prokop