| View previous topic :: View next topic |
| Author |
Message |
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
 Posted: Wed Dec 07, 2005 11:21 pm Post subject: [howto] Gentoo Linux Livecd [last update 01/22/2007] |
 |
|
UPDATE 1, 12/11/2005: Dropped Grub in favor of ISOLINUX.
UPDATE 2, 12/16/2005: Added section "10. HD PARTITIONS AUTODETECTION".
UPDATE 3, 12/21/2005: Changed several things.
- The linuxrc script has changed. Check it out, now it umounts the initrd claiming 10 MB of RAM back.
- Section 6. has been upgraded with some "graphics" (  ). I've made some changes to make it a little easier to understand.
- Fixed a "bug". Somehow I confused /var/lib/portage with /usr/lib/portage o_O Fixed. The build environment has changed and so have the prepare_env and release_env scripts.
- Slightly changed the X autoconfiguration section, check it out.
UPDATE 4, 01/06/2006: Migrated to UNIONFS!
- You can find the old guide at the address http://lepacakliffoth.interfree.it/howto.txt
UPDATE 5, 01/21/2006: Minor update
- Fixed some typos and other inconsistencies. Big thanks to Aszrael and anyNiXwilldo and everyone else who pointed them out!
- In particular Section 2. has undergone an important change. Now you have to change the checkroot service. Check it out.
UPDATE 6, 06/07/2006: Improvement
- At the end of page 4 you'll find an improved version of the HD autodetect script, pending integration in the guide.
UPDATE 7, 12/20/2006: Some changes
- Section 10 has changed.
- Merged some corrections users suggested a long time ago.
UPDATE 8, 01/22/2007: One change
- Thanks to STrRedWolf there's now an additional, easier way to make the initrd (Section 5).
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox!
Last edited by Lepaca Kliffoth on Mon Jan 22, 2007 4:01 pm; edited 20 times in total |
|
| Back to top |
|
 |
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Wed Dec 07, 2005 11:22 pm Post subject: |
|
|
Gentoo Linux Livecd HOWTO - the Lepaca way
ACKNOWLEDGEMENTS
This guide was heavily based on the "Gentoo Linux LiveCD for Dummies!" guide by veezi. This guide has changed considerably during its first month of life but it started as a simple upgrade/update on the one by veezi and still shares many things with it.
INTRODUCTION / DISCLAIMER
First of all, I have no idea what you can or cannot do with Catalyst so it could be that this is just a complicated way of re-inventing the wheel. The one and only thing I can assure you is that it works.
This is a relatively simple method most experienced Gentoo users will be able to follow without too many problems. Here is a rough list of what you should be confident with before attempting to follow this guide, some is common knowledge and some you may not be confident with:
- Please don't attempt this if you still need the gentoo handbook to install a Gentoo base system. I won't replicate the relevant handbook parts here and you'll probably fsck lots of things up anyway because of your lack of experience.
- You must have mastered portage, i.e. you should know how to emerge things properly and configure gentoo-related things.
- This guide doesn't deal with software that isn't stricly related to running Linux from a CD. You have to configure programs by yourself.
- Read the mount man page, you should at least know about the --bind.
- One of the most difficult things in the guide is understanding how a Linux system boots, from grub/isolinux to init. I'll try to give as much info as I can but I'm not sure it'll be enough. It's important to understand the linuxrc script as it's very easy to make mistakes when writing one. You should be fine with the code I provide but some previous knowledge will make things way easier.
Keep in mind that even if I provide a few scripts -- very simple ones as they're not meant to be powerful -- and some bash code fragment, they won't add up to a big complete installation script that you can run once to get a working iso. Always make sure you know exactly what you're doing unless I tell you "you will understand this later" and remember that the ctrl-c,ctrl-v combo can't really replace your brain :p
I tried to be as informative as I could; this is not a quick howto, it's meant to be a complete guide. The best way to follow this guide is to read a whole section without doing anything, then go back to the beginning and actually do what you're told to do as you go through the section a second time. Let me know if you feel this guide lacks detail in some or all of its parts.
0. THE HOST OS
The host operating system doesn't have to be Gentoo, e.g. I only built Gentoo livecds until now but the host system has always been SourceMage. Before you start reading the guide and building the livecd make sure the host OS you use meets the following requirements.
- You need mksquashfs, mkisofs and mkfs.ext2 to create filesystems
- You need support in the kernel for ext2. Squashfs support isn't required but would probably come in handy for debugging purposes. To this day I never had any need of it although I built more than 20 livecds.
- You need an app to burn the iso you will produce. Since you may find yourself working from the command line without any X running you may want to use good old cdrecord/growisofs without any gui. Of course you need mkisofs to create the iso
- You need root access
That's all.
1. FIRST STEPS
(a.k.a emerge system)
This guide assumes you're always logged as root. Throughout the guide we'll also use features that imply you're going to run a 2.6 kernel on your livecd; if you want to run 2.4 you'll have to figure out what you have to change by yourself.
We need to install a Gentoo base system either inside a directory or in its own partition. It doesn't make a difference which approach you use but using a simple directory will be quicker and easier. On the other hand if you use a partition you can test the livecd without even creating an iso.
Create a directory that you will use exclusively for the building of the livecd. Set an environment variable to that path, like this:
| Code: | | export LIVEDIR="~/livecd" |
or something like that. In the few scripts I provide and in the guide itself the variable LIVEDIR will be used extensively. In this guide and those scripts ${LIVEDIR} means "the content of the variable LIVEDIR", in this case ~/livecd.
Under ${LIVEDIR} create a directory called "source". If you have chosen to install Gentoo in its own partition you must now format it and mount it under ${LIVEDIR}/source.
If you have a working Gentoo inside that partition, you're ready to go on; read the rest of this section just in case you have to make some changes (e.g. fstab and isolinux) and then go on with the guide. Make sure your installation isn't too big for the media you want to use; you can't tell how much space it will take on the cd until you've compressed it (more on that much later) but as a reference I can tell you my 1.1 GB gentoo installation produces a 316 MB iso. This guide will go on assuming you're building from scratch.
Inside ${LIVEDIR}/source/ unpack a stage3 tarball, chroot into it and rebuild the Gentoo base system with your own optimizations.
*WARNING* From now on we're chrooted inside the Gentoo base system. Keep in mind that /var really is ${LIVEDIR}/source/var on your HD.
When you build the base system follow this guidelines:
- Don't install the kernel. Emerge the sources but leave them alone. Do not emerge Grub, emerge the "syslinux" package instead. Don't configure fstab.
- I suggest you follow Bob P's stage 1/3 method as it's probably the best one, however the objective here is just to get a working base system (barring the kernel and fstab); you can choose whatever method you want, just make sure you're getting the equivalent of "emerge system". You can add the most basic things like hotplug and a logger but forget about kde/gnome/fluxbox and even X. We will install them much later.
- USE flags should be kept to a minimum. What we want here is just a platform to build any kind of system we may want to use. Space IS an issue so follow the "less is more" philosophy.
- CFLAGS should be tuned for "the less space taken the better", i.e. -Os. It's the one optimization that makes most sense for a system that has to live in a very limited space; at any rate, if you want to use something different suit yourself - I don't even know how much space you actually save.
Once you're done, don't forget to activate whatever services you need. By the way, go for the parallel startup of services (RC_PARALLEL_STARTUP in /etc/conf.d/rc), it makes a huge difference when booting from a livecd.
Here is your /etc/fstab:
| Code: | unionfs / unionfs defaults 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
none /dev/pts devpts defaults 0 0 |
Whatever the system you built, this is what you must use. Add whatever you want but leave these lines unchanged. If you don't understand this particular configuration don't worry, by the end of this guide everything will be clear. Read it again after you've read the section of this guide that explains the initrd and the linuxrc script.
Our bootloader will be ISOLINUX since Grub doesn't work properly on many laptops.
First create a directory under /boot called "isolinux". Copy inside that directory the file /usr/lib/syslinux/isolinux.bin and create an empty isolinux.cfg:
| Code: | mkdir /boot/isolinux
cp /usr/lib/syslinux/isolinux.bin /boot/isolinux/
touch /boot/isolinux/isolinux.cfg |
Here is your isolinux.cfg:
| Code: | timeout 1
default linux
label linux
kernel vmlinuz
append initrd=initrd init=/linuxrc root=/dev/ram0 |
As you can see our kernel will be named "vmlinuz". The "append" command does exactly what you think it does, which is appending whatever follows it to the kernel command line. The first parameter specifies the initrd to load in memory, the second states that the kernel must start an executable called "/linuxrc" instead of the default /sbin/init and the last tells the kernel to mount as root /dev/ram0, which will point to the initrd loaded in memory. We'll talk extensively about initrd and linuxrc scripts later on so for the moment hold your horses.
Don't exit the chroot yet; we need to make some tuning and install a generic kernel.
You have completed the first, most boring part of the guide.
2. TUNING THE DIRECTORY TREE (AND OTHER IMPORTANT THINGS)
(a.k.a. fix Gentoo so it will run from the cd)
If for any reason you dropped out of the system we're building, chroot back into it.
The directory /var contains two huge directories that we won't put inside the finished livecd; they are "cache" and "db". These are portage-related and completely useless as you won't emerge anything from a running read-only livecd, so let's move them together with other portage components that will be left out of our disk:
| Code: | cd /var
mv cache db /usr/lib/portage/
ln -s /usr/lib/portage/cache cache
ln -s /usr/lib/portage/db db |
That's it for /var. As you will see later, /usr/lib/portage will be left out of our livecd, freeing some precious space.
One other thing we must do is to modify the checkroot service. If we don't it'll try to remount the root filesystem readonly, causing problems with unionfs and making the bootup fail.
Change the file so that it contains only the following:
/etc/init.d/checkroot:
| Code: | #!/sbin/runscript
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
depend() {
before *
}
start() {
return 0
}
# vim:ts=4 |
Nothing less, nothing more than this.
We're finished adjusting things.
Don't exit from the chroot yet.
3. KERNEL CONFIGURATION
(a.k.a.: beyond genkernel)
Writing a generic kernel configuration is far from trivial. We're lucky enough since genkernel does it for us when we need a generic kernel for a regular Gentoo installation, but that tool is not perfectly suited for the custom livecd we want to build; kernels generated with it rely on the functionality of genkernel's initrd, which contains a complex script we don't want to modify as it would make things way too complex.
My advice is to start with a simple kernel that runs on the hardware you own; you can go back inside our "build environment" (next section) later and spend some more time on kernel configuration once most of the difficult things have been dealt with.
If you feel like doing it right now but you still don't have the knowledge needed to do it, here's what I did the first time I built a livecd: I simply ran genkernel and stopped it while it was compiling. At that point genkernel had already placed a fine .config in /usr/src/linux. All I needed to do was to run "make menuconfig" and switch from "M" to "Y" anything I thought would be needed before mounting /, like IDE and SCSI drivers. Easy and fast, but I got a huge kernel with support for lots of hardware almost nobody owns.
Make sure you choose "Y" for ext2, squashfs and iso9660 filesystem support; you also need initrd support and you should make the default initrd size more than 9 megabytes.
Since we're going to use union, you'll have to include union support too. To keep things simple, please avoid doing emerge unionfs as it will only build a module. We want unionfs INSIDE the kernel. To get union inside the filesystem menu in menuconfig, download the appropriate version of unionfs for your kernel from the table on http://www.filesystems.org/project-unionfs.html and then untar the tarball, cd into the directory it created, and run patch-kernel.sh /usr/src/linux to patch your current kernel. Next time you run menuconfig, unionfs will be under File systems --> Miscellaneous filesystems --> Union fs support.
[thanks to peaceful for the correction]
Once you're done configuring, compile the kernel and install its modules; name the kernel bzImage "vmlinuz", copying it in /boot/isolinux/. If you want you can use a better name, like "kernel-2.6.12-gentoo-r2", but make sure you change isolinux.cfg accordingly.
You can now exit from the chroot. We won't be going back into our Gentoo installation for a while.
4. PREPARATION OF THE BUILD ENVIRONMENT
(a.k.a.: make "mkdir" sound cool)
The following list of directories describes the "environment" in which our livecd will be built:
| Code: | source
backup
boot
usr-lib-portage
usr-include
usr-portage
usr-share-doc
usr-share-info
usr-share-gtk-doc
usr-share-man
usr-src
usr-X11R6-man |
All of this dirs must be created under ${LIVEDIR}, except of course the directory "source" we have just filled with Gentoo c00ln3ss. Create all of them now.
So, how does it work? The directory usr-include will hold the contents of /usr/include, usr-portage the contents of /usr/portage and so on. This are some of the many dirs containing totally useless things that portage installed, like headers or documentation. We do need headers when we emerge something and docs to read up things we forgot, so instead of deleting them we're moving them out of the installation, keeping them nearby. In the end they'll be left out of the cd since we'll include only what's under the ${LIVEDIR}/source directory.
Before you actually move the files, take note of the following:
Note that we're moving /boot out of the system even though it'll obviously be required. That's ok, when we get to the point of building the livecd you'll see that it will be included on the disc after all, just not in the same way as the rest of the system. Indeed ${LIVEDIR}/source/* will be compressed inside a single file while we want the kernel to be present on the CD outside that file, so that it can be accessed by isolinux.
Here's the list of mv commands. The directories belonging to Xorg and gtk are included here as an example:
| Code: | cd ${LIVEDIR}
mv source/boot/* boot
mv source/usr/include/* usr-include
mv source/usr/portage/* usr-portage
mv source/usr/lib/portage/* usr-lib-portage
mv source/usr/share/doc/* usr-share-doc
mv source/usr/share/info/* usr-share-info
mv source/usr/share/man/* usr-share-man
mv source/usr/X11R6/man/* usr-X11R6-man
mv source/usr/src/* usr-src
mv source/usr/share/gtk-doc/* usr-share-gtk-doc
#WARNING it's NOT /source/usr/share/gtk/doc |
In the same way you can move anything that you think isn't needed out of the base system, e.g. most of gcc. If you mess up you can always go back by moving things back under their original directory. At the moment, however, you should stick to this list; it won't save a huge space but it's good enough for our first prototype. After you've made your first iso you'll be able to go beyond this guide easily.
Now that we have cleaned our base system from uncool things we can't emerge anything anymore. To get back the ability to add software and read man pages we need to bind the directories under ${LIVEDIR} back to their original place under ${LIVEDIR}/source. Here's the script to do it, just to save some of your time. It also mounts proc and binds dev and sys so you can chroot into it immediately after you run it:
prepare_env:
| Code: | #!/bin/bash
cd ${LIVEDIR}
mount -t proc none source/proc
mount -o bind /sys source/sys
mount -o bind /dev source/dev
mount -o bind usr-src/ source/usr/src
mount -o bind usr-portage/ source/usr/portage
mount -o bind usr-lib-portage/ source/usr/lib/portage
mount -o bind usr-include/ source/usr/include
mount -o bind usr-share-info/ source/usr/share/info
mount -o bind usr-share-man/ source/usr/share/man
mount -o bind usr-share-doc/ source/usr/share/doc
mount -o bind usr-share-gtk-doc/ source/usr/share/gtk-doc
mount -o bind usr-X11R6-man/ source/usr/X11R6/man |
Here is the script to umount everything so you don't have to waste time writing it:
release_env:
| Code: | #!/bin/bash
cd ${LIVEDIR}
umount source/proc
umount source/sys
umount source/dev
umount source/usr/src
umount source/usr/portage
umount source/usr/lib/portage
umount source/usr/include
umount source/usr/share/info
umount source/usr/share/man
umount source/usr/share/doc
umount source/usr/share/gtk-doc
umount source/usr/X11R6/man |
Now we're all set. We can "switch on and off" the directories needed to compile packages; while they're "switched on" we can chroot inside ${LIVEDIR}/source and emerge anything. If you want to backup your system before making some dangerous changes, just run prepare_env, umount sys dev and proc by hand and finally tar source/*.
For the advanced users: if you're wondering why I didn't just build an exclude list so I could pass it to mksquashfs, there's a simple reason. If you move something out of the base system and you're not sure if it really is unneeded, you can just mount proc, sys and dev and chroot inside the system to see if things still work. That's a lot of time saved since the alternative is to spend 20 minutes running the build script and burning the cd.
5. INITRD CREATION
(a.k.a.: head starts to spin)
An initrd is the image of a partition, usually formatted in ext2 (it must be little), containing some basic tools like mount and our linuxrc script. What we're going to do right now is to create an initrd that contains everything linuxrc needs.
Here is a simple list of things that happen when Linux boots up. It's not complete or exaustive, just good enough for what we have to do. Refer to the isolinux configuration I gave you in the first section as you read the list.
1- The kernel and initrd are loaded in the RAM
2- The kernel takes over and goes through a hardware recognition routine, activating all the drivers you compiled inside it. Anything compiled as module isn't usable yet.
3- The kernel mounts the root partition specified by the "root" parameter specified in isolinux's configuration. In our case root equals /dev/ram0, which is the device bound to the initrd that has been loaded. That means the kernel mounts the initrd as the root partition.
4- The kernel calls init. Since we passed the parameter init=/linuxrc, instead of /sbin/init the kernel executes /linuxrc. That's a script we'll write later (next section)
5- The linuxrc script takes over. What it can or cannot do depends on what we put inside the initrd (this section deals with just that). Kernel modules are still off-limits with the initrd we'll create. At the end the script will call the real /sbin/init
6- /sbin/init takes over. Gentoo boots normally going through all the services you activated.
Keep all this in mind and this section and the next will make a lot more sense.
We're going to create an initrd and then write a linuxrc script, effectively completing the livecd "framework". Once we've gone through this we can finally backup everything and start building whatever system we want, be it it a MythTV box or a diagnostics system.
First of all, create an empty file, 8 MB should be enough:
| Code: | | dd if=/dev/zero of=${LIVEDIR}/boot/isolinux/initrd bs=1M count=8 |
Bind the file to a loop device and format it ext2:
| Code: | losetup /dev/loop0 ${LIVEDIR}/boot/isolinux/initrd
mkfs.ext2 /dev/loop0 |
Now we have an 8 MB "partition file" bound to /dev/loop0 and we can mount/umount it and copy files in it at will.
Start by mounting it anywhere, laying out the basic directory structure of a root partion and touching some files:
| Code: | mount /dev/loop0 /mnt/initrd
cd /mnt/initrd
mkdir etc dev lib bin proc new cdrom static dynamic union
touch linuxrc
chmod +x linuxrc
touch etc/mtab
touch etc/fstab |
Now we need to copy inside the initrd all the executables we will need. Here is a list:
| Code: | /bin/sh
/bin/cat
/bin/mount
/bin/umount
/bin/mkdir
/bin/chroot
/bin/tar
/sbin/pivot_root |
All those files go under /mnt/initrd/bin. pivot_root goes there too. Copy them now.
Next we have to copy inside the initrd all the libraries needed by those executables we just copied. To find out which libraries you need, use the comamnd "ldd". Like this:
| Code: | #> ldd /bin/sh
linux-gate.so.1 => (0xffffe000)
libreadline.so.5 => /lib/libreadline.so.5 (0xb7f72000)
libhistory.so.5 => /lib/libhistory.so.5 (0xb7f6b000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7f33000)
libdl.so.2 => /lib/libdl.so.2 (0xb7f2f000)
libc.so.6 => /lib/libc.so.6 (0xb7e42000)
/lib/ld-linux.so.2 (0xb7fad000) |
Run ldd once for each executable and copy all the libraries listed by it under /mnt/initrd/lib. Ignore linux-gate.so.1.
We need to populate /dev with devices so we have access to the hardware. Since we're not going to use udev in the initrd, we have to create the following devices by hand:
| Code: | mknod /mnt/initrd/dev/console c 5 1
mknod /mnt/initrd/dev/null c 1 3
mknod /mnt/initrd/dev/hda b 3 0
mknod /mnt/initrd/dev/hdb b 3 64
mknod /mnt/initrd/dev/hdc b 22 0
mknod /mnt/initrd/dev/hdd b 22 64
mknod /mnt/initrd/dev/tty c 4 0
mknod /mnt/initrd/dev/loop0 b 7 0 |
Console, null and tty are the bare minimun you can have. Then we have the hd*, which will let us mount the cdrom, while loop0 will be needed to mount the compressed (squashfs) root image.
If your cd-rom drive is not an IDE or if you plan on adding support for non-IDE drives you'll need to create other devices and modify slightly the linuxrc script; however this guide will now proceed assuming you, like most people, own and use and IDE drive.
Don't umount the initrd yet.
Alternatively:
| STrRedWolf wrote: |
Using Busybox in the initrd
Gentoo always builds a copy of Busybox, which is a small integrated subset of utilities. It currently lives in /bin/busybox. Instead of all those major utilities when building the initrd:
- Copy Busybox over into the initrd's /bin,
- symlink initrd's /bin to /sbin
- chroot . /bin/busybox sh
- In the chroot: 'busybox --install -s'
This will install all the symlinks for all the utilties we need for the initrd, and then some.
- Exit the chroot.
|
6. THE LINUXRC SCRIPT
(a.k.a.: back to sh)
The linuxrc script is very volatile and can explode in your face without any warning so pay extra attention.
The starting point is a situation in which we have unrestricted access to the whole PC and we can manipulate whatever is attached to it, provided we have put the necessary devices under /dev inside the initrd; the objective is to create an environment where our linux installation can run. Whatever modifications we have made to the system, like squashing it, must be "canceled"; we need to make them transparent to Gentoo so it finds everything it needs and can boot normally without any hacking of the base system. The tool we'll use to do all this is the linuxrc script.
First of all, here's a list of things you have inside the cd:
- livecd.squashfs: this file contains the whole root, minus what we moved out of it. It's compressed and we can mount it with mount -o loop.
- /boot: here we have things we're not going to care about (kernel, initrd, isolinux) because by the time the linuxrc script is executed they all have long since finished doing their job.
Mainly we need to do three things, which will break down to several commands:
1- Since right after booting we don't know where the livecd is, even if that's where the kernel was loaded from, we need to probe all the IDE devices we can access through /dev/hd*.
2- Once we have found and mounted our livecd, we need to provide the "root partition"; we will simply mount -o loop livecd.squashfs. We also need to solve the problem of having rw access to the system, which will involve creating a ramdisk and merging the ramdisk and the squashed root image using unionfs. The union between the two filesystems will be mounted under /union.
3- We have to use pivot_root. The objective here is to change / from the initrd's root to /union; at that point we can simply call init to finally go all the way to the console/Gnome/KDE.
I'll now list and comment each code fragment. Don't copy/paste yet, you'll find the whole script in one piece at the end of this section. If you're impatient or very knowledgeable, you can skip the next part, get the script and move on.
We start like in any script, declaring who's going to interpret it. In this case, sh. Then since we have placed all our executables in /bin we set PATH to that directory:
| Code: | #!/bin/sh
export PATH=/bin |
Next we should get the kernel parameters since some of them may be important for init. When we call init we'll pass them on. To get them we have to mount /proc, they'll be inside /proc/cmdline:
| Code: | mount -t proc none /proc
CMDLINE=`cat /proc/cmdline`
umount /proc |
Then we need to find the livecd; this fragment should be almost self-explanatory: we loop trying to mount hda, hdb, hdc and hdd until we find the right one. When the loop ends either we have found the cd or something has gone terribly wrong. In the second case we're stuck and we must stop.
| Code: | CDROM=""
for x in hda hdb hdc hdd
do
mount -t iso9660 -r /dev/${x} /cdrom > /dev/null 2>&1
if [ "$?" = "0" ]
then
CDROM="${x}"
break
fi
done |
So, have we found it or not?
| Code: | if [ "${CDROM}" == "" ]
then
echo "FATAL --- LIVECD NOT FOUND"
exec /bin/sh
exit
fi
echo "LiveCD found in /dev/$CDROM" |
Ok we're done gathering data. From now on everything we do will create, step by step, a sane environment we will be able to boot Gentoo inside of.
First of all, we have to mount livecd.squashfs, which contains our compressed root image. The target is /static.
| Code: | | mount -t squashfs -o loop /cdrom/livecd.squashfs /static |
Now we have to mount a ramdisk under /dynamic so we can later merge static and dynamic in /union.
The command to create a ramdisk is:
| Code: | | mount -t tmpfs -o size=<size> none /target/directory |
This will mount a ramdisk of the specified size under the specified target directory. The ramdisk will occupy 0 bytes until we start filling it and will grow and grow until it reaches the specified size; it won't grow bigger than that.
Here's what will go inside the linuxrc script:
| Code: | | mount -t tmpfs -o size=300 none /dynamic |
If you think 300 is too big as a limit feel free to reduce it (or increase it).
Finally we have to merge /static and /dynamic. The command to create a union is:
| Code: | | mount -t unionfs -o dirs=/dir1=ro,dir2=rw,dir3=ro,dir4=rw unionfs /union |
Basically we're saying that we want to merge those 4 directories, dir1 and dir3 are read only while dir2 and dir4 are writable. The files in each directory will appear all under /union as if they were all inside the same directory. If there are files that have the same exact name, the file belonging to the directory that appears first -- more on the left -- in the mount command gets the priority. The same mechanism is used to decide where files are written; in this particular example everything will be written in dir2/ until there's no space left, then dir4 will be used.
Our case is particularly simple; we have a read-only directory, /static, which holds all of the files. The other directory, /dynamic, is writable and enpty. This means we don't have to worry about priorities at all, we'll just merge the two dirs and be done with it. This is what we'll put inside the linuxrc script:
| Code: | | mount -t unionfs -o dirs=/dynamic=rw:/static=ro unionfs /union |
Simple, isn't it?
To make things easier to understand here is an image I've made that describes where everything is mounted at this point in the linuxrc execution:
| Code: | Before pivot_root:
/ (ext2 initrd)
|
|----- cdrom/ (iso9660) --->---|
| |
| livecd.squashfs via loop
| |
|----- static/ (squashfs) <----|
| |
| |----------->----------\
| union-|
|----- dynamic/ (tmpfs) ------->----/ |
| |
| |
| |
|----- union/ (unionfs) <----------------|
|
I hope it's as clear as it seems to me. As you can see our "root partition", the one containing the system we want to boot, is mounted under union/. We want it to be mounted as / and to do that we have to use the pivot_root magic, like this:
| Code: | cd /union
pivot_root . initrd |
The pivot_root command can be a little tricky to understand. After we have run it, /new will be our /; the old /, which is the initrd, will be mounted uder /initrd which is inside the compressed root (livecd.squashfs). Got it? Check the man page and look at this other image:
| Code: | After pivot_root:
/ (unionfs, was "/union") <------------------|
| |
|----- initrd/ (ext2 initrd, was "/") |
| |
|----- dynamic/ (tmpfs)-->---\ |
| union--|
| |------->-------/
| |
|----- static/ (squashfs) <--|
| |
|----- cdrom/ (iso9660) -----| |
Now we have modified the environment to the point that running /sbin/init is enough to boot Gentoo. However we're not going to do it yet, and here is why:
As you can see, the initrd is still mounted under /initrd. That means 10 megabytes of RAM are still taken by things we don't need anymore. Indeed, any executable we run from now on will be run from our compressed root image, not from the initrd; the initrd itself is now completely useless.
The problem is, we can't just go on and umount /initrd. We would get a "/initrd is busy"-like error message. There are 2 things keeping us from umounting the initrd:
1) The most obvious one: our cdrom, dynamic and static are still mounted under /initrd.
2) The "sh" that's executing our linuxrc script is the one we ran from the initrd! So even if we get rid of the cdrom we still can't umount initrd until /initrd/bin/sh has died.
To claim those 10 megabytes back we're going to use some more magic:
- Check out the mount manpage. There's a "move" option. Using that we can move those mountpoints somewhere else.
- Instead of trying to umount the initrd from the the linuxrc script, which is being executed by /initrd/bin/sh, we're going to spawn a new sh -- this time it will be the sh executable that resides inside the compressed root image -- telling it in advance what it has to do: umount the initrd and run /sbin/init. By the time the new sh is actually executed the old sh from the initrd will be dead and umounting the initrd won't be a problem anymore.
Here is a last image. We have just moved cdrom, static and dynamic from /initrd to /mnt:
| Code: | After "mount -o move":
/ (unionfs) <---------------------------|
| |
|----- initrd/ (initrd) |
| |
|----- mnt/dynamic/ (tmpfs) -->--\ |
| union --|
| |------->-------/
| |
|----- mnt/static/ (squashfs) <-----|
| |
|----- mnt/cdrom/ (iso9660)---------|
|
Now the initrd is free so later we'll be able to umount it. Here is the code fragment:
| Code: | mount -o move /initrd/dynamic /mnt/dynamic
mount -o move /initrd/static /mnt/static
mount -o move /initrd/cdrom /mnt/cdrom |
One last thing we have to do about mount points is updating /etc/mtab with the contents of /proc/mounts:
| Code: | mount -t proc none /proc
cat /proc/mounts > /etc/mtab
umount /proc |
And finally we spawn a new sh which will spawn /sbin/init and let /initrd/bin/sh terminate its execution, freeing initrd completely and making it umountable.
| Code: | exec chroot . /bin/sh <<- EOF >dev/console 2>&1
umount /initrd
echo "Starting init!"
exec /sbin/init ${CMDLINE}
EOF |
Here's the linuxrc script in its entirety:
| Code: | #!/bin/sh
export PATH=/bin
for x in hdc hdd
do
mount -t iso9660 /dev/${x} /cdrom
if [ "$?" == "0" ]
then
CDROM=${x}
break
fi
done
if [ "${CDROM}" == "" ]
then
echo "FATAL --- LIVECD NOT FOUND"
exec /bin/sh
exit
fi
echo "LiveCD found in /dev/${CDROM}"
mount -t squashfs -o loop /cdrom/livecd.squashfs /static
mount -t tmpfs -o size=300 none /dynamic
mount -t unionfs -o dirs=/dynamic=rw:/static=ro unionfs /union
cd /union
pivot_root . initrd
mount -o move /initrd/dynamic /mnt/dynamic
mount -o move /initrd/static /mnt/static
mount -o move /initrd/cdrom /mnt/cdrom
mount -t proc none /proc
cat /proc/mounts > /etc/mtab
umount /proc
exec chroot . /bin/sh <<- EOF >dev/console
umount /initrd
echo "Starting init!"
exec /sbin/init
EOF |
Save the script and umount the initrd. Under ${LIVEDIR}/source create the directories we're going to use with the linuxrc script: /initrd and /mnt/cdrom, /mnt/static, /mnt/dynamic.
Run release_env.
7. BACKUP
(a.k.a.: run for cover)
It's time to do some tarring. We have a fine base system we can use to build anything we have in mind, to make sure we can get back to this point anytime let's store it somewhere safe.
First create a "backup" directory under ${LIVEDIR}, then tar the entire content of ${LIVEDIR}/source under ${LIVEDIR}/backup/basesys-backup.tbz2. This means running prepare_env, umounting by hand sys, dev and proc and then running the tar command. Maybe it would be best to create a gz archive rather than bz2 since it's way faster and you lose only a little space.
8. EMERGE NEEDED APPS - KEEPING IT SLIM
(a.k.a.: everybody knows, but just in case...)
Run prepare_env if needed, chroot into ${LIVEDIR}/source and set the USE flags according to the kind of Gentoo installation you have in mind. Here are some tips about building a slim base system, most are common knowledge.
- Don't use ccache! Its huge cache goes under /root, if you want to use it at least remember to move it out of the system.
- Make sure what you have in mind isn't too broad. We're not replacing Kanotix, what we want is a fast system that is useful in some very specific cases. E.g. if you want a MythTV/Freevo box make sure you don't add anything else. If you want a diagnostics/disaster recovery system then avoid building X. And so on.
- Thanks to KDE having been divided in its single components, you can have a very light KDE installation. Emerge kdebase-startkde and build up from there making sure you don't pull inside the system unneeded crap.
- Avoid redundancy. If you're a KDE user just use Konqueror and leave Firefox out. As great as FF is, you don't need it for 99% of the sites out there, Konq can replace it perfectly. The same is true for most DE-related things.
- Rather then using OOo or KOffice, go for Abiword and Gnumeric. They're fast, light and can replace MS apps perfectly for most users.
- Rather than going directly for MythTV, give Freevo a chance. You'll find several HOWTOs around the net helping you set it up and it makes for a great mplayer/xine interface while occupying much less space than MythTV.
- CONSIDER USING KDRIVE! Soon we'll be able to cut down on xorg's size thanks to the modular xorg, until then kdrive is very very tiny (guess what the Damn Small Linux guys are using  ). It may not be suited for what you have in mind, so check carefully what it can and what it cannot do (e.g. scrolling down pages in Konqueror is very slow under Kdrive).
Once your box is done torturing your HD, do whatever amount of configuring you need to do. If you built X don't configure it yet (more on that later). Your DE will have to wait, too, since you can't run it until X has been configured. Don't leave the chroot yet.
9. X AUTOCONFIGURATION
(a.k.a.: plug & pray)
To make the livecd truly able to run on anything, we need to put in place some kind of X autoconfiguration service that kicks in right before the login manager (or wm or whatever you use) and lays out a working xorg.conf. The package x11-misc/mkxf86config does it; pay special attention to its dependency sys-apps/hwsetup, you may want to read documentation about it as it's useful for more than creating a xorg.conf. If you're a good scripter you may build some interesting things with it. Let's move on.
| Code: | | emerge mkxf86config -av |
Once we have emerged the needed packages we can go on activating the service and making some changes.
First of all, add the mkxf86config service to the default runlevel.
The executable is /usr/sbin/mkxf86config.sh, open it with your text editor and take a look. As you can see the program assumes that hwsetup has been already run once; hwsetup works by probing every device you can imagine -- I think it uses /proc or /sys, actually -- and reporting what it actually finds. Its output is saved in a number of text files under /etc/sysconfig/.
Exit the editor and run "hwsetup". It'll take a little while. Once you get the console back, look inside /etc/sysconfig and check the text files it created, especially xserver. Those are the files mkxf86config will work with. Now delete them all, they are good only for the machine you've just run hwsetup on.
Imagine the livecd is booting. The mkxf86config script starts... and errors out: it didn't find hwsetup's output files under /etc/sysconfig. That means the first thing we have to do is to run hwsetup right before it's needed; instead of writing a service just for that little program we're going to hack /etc/init.d/mkxf86config. Modify the start function:
| Code: | start() {
ebegin "Creating X Configuration"
/usr/sbin/hwsetup
/usr/sbin/mkxf86config.sh
eend $?
}
|
Easy enough. Now mkxf86config works so add the related service to the default runlevel.
It's important to know that mkxf86config uses /etc/X11/xorg.conf.in as a template to generate a working xorg.conf; if the script doesn't work for you, try forcing some settings hacking the xorg.conf.in. You'll have to use a trial-and-error approach, but in the end you should get it to work quite easily, although it'll be time-consuming. An extended treaty on the quirks of mkxf86config is beyond the scope of this guide.
If you need more than just a working X, e.g. you want KDE/Gnome, you can't move on yet; you'll want to configure KDE/Gnome going through the inital configuration, theming it and finally setting your preferences. To do that, start by dropping out of the DE you're inside right now. Once you're back to the console with no X running, just chroot inside ${LIVEDIR}/source and run hwsetup && mkxf86config.sh by hand. Don't try to start the service, it won't work. Once mkxf86config.sh is done just run the login manager/wm/whatever and configure to your heart's content. Remeber to delete /etc/sysconfig/* and /etc/X11/xorg.conf once you're done.
If you have installed X you're probably going for a regular Gentoo system with a DE like KDE or Gnome; if that's the case and you care about giving the normal unprivileged user access to the partitions on his hard disks read the next section. Otherwise you can exit from the chroot and run release_env. We're ready to build the livecd!
10. HD PARTITIONS AUTODETECTION
(a.k.a. update fstab)
Here's a horrible script (that works) to update fstab at boot time so that the normal user has the ability to mount hard-disk partitions.
Create the directoy ${LIVEDIR}/source/mnt/temp. Then create a script under /sbin and make it executable only by root. Here's the content of the script (most of you can script better than me, if you make a better version let me know and I'll put it here):
hd_autodetect:
| Code: | #!/bin/bash
#Get a list of partitions
fdisk -l | grep /dev | awk '{print $1}'| sort | uniq | grep /dev > /tmp/disklist
#Get a list of swap partitions
fdisk -l | grep swap | awk '{print $1}' > /tmp/swaplist
#Get a list of NTFS partitions
fdisk -l | grep NTFS | awk '{print $1}' > /tmp/ntfslist
#Use a ludicrously complicated way to subtract swaplist and
# ntfslist from disklist because my coding skills suck
cat /tmp/swaplist /tmp/ntfslist >> /tmp/disklist
cat /tmp/disklist | sort | uniq -c | grep \ 1\ | awk '{print $2}' > /tmp/finaldisklist
#Go through every partition that isn't swap or NTFS and if
# the kernel can mount it then add a line for it in fstab
for i in `cat /tmp/finaldisklist`
do
mount $i /mnt/temp
if [ $? -eq 0 ]
then
DISK=`echo $i | cut -c 6-`
echo "/dev/$DISK /media/$DISK auto users 0 1" >> /etc/fstab
mkdir /media/$DISK -p
umount /mnt/temp
fi
done
#Same thing but for NTFS partitions. The line added
# to fstab is different because the NTFS module, like
# NTFS itself, sucks
for i in `cat /tmp/ntfslist`
do
mount $i /mnt/temp
if [ $? -eq 0 ]
then
DISK=`echo $i | cut -c 6-`
echo "/dev/$DISK /media/$DISK auto users,umask=000,ro 0 0" >> /etc/fstab
mkdir /media/$DISK -p
umount /mnt/temp
fi
done
#Activate the swap partitions for added pwnage
for i in `cat /tmp/swaplist`
do
swapon $i
done |
Removable media should be handled by KDE/Gnome just fine and doesn't need an fstab entry.
Call the script from local (add "/sbin/hd_autodetect" in /etc/conf.d/local.start) so that it runs before Gnome or KDE have a chance to bring up the desktop and you'll get all those nice HD partition icons. If you don't want to stop the booting process for the time needed to mount and umount all the partitions you can add "&" after "/sbin/hd_autodetect".
Exit from the chroot and run release_env, we're going to write the build scripts and create our first iso!
11. LIVECD BUILD SCRIPTS
(a.k.a.: your life just got 20 mins shorter)
It's now time to waste hours building isos. The build process will take ~15 mins plus another ~5 to burn the image; that's too short to have dinner and too long to avoid boredom. In other words, it sucks.
Here's a rough list of the things we have to do to build an image:
1- Clean out any temporary files created during our test runs.
2- Copy the ${LIVEDIR}/boot directory in a temporary dir called ${LIVEDIR}/cdroot
3- Create a squashfs image of the ${LIVEDIR}/source directory and put it under ${LIVEDIR}/cdroot
4- Build an iso that contains ${LIVEDIR}/cdroot/* and is bootable
And here is the script that does it, self-explanatory I believe:
build:
| Code: | #!/bin/bash
mkdir cdroot
cp -a boot cdroot/
cd source
rm -rf var/tmp/*
rm -rf var/run/*
mkdir var/run/dbus
rm -rf var/lock/*
cd ..
rm -rf source/tmp/*
rm -f source/etc/mtab
touch source/etc/mtab
echo squashing
mksquashfs source/ cdroot/livecd.squashfs
echo building iso
mkisofs -R -b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size \
4 -boot-info-table -c boot/isolinux/boot.cat -iso-level 3 -o livecd.iso cdroot/ |
The last command may seem a little cryptic; basically it installs isolinux inside the iso in such a way that a cd burned from that iso will be bootable. Don't waste time trying to decipher it, I lifted it right off of isolinux's site myself. You can start worrying about it if the cd doesn't boot at all .
The rest is quite clear: the output image is called livecd.iso, which will appear right under ${LIVEDIR}/, built from the contents of ${LIVEDIR}/cdroot/.
NOTE: remember to delete the cdroot directory every time you want to make a full build of the livecd running the "build" script. And backup your isos!
After you have built the squashfs image once, you won't have to rebuild it every single time you make a little change.The squashfs image contains only the read-only part of the system. If you modify things under /boot, e.g. you make a correction to the linuxrc script inside the initrd, you don't need to recreate the whole squashfs image, just rebuild the iso:
build_iso:
| Code: | #!/bin/bash
mkisofs -R -b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size \
4 -boot-info-table -c boot/isolinux/boot.cat -iso-level 3 -o livecd.iso cdroot/ |
If you have followed the guide properly you should now be able to build your first iso. Do it now!
12. TRY IT OUT!
(a.k.a.: burn baby, burn!)
Once you have the livecd.iso just burn it on some rewritable media. Slap the cd inside a machine, reboot and look out for any kind of error message. Here is what might go wrong:
- First of all, even if we're using isolinux we can't be sure the cd will boot on all of the machines on the Earth. The isolinux homepage states clearly that there are a lot of buggy BIOSes around the globe and if you're unlucky enough to own one please go read on the isolinux homepage what alternatives you can use.
- Once isolinux takes over, it'll load the kernel and initrd. If it doesn't find them check isolinux.cfg for typ0s.
- Once the kernel and initrd have been loaded, the kernel will start the hardware recognition routine. Once it's finished, the kernel will try to mount the initrd; if you get an error now, it means you compiled ext2 as a module. Compile it IN. The linuxrc script will then be executed instead of init; a lot of things could go wrong here.
- If the linuxrc script doesn't find the cdrom drive, you probably put the wrong devices inside the initrd under /dev. Check them out. If it cannot mount the cd or cannot mount the squashfs/unionfs image please check the kernel's configuration. You probably compiled as modules some filesystems that are needed, namely iso9660, squashfs and unionfs. Fix your kernel.
If the script gets to the point when it runs init and you see Gentoo starting, you've made it!
Any error you get after init starts will be probably caused by bad Gentoo configuration.
If everything's OK, good job! You have completed the basics. Now you must refine the system configuration until it's perfect. Good luck!
13. ADDING MORE ROOT IMAGES
(a.k.a.: two-seats flying saucer)
[HELD UP]
14. RUN FROM RAM MODE
(a.k.a.: process killed: out of memory)
[HELD UP]
15. FAQ && QUIRKS && BUGS
(a.k.a.: ...but does it run Linux?)
Q. Can I turn my current Gentoo system in a Livecd?
A. Sure, but it isn't covered in the guide yet. You'll have to either mount the root partition from another Linux system or copy /usr, /var, /lib etc etc in ${LIVEDIR}/source. Either way, when you have the whole system isolated inside a directory you can follow the guide. Start from the beginning and go through the FIRST STEPS section figuring out what kind of modifications you have to make to the system (fstab, install isolinux etc etc). The remaining sections should be followed normally.
Q. How much can I fit inside a CD/DVD?
A. That's quite difficult to say because in your system there are a lot of things like text files that will be compressed so much they'll almost diappear but also a lot of other things like jpg images that are already compressed and won't shrink any more. In an effort to give you an idea of how much compression you can expect, I can tell you that my ~1.1 GB source produces a ~306 MB iso.
Known quirks
1) Initrd umounting
I'm not sure but it seems that since the switch to unionfs I can't umount the initrd. I have to debug this properly, anything you find out let me know.
2) Rebooting doesn't work
I'm trying to figure out why unionfs prevents the system from rebooting properly, I'll probably have to hack some init script. As always, anything you find out...
temporary solution:
Change halt.sh:
| Code: | grep "^/dev/" /proc/mounts | grep -v cdrom | grep -v static \
| cut -d " " -f 1 | sort | uniq > /tmp/mounted
for i in `cat /tmp/mounted`
do
mount -o remount,ro $i
umount $i
done
sync && sync && sync
sleep 3
if [[ -f /etc/killpower ]] ; then
UPS_CTL=/sbin/upsdrvctl
UPS_POWERDOWN="${UPS_CTL} shutdown"
elif [[ -f /etc/apcupsd/powerfail ]] ; then
UPS_CTL=/etc/apcupsd/apccontrol
UPS_POWERDOWN="${UPS_CTL} killpower"
fi
if [[ -x ${UPS_CTL} ]] ; then
ewarn "Signalling ups driver(s) to kill the load!"
${UPS_POWERDOWN}
ewarn "Halt system and wait for the UPS to kill our power"
/sbin/halt -id
while [ 1 ]; do sleep 60; done
fi
halt -i -f -d -h -p |
Change reboot.sh:
| Code: | grep "^/dev/" /proc/mounts | grep -v cdrom | grep -v static \
| cut -d " " -f 1 | sort | uniq > /tmp/mounted
for i in `cat /tmp/mounted`
do
mount -o remount,ro $i
umount $i
done
sync && sync && sync
sleep 3
/sbin/reboot -idpk
# hmm, if the above failed, that's kind of odd ...
# so let's force a reboot
/sbin/reboot -f |
Make sure the modified versions are the first in your PATH and modify inittab so they get called. Also modify kde/gdm configuration accordingly if you use them.
[thanks to schneekater for his help on this]
16. SPECIAL THANKS
To the Gentoo community for its continued support during my first year of Gentoo Forums membership.
To Yuki Kajiura. Without your soundtracks keeping me sane this guide wouldn't exist.
To my cat. Without your frantic jumping on and off my keyboard the scripts in this guide wouldn't exist.
This guide has been written with Kate under KDE 3.5 running over a SourceMage installation.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox!
Last edited by Lepaca Kliffoth on Wed Apr 18, 2007 5:59 am; edited 27 times in total |
|
| Back to top |
|
|
dbasetrinity
Apprentice
Joined: 25 Jun 2005
Posts: 167
|
| Posted: Fri Dec 09, 2005 4:14 am Post subject: |
|
|
| Nice looking How to, I think i shall give it a try |
|
| Back to top |
|
|
linuxchimp
n00b
Joined: 12 Dec 2005
Posts: 25
|
| Posted: Mon Dec 12, 2005 4:55 pm Post subject: |
|
|
| have you considered using unionfs for writing to the filesystem? |
|
| Back to top |
|
|
Gotterdammerung
l33t
Joined: 11 Feb 2004
Posts: 627
Location: Rio de Janeiro, Brazil
|
| Posted: Tue Dec 13, 2005 11:01 pm Post subject: |
|
|
really nice indeed.
_________________
A mind that is stretched by a new experience can never go back to its old dimensions. - Oliver Wendell Holmes |
|
| Back to top |
|
|
MixMax
n00b
Joined: 28 Jan 2005
Posts: 73
Location: Finland
|
| Posted: Wed Dec 14, 2005 1:59 pm Post subject: |
|
|
| If this would use unionfs this would be perfect howto. There is a small howto in the last livecd topic (somewhere in the early pages) how to get livecd with unionfs (recoment it). |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Fri Dec 16, 2005 8:02 am Post subject: |
|
|
Sorry guys for some reason I stopped being notified of your replies. If you want me to add unionfs support please explain the advantages of it. Then if I think it's interesting I'll test and add it. Sorry but don't have the time to check things myself so give me a hand ^^
edit: actually, I did have some time today and managed to look into the unionfs thing. I'm going to add it to the guide during the weekend; actually, it'll replace the current symlink mess and you won't have to sweat so much to make things writable. Just give me some time to determine the best directory layout and test stuff.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Sun Dec 18, 2005 9:42 pm Post subject: |
|
|
I have switched one of my livecds to unionfs. Great stuff. However there's one outstanding bug in that particular liveced, as soon as I either fix it or make sure it doesn't have anything to do with union I'll update the guide. Anyone who's following the guide right now (probably nobody, heh) be warned that it will change considerably, so if you want to go on with the current one save it somewhere on your disk! You have time until tomorrow evening (GMT+1). Any section dealing with the linuxrc script, the initrd and/or the build environment will change. The section about tuning the directory layout will be completely rewritten. The livecd build scripts will change too since they're tied to the build environment.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
thedangerouscrew
Tux's lil' helper
Joined: 03 Nov 2004
Posts: 110
|
| Posted: Sun Dec 18, 2005 11:31 pm Post subject: |
|
|
i have been trying to make a slax like livecd and the only thing that is keeping me
from getting it to work is that unionfs craps out when i boot my cd.
i get "unable to handle kernel null pointer"
i have done some research on this and haven't found much help. needless to say i haven't
gotten this resolved.
forums i visited:
http://slax.linux-live.org/forum/
http://www.knoppix.net/forum/
i wish you luck and i will post any helpfull info i find |
|
| Back to top |
|
|
thedangerouscrew
Tux's lil' helper
Joined: 03 Nov 2004
Posts: 110
|
| Posted: Mon Dec 19, 2005 12:14 am Post subject: |
|
|
ok i fixed my problem. what i did to fix my problem is that i
downgraded to unionfs-1.0.11.
this should helps if you were getting the same error i was |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Mon Dec 19, 2005 9:40 am Post subject: |
|
|
My problem is that QT claims it can't write in some temp file under /usr/tons/of/subdirs and KDE doesn't start. I have to figure out what the hell is happening, which is exactly what I'm starting to do right now. I had stability problems (oopses) with union but instead of downgrading I upgraded to 1.1.1 and now I get no oops.
When I'll update the guide one of the improvements will be that we'll be able to umount the initrd and claim 10 MB back. The upgrade will happen in 10-12 hours from now. Shortly after I'll clean out the "run from ram" section and by the end of the week you'll get a proper howto for that too.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
Gotterdammerung
l33t
Joined: 11 Feb 2004
Posts: 627
Location: Rio de Janeiro, Brazil
|
| Posted: Mon Dec 19, 2005 4:48 pm Post subject: |
|
|
I have a system if KDE, Qt, OpenOffice, etc installed, and I plan to create a stage4.tgz-like backup file, or a LiveCD. In case it will become a LiveCD, what it is the maximum size it may reach in order to still fit a CD?
Thanks!
_________________
A mind that is stretched by a new experience can never go back to its old dimensions. - Oliver Wendell Holmes |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Mon Dec 19, 2005 6:38 pm Post subject: |
|
|
| Tleilaxu wrote: | I have a system if KDE, Qt, OpenOffice, etc installed, and I plan to create a stage4.tgz-like backup file, or a LiveCD. In case it will become a LiveCD, what it is the maximum size it may reach in order to still fit a CD?
Thanks! |
This is a strange question. 700 MB?  If you mean how much you can compress the system using squashfs you can't tell until you've compressed it and have seen the size of the image; for reference I can tell you the source for the livecd I test things on is 1.1 GB and it produces a 310 MB iso.
----------
OK newsflash: KDE doesn't work with uonionfs and kernel 2.6, no matter what. I'm putting on hold the switch to unionfs until this problem has been solved. If you're curious about why it doesn't work, all I can tell you is that DCOP doesn't work at all. I have no idea about the _real_ why.
For those of you who still want to switch to unionfs, expect an addition to the guide by tomorrow (sorry but it's not top-priority anymore as there's no way to tell how many bugs could arise from using union at this point).
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
Gotterdammerung
l33t
Joined: 11 Feb 2004
Posts: 627
Location: Rio de Janeiro, Brazil
|
| Posted: Mon Dec 19, 2005 11:17 pm Post subject: |
|
|
| Lepaca Kliffoth wrote: | | Tleilaxu wrote: | I have a system if KDE, Qt, OpenOffice, etc installed, and I plan to create a stage4.tgz-like backup file, or a LiveCD. In case it will become a LiveCD, what it is the maximum size it may reach in order to still fit a CD?
Thanks! |
This is a strange question. 700 MB? If you mean how much you can compress the system using squashfs you can't tell until you've compressed it and have seen the size of the image; for reference I can tell you the source for the livecd I test things on is 1.1 GB and it produces a 310 MB iso. |
That will do. Thanks!
_________________
A mind that is stretched by a new experience can never go back to its old dimensions. - Oliver Wendell Holmes |
|
| Back to top |
|
|
thedangerouscrew
Tux's lil' helper
Joined: 03 Nov 2004
Posts: 110
|
| Posted: Tue Dec 20, 2005 2:04 am Post subject: |
|
|
i've had that problem before on a hd install a couple of times and it been a permission
problem. i can boot my live cd into kde but i'm running as root. i don"t know if it works
for a user account
note: in order for unionfs to work on a live cd you have to disable mounting rootfs
as ro during bootup
http://www.unionfs.org/ |
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Tue Dec 20, 2005 11:05 pm Post subject: |
|
|
Looks pretty nice but I prefer using genkernel's initramfs (easier and more compatible)
Perhaps add a step 'Adding a motd'
which is just adding words to /etc/motd
e.g.
| Code: | # cat /etc/motd
Welcome to the super livecd
Type 'gdm' to get started!
visit http://website.com for more information! |
Also, what I do is...
# emerge livecd-kconfigs
(Fetch the all-over compatible gentoo livecd configurations)
# cp /usr/share/livecd-kconfigs-2005.1/x86/2.6.12-smp /usr/src/linux/.config
(for my amd64 it is, .../livecd-kconfigs-2005.1/amd64/2.6.12-smp)
Then I edit it as necessary, i add reiser4 personally (after patching gentoo-sources) but you could do things like ALSA, etc
# cd /usr/src/linux; make menuconfig
Then, after setting up gensplash I build it with...
# genkernel all --gensplash=livecd-2005.1 --no-clean
Then edit isolinux.cfg for splash...
# nano /isolinux/isolinux.cfg
LABEL ...
APPEND ... vga=791 splash=silent,theme:livecd-2005.1 quiet CONSOLE=/dev/tty1 ...
Then you have your initramfs-genkernel-gentoo-r* and kernel-genkernel-gentoo-r* in /boot and are ready to go.
I think it is easier, and it is the most compatible thing you are going to get 
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land. |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Wed Dec 21, 2005 10:12 am Post subject: |
|
|
| thedangerouscrew wrote: | i've had that problem before on a hd install a couple of times and it been a permission
problem. i can boot my live cd into kde but i'm running as root. i don"t know if it works
for a user account
note: in order for unionfs to work on a live cd you have to disable mounting rootfs
as ro during bootup |
Every single KDE component crashes. On the unionfs mailing list people are saying that KDE doesn't work on 2.6+union. What can I do? 
| cheater1034 wrote: | | Looks pretty nice but I prefer using genkernel's initramfs (easier and more compatible) |
If you mean the kernel config is the most compatible we can get, sure. I don't see how the initramfs is more compatible, though, since in my initrd I only mount and umount things. Maybe you mean it's got more features? I can assure you that the initrd I've explained (which is pretty much the same as veezi's) has worked flawlessly on many pcs.
| cheater1034 wrote: | Perhaps add a step 'Adding a motd'
which is just adding words to /etc/motd
e.g.
| Code: | # cat /etc/motd
Welcome to the super livecd
Type 'gdm' to get started!
visit http://website.com for more information! |
|
Next time I update I'll put this in the guide
| cheater1034 wrote: | [code]Also, what I do is...
# emerge livecd-kconfigs
(Fetch the all-over compatible gentoo livecd configurations)
# cp /usr/share/livecd-kconfigs-2005.1/x86/2.6.12-smp /usr/src/linux/.config
(for my amd64 it is, .../livecd-kconfigs-2005.1/amd64/2.6.12-smp)
Then I edit it as necessary, i add reiser4 personally (after patching gentoo-sources) but you could do things like ALSA, etc |
I'll test this and put it in the kernel configuration section of the guide.
edit: oh and I'm still working on the unionfs addition for those who want to use it. Sorry but everything always takes longer than I think
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Wed Dec 21, 2005 3:36 pm Post subject: |
|
|
| Lepaca Kliffoth wrote: | | thedangerouscrew wrote: | i've had that problem before on a hd install a couple of times and it been a permission
problem. i can boot my live cd into kde but i'm running as root. i don"t know if it works
for a user account
note: in order for unionfs to work on a live cd you have to disable mounting rootfs
as ro during bootup |
Every single KDE component crashes. On the unionfs mailing list people are saying that KDE doesn't work on 2.6+union. What can I do?
| cheater1034 wrote: | | Looks pretty nice but I prefer using genkernel's initramfs (easier and more compatible) |
If you mean the kernel config is the most compatible we can get, sure. I don't see how the initramfs is more compatible, though, since in my initrd I only mount and umount things. Maybe you mean it's got more features? I can assure you that the initrd I've explained (which is pretty much the same as veezi's) has worked flawlessly on many pcs.
| cheater1034 wrote: | Perhaps add a step 'Adding a motd'
which is just adding words to /etc/motd
e.g.
| Code: | # cat /etc/motd
Welcome to the super livecd
Type 'gdm' to get started!
visit http://website.com for more information! |
|
Next time I update I'll put this in the guide
| cheater1034 wrote: | [code]Also, what I do is...
# emerge livecd-kconfigs
(Fetch the all-over compatible gentoo livecd configurations)
# cp /usr/share/livecd-kconfigs-2005.1/x86/2.6.12-smp /usr/src/linux/.config
(for my amd64 it is, .../livecd-kconfigs-2005.1/amd64/2.6.12-smp)
Then I edit it as necessary, i add reiser4 personally (after patching gentoo-sources) but you could do things like ALSA, etc |
I'll test this and put it in the kernel configuration section of the guide.
edit: oh and I'm still working on the unionfs addition for those who want to use it. Sorry but everything always takes longer than I think |
I was just considering the initrd, it is used on the Gentoo LiveCD's (which boot on EVERYTHING) so just considering, it might be a bit easier
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land. |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Wed Dec 21, 2005 4:11 pm Post subject: |
|
|
| cheater1034 wrote: | | I was just considering the initrd, it is used on the Gentoo LiveCD's (which boot on EVERYTHING) so just considering, it might be a bit easier |
No problem, just making sure what you were saying. The linuxrc inside the initramfs is quite complex and diving into it would have taken too long. The one I propose is quicker to understand and easier to mantain and add things to. As for booting, if isolinux loads the kernel properly you're done (it's that simple). There's nothing in the initrd making booting any easier. The only big problem is creating a truly generic kernel, but now that you have told me about the gentoo configuration being available in portage (I didn't know) I can add that to the kernel config section and hopefully consider the gap closed.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
thedangerouscrew
Tux's lil' helper
Joined: 03 Nov 2004
Posts: 110
|
| Posted: Thu Dec 22, 2005 1:48 am Post subject: |
|
|
my live cd
kernel: 2.6.12.2 (compiled by me)
unionfs v1.0.11 (any version higher than this, is too buggy)
and kde
it works on my live cd but i'm using slackware
you might want to take a look at this site http://slax.org
live cd with kernel 2.6.13 kde and unionfs
the sight also has a forum |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Thu Dec 22, 2005 10:27 am Post subject: |
|
|
| thedangerouscrew wrote: | my live cd
kernel: 2.6.12.2 (compiled by me)
unionfs v1.0.11 (any version higher than this, is too buggy)
and kde
it works on my live cd but i'm using slackware
you might want to take a look at this site http://slax.org
live cd with kernel 2.6.13 kde and unionfs
the sight also has a forum |
Which version of KDE are you talking about? I tested 3.5.0 and it doesn't work on any unionfs version.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
thedangerouscrew
Tux's lil' helper
Joined: 03 Nov 2004
Posts: 110
|
| Posted: Fri Dec 23, 2005 2:39 am Post subject: |
|
|
i'm running kde v3.4.2
are you using portage or are you compiling by hand?
i would compile by hand and avoid gentoo's manipulation of the source.
especialy with unionfs. |
|
| Back to top |
|
|
Lepaca Kliffoth
l33t
Joined: 28 Apr 2004
Posts: 737
Location: Florence, Italy
|
| Posted: Fri Dec 23, 2005 9:45 am Post subject: |
|
|
I'm using portage of course. Compilation by hand is WAY beyond the scope of this guide. Remember that this is not a support request to make KDE run on unionfs. This is a guide explaining how to make a livecd and I'm not going to include unionfs if it doesn't work by default. As soon as the problem is fixed (whatever it is, probably socket madness since it's DCOP crashing and making everything else crash too) and KDE, which is what many ppl use, can work over union I'll modify the guide. Anyway, I'm going to make an addition to the guide explaining how to use Union as soon as I have some time -- I had to work hard this last few days -- what's being held up is only its integration inside the guide.
_________________
It isn't enough to win - everyone else must lose, and you also have to rub it in their face (maybe chop off an arm too for good measure).
Animebox! |
|
| Back to top |
|
|
thedangerouscrew
Tux's lil' helper
Joined: 03 Nov 2004
Posts: 110
|
| Posted: Fri Dec 23, 2005 7:43 pm Post subject: |
|
|
| noted |
|
| Back to top |
|
|
victordavion83
n00b
Joined: 25 Mar 2004
Posts: 24
Location: Hallandale, FL
|
| Posted: Fri Dec 23, 2005 8:17 pm Post subject: Attempt to make my own home LiveCD |
|
|
I have a few questions before I go out trying to make my own LiveCD. First thing is that I would like to make one that will work for everyone in my house and naturally the priority would be that it works on my computer first than everyone elses afterwards.
One of the things I want it to be is a XFCE4 setup with some basic programs (web browser, office programs, IM, etc.) and wireless support when I boot. I know how I can do this on my computer (emerge rtl8180) but I know my uncle's computer would need ndiswrapper for his to work. Is there a way I can make a dynamic script to load his wireless card on start?
I also would like to include the gentoo installer if possible on the LiveCD as it's updated and becomes more official. I know the way I installed Gentoo on this computer was through the LiveDVD RR4 and he seems to have setup the installer to allow a direct copy of what is on the DVD onto your hard drive as well as build your own install. I would want to have both of those options available to me (so maybe later it could be used by anybody).
Another thing is the question of burning it onto a CD or a DVD. Will having a DVD speed up the processing at all and if so how would I go about making an image for the DVD?
For my last question I would like to ask if it's possible for me to graphically login to the setup I have created to change the layout of the programs I've installed and if so how would I go about doing it? My goal being to make the layout as close as possible to what my family would expect it to look like.
I don't mind if you don't feel like writing out a whole thing and rather link me to stuff already written to find the answers but I would love to do this for my family so they would always be able to use their systems after I'm done making this thing. Then maybe later I could come back and top the icing by asking the question of allowing on the same disk an option to load the AMD64 or the 32bit version.
I appreciate the time you have put into making this guide. I'm trying to follow it now but will wait for the replies before I get myself in way too deep. =)
EDIT: Clarified a graphical login |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
