Customizing Grml

The script grml2hd creates a standard Debian system. It does not work like live CD. To add or remove packages, simply run apt-get.

The grml2hd script already generates initrd files and configures LILO. Click "yes" when prompted. You can modify later, but nothing requires that.

A different script called grml2usb creates a device which does imitate grml live CD. It is meant for smaller capacity devices like flash sticks.

Mark @ sneakemail.com

If you use the scripts boot para, this is pretty easy.

Create a directory called scripts in the top of the cdrom, and put a shell script named grml.sh on it.

You can now install packages or other stuff from this shell script. You can also put the .deb itself on the cdrom and just run

Ulrich Dangel

Oh, btw. i forgot to mention, you can also just put youre deb files under /cdrom/debs/ and use the debs boot para…

Ulrich Dangel

Remastering grml from Debian Sarge which doesn't understand the GRML/GRML SquashFS file system, without applying the kernel patch for SquashFS.

I now have a read-/writable copy of grml filesystem.

Note: I did not apply the kernel patch for SquashFS to my Debian Sarge because of approach above.

I boot back to my Debian Sarge to make the changes, because although I can't use the squashfs modules in Debian Sarge, I can create squashfs file system with the native squashfs-tools package.

All that I need to do is to chroot into it, and do whatever I like to do with grml, eg to run apt-get and so on.

You now need to create a new squashfs image (the huge GRML/GRML file). The tool used is 'mksquashfs' from the squashfs-tools package. Ran it as root with the source directory and the destination file as arguments:

documented on: 2006.07.02

http://wiki.grml.org/doku.php?id=remastering

Table of Contents

To get access to grml's /, you first have to mount the grml_X.Y.iso somewhere. This ISO image is a iso9660 filesystem - any recent distribution kernel should include support for iso9660.

I put all my remastering stuff under '\~/grml-remaster', just to keep track of all the files. So create a mount point and mount the iso image:

Now we have the CD image mounted at 'mount1/'. Inside the cd image there's e.g. the isolinux stuff, the index.html (which you get displayed when you put grml into a windows pc) and a file called 'GRML' in the directory 'GRML'. This file contains grml's root file system and is a squashfs filesystem.

The rest of this procedure depends on whether you intend to change the contents of the sqashfs filesystem or not. Since grml is very flexible, there are chances that you do not need to modify the squashfs.

You can start exploring the grml CD's / in '\~/grml-remaster/mount1' right now. Beware that the file system is mounted read-only, as iso9660 is a read-only filesystem (anything else wouldn't make sense on the CD, either :-)).

To make changes, we have to copy the mounted CD. I created '\~/grml-remaster/copy-mount1' for this and copied 'mount1/' there:

This takes some time. After cp is finished you have a read-/writeable copy of the grml CD's '/' in '\~/grml-remaster/copy-mount1'. You may umount '\~/grml-remaster/mount1' now, if you wish.

After making your changes, create a new .iso:

You can treat \~/grml-remaster/copy-mount2 like a root filesystems of an installed linux (in fact, it isn't something else).

You can just copy files there or chroot into it, to run apt-get or so.

consult any knoppix remastering howto (like the one on knoppix.net).

To create a new squashfs image, mksquashfs is needed. If you are on a Debian system, just apt-get install squashfs-tools. Ran it with the source directory and the destination file as arguments:

to put the new-GRML into an iso9660 image and others, check back the original wiki.

documented on: 2006.11.26

Stripping the big one down works fairly well (in my opinion better than adding things to grml_small because you might add newer/untested versions accidentally) and even without network connection.

Just take dpkg —get-selections, and set everything to purge which is not listed in the grml-small-selections file. Keep the following packages as well (since packages on grml-small are named differently for these):

Run apt-get dselect-upgrade and after some time you will have a smaller system. Keep more packages to get a bigger cd image.

From one of my scripts for a similar purpose:

Michael Schierl

So I have played around with this script for a while; I am trying to keep X, so my 'my-selections' looks like this:

The first 'apt-get -y dselect-upgrade' runs fine and leaves everything related to X alone.

The second one, though, wants to remove everything that looks remotely like X:

What am I missing there? Do I have to put the whole dependency tree for those packages into my selection file?

Maybe it would be easier to strip grml down to the minimum packages you mentioned and then go using aptitude or apt-get…

Juergen Fiedler

What I want to know is how do you actually make a live cd? What I mean is this, and I will explain what I mean in more detail.

Ok, starting from a running grml system on your development machine, all the programs are on there, the bugs are out, to the best of your knowledge, and you are ready to make a new release. What is done to get from that to the iso file system with its large compressed file system, and the other files that are with it.

I know how to make an iso-9660 file system, at least, well enough to make a cd, but how do you make the thing bootable? How does the technology work that is used to compress the software and documentation down? How does the thing know which parts of this large file to use when accessing programs?

Why I wonder this is, I like to add in a few packages that I use. I would like to have my own disk with config files, new packages and more so that I can just set up on any machine and rock and roll.

Doug Smith

If you just want to remaster it, follow one of the remastering guides. If you want to change how the boot process works, you will have to dig deeper. I'll try to sketch it below, but if you are really interested to build your own live cd "from scratch", you will have to read a lot more…

There are, in theory, two ways.

In practice, nowadays you use only method (b). Popular boot loaders for CDs are for example isolinux (used by grml), grub, and cdshell (which can boot almost everything: Windows install and live cds, cd and floppy images, and of course Linux).

It is a compressed filesystem. It is read-only (similar to iso) but compresses all files on disk. The filesystem itself is not stored directly on a disk, but in a filesystem image which is on the CD and appears a one file there. There are several compressed filesystems available; most live cds use squashfs nowadays (which needs a kernel patch since it is not in mainline yet), older ones used cloop.

Since the filesystem is read-only, you need some place to store temporary data as well. The filesystem for this is tmpfs (which lives just in RAM). Live CDs used to set up sophisticated symlinks so that all read-only files are on compressed filesystem and all files that have to be changed are copied to RAM at boot. But nowadays there is a better solution called unionfs: It will take two filesystems and create a view that unites both. All write access will go to the read-write filesystem (i. e. RAM), unchanged files live on the compressed filesystem. This is not limited to live cds, but can as well be used everywhere else where you have a "base filesystem" you have to go back to regularly.

Just like an on-disk filesystem knows what parts of your hard disk to access to find your files.

The more tricky part is how to tell the kernel how to assemble the filesystem out of three other filesystems. The solution is initrd (you can also use initramfs in more recent kernels) which is loaded to RAM (by the bootloader) and sets up the root filesystem. That means: Looks for where the CD is (IDE, SCSI, somewhere else), mount it, mount the compressed filesystem on it, create the unionfs, and give the new unionfs as root device to the kernel.

Building an initrd is tricky because you will have to use tools on it that work without having the full filesystem available. busybox is quite useful for this. But usually you can use an existing initrd (or at least modify an existing one instead of building one from scratch). On the other hand, it can be very interesting to try to build one yourself - but in that case you should have a PC emulator like VMWare or qemu handy, because otherwise you will need lots of CDs and lots of time for burning them.

Start at the boot process howto (Umm, I can't find it at the moment). Or if you want to learn more about Linux, try to follow a "Linux from scratch" guide, which will tell you how to build a Linux that is on a hard disk (including kernel, bootloader and everything) and does not use any files from your current Linux distribution. Building chroot environments (directories that do not allow access outside to prevent malicious programs inside to use programs outside) helps as well because it gives you experience what files are needed by which programs to run (which is useful for building an initrd).

Ask again if you do not understand the answers. Since no one here knows what you know about Linux and what you don't, it is hard to give a description that does not bore the intermediate used and does not ask too much of a complete newbie (that never used a Linux console before) either.

Michael Schierl

You already know the bootoption "startx"?

Hm, sorry - what does 'don't do anything' mean? :) Interesting feature request. Do I have to implement nothing as well? ;)

Ok, so you mean you want to get a special bootoption which runs 'grml-x -force -nostart wm-ng' in background during bootup?

Bootoption startx does that. :)

regards,

Someone has to implement it. :) I have some more important stuff on my todo list and would like to see unionfs in a more stable state before doing such a major modification with unionctl (inclusion in mainline kernel once would be great).

Michael Prokop