On Sun, Aug 24, 2008 at 00:50, Michael Prokop mika@grml.org wrote:

We are aware of this problem and it's already tracked in our Bug Tracking System, see http://bts.grml.org/grml/issue466

I don't know if I am registered on the bts, so I will just reply here and ask you to attach this to the bug.

Can you create a generic structure like

/grml/release/{small,large,x64}/

so different grml releases play along nicely with each other?

Richard

On Mon, 25 Aug 2008 14:01:52 +0200, Michael Prokop wrote:

...

Can you create a generic structure like

...

/grml/release/{small,large,x64}/

...

so different grml releases play along nicely with each other?

Nice idea, I'll check this out. I've attached the I've attached it to the bug report: http://bts.grml.org/grml/issue466

I've been playing with the slax derivatives for a while, and found that their modular approach is very appealing. For example, instead of having structure like,

/grml/release/{small,media,large,super-dvd}/

The slax derivatives' modular way is that large based on media which is in turn based on small. For example, here's a sample module layout (ripped off from http://forums.wolvix.org/index.php/topic,583.0.html):

* 01_kernel (Guess what's in here)

* 02_core (Core tools, like bash, and the basic GNU utilities)

* 03_ base_app (CLI applications like MC, Elvis, htop and Multimedia tools like ogg, normalize.)

* 04_base_lib (Basic libraries used by many apps. Mostly audio related.)

* 05_base_net (CLI network tools like mutt, elinks, bind, traceroute, etc.)

-- The grml small edition starts and ends here.

* 06_x11 (Xorg and fonts.)

* 07_common_desk (Xfce plus goodies, Fluxbox plus "goodies", icons, themes, wallpapers, etc. This one I'll break up a bit more, to separate Flux and Xfce.)

* 08_common_lib (All libs and requirements for the common applications. A lot of Gnome, graphics and multimedia libraries and bindings. Xfce has some deps here, guess I need to sort them out.)

* 09_common_app (All the GUI applications, network apps, graphics apps, office tools, multimedia apps, you name it. Guess this might be broken up a bit too)

-- grml Media ends here.

* 10_more_lib (All the libraries and requirements for the apps in Hunter)

* 11_more_app (All additional apps for Hunter, not found in Cub plus large things like Java and Samba. Perhaps I could make the two last separate modules.)

-- grml large ends here.

This is just an example showing how Wolvix does module layout. The modular approach has many advantages, For example, all files which belongs to Xwindow are packed in xwindow module, KOffice related stuff is in koffice module, etc. If you work with KOffice, you usually need only files from KOffice and nothing else; and hence all files from that part of the filesystem are separated from the rest of it, your CD drive has to seek only in a 10 MB area. This significantly improves the speed. Another great advantage is that, I never need to remaster slax any more, putting my extra stuff in is just as simple as putting in several modules. and I separate my own modules according to how often they are updated -- my live-usb always contains the latest tools/docs of my own, without going through the remastering process.

I know grml is different but the spirit is the same. For example, we can put forensic analysis, and network-penetration/intruder-detection tools into different modules, and load them only when necessary.

All above just requires including liblinuxlive (from http://www.linux-live.org/) into linuxrc, then the modular approach can be supported by grml. I can write more if anyone is interested.

thanks

* T o n g mlist4suntong@yahoo.com [20080902 16:49]:

On Tue, 02 Sep 2008 05:52:20 +0000, T o n g wrote:

...

All above just requires including liblinuxlive (from http://www.linux-live.org/) into linuxrc

sorry, I meant to say to include liblinuxlive in initrd.

Yes, very nice stuff. Though I've to admit that *I* won't have the time to work on this for the next few weeks. I'm busy working on the new release. If anyone is interested in bringing liblinuxlive into live-initramfs (the initrd/initramfs technology grml is using) it's highly welcome of course!

regards, -mika-

* T o n g mlist4suntong@yahoo.com [20080902 22:32]:

On Tue, 02 Sep 2008 16:55:55 +0200, Michael Prokop wrote:

...

If anyone is interested in bringing liblinuxlive into live-initramfs (the initrd/initramfs technology grml is using) it's highly welcome of course!

I'll be happy to make the attempt. Basically, I'll only need to do two things (for the moment),

Cool!

• include liblinuxlive in initrd/initramfs that grml uses.
• change linuxrc so that it mounts GRML/GRML using the function in liblinuxlive

Where can I find the grml-specific initrd/initramfs? Not the following, I presume.

initramfs-tools - tools for generating an initramfs bootcd-mkinitramfs - initramfs extension for bootcd live-initramfs - Debian Live initramfs hook

We are using live-initramfs which is based on the infrastructure initramfs-tools provides.

You can retreive the live-initramfs source we are using through running:

hg clone http://hg.grml.org/live-initramfs-grml

It's live-initramfs from Debian plus some minor grml specific addons. If anyone is wondering why it's named live-initramfs-grml: no it's *not* a fork. :)

regards, -mika-

T o n g wrote:

...

hg clone http://hg.grml.org/live-initramfs-grml

hmm..., seems much harder than I thought. I haven't find out

• where is linuxrc

there is no linuxrc anymore.

• where is code that mounts GRML/GRML
• where is code that handle grml boot cheat code

git://git.debian.net/git/live-initramfs.git

in the scripts/ section

cu, michael

Hi I would like to install grml to a usb stick. (not as a live cd but as a hard disk install). Since this is flush memory, with limited write cycles, I wonder if I have to take special with some files or directories that might perform to a high number of write access. For example, I can not create a swap partition since this will rapidly ruin the stick. My question is: are there other files (for examples in the /dev /tmp /var dirs) that are written very frequently and that should be mapped for example to a tmpfs or ramdisk ?

Thanks for your help Peter