Fool-proof multi-boot PC with Knoppix 6.2.1 run from HD as deault boot option.

[Capricorny]

I've just gone through these steps with a laptop (Dell Vostro 1710) setup from scratch.

1. Replace the original HD with a new, blank and possibly bigger one. Store the old one in case it is to be used the "normal" way again later. Skip partition resizing and all that kind of fiddling.

2. Run Knoppix from a USB stick. Use plain old fdisk to partition the new HD. For defensive system setup, you'll need one NTFS partition for Windows, one FAT32 partition for exchange of data with Windows plus evt KNOPPIX directory, one big Unix partition for more permanent storage, at least one system Unix partition and swap. If you intend to install several Unix variants, you'll need at least one partition for each. Separate /home and /usr/local might be useful, but they will interfere with Knoppix setup, so I skip them for now.

3. Format the exchange partition (here /dev/sda2) to FAT32 and the system and storage partitions to your file system of choice. I used ext3:

mkfs.vfat -F 32 /dev/sda2
mkfs.ext3 /dev/sda7
mkfs.ext3 /dev/sda11

4. Install Windows (in my case Vista Home) on partition 1 (in my case /dev/sda1.) Why? Well, just check out the reports of problems with network in recent Knoppix versions, and you will realize it's good to have a backup solution. Just to mention one thing.

5. Running Knoppix from the USB again. download an ISO of a current non-Knoppix Linux distro to the storage area, and burn it to CD. Why? Again, to have backup solutions available. And to check against. I used Mandriva 2010 with KDE, but the choice shouldn't matter much at all.

6. Install the Linux distro to the system partition (here /dev/sda7), let GRUB take over the booting from WIndows. But don't care too much about what works and what doesn't in this distro at first. The existence of a Linux backup solution on disk, and the GRUB install, are the essential things here.

7. Running Knoppix from the USB again, install a second USB medium and use the install-to-flash option (preferences) to make a copy on that medium. This is for avoiding any mess with a living system when you setup the system on the HD. Plus, it's a backup. So, if you were wise and already had a backup, yuou could use that.

8. Mount the FAT32 partitions. Copy the Knoppix structure from the backup (here /dev/sdc1) to the partition. (For simplicity, here I copy just everything.)

su
mount /dev/sda2 /media/sda2.
mount /dev/sdc1 /media/sdc1
cp -ar /media/sdc1/*  /media/sda2

Now you have a runnable Knoppix 6.2.1 on your hard disk. You could check if it works by starting Knoppix with the fromhd cheatcode: knoppix fromhd=/dev/sda2


9. Next step is setting up GRUB to boot Knoppix as default. The safest way to avoid trouble, is to make separate boot subdirectories for each booting option, and leave the existing setup untouched. You have to mount the system partition, which in ordinary use will be left unmounted - that's also a defensive measure. Then create a subdirectory for Knoppix, copy the actual booting files there, and modify GRUB's init file /boot/grub/menu.lst. I used emacs, of course any good editor would do.

mount /dev/sda7 /media/sda7
cd /media/sda7/boot
mkdir knx621
cd knx621
cp -a /mnt-system/boot/* .
cd ../grub
emacs menu.lst &

The modification of menu.lst is very simple in this case. Just insert a new booting option as the first. That will be used as default.

title Knoppix 6.2.1
kernel (hd0,6)/boot/knx621/linux ramdisk_size=100000 lang=en vt.default_utf8=0 apm=power-off vga=791 nomce quiet no3d loglevel=0 tz=localtime
initrd (hd0,6)/boot/knx621/minirt.gz

Here you can fill in with Knoppix cheat codes. I had to use the no3d option because Compiz doesn't get the resolution thing right on the 1920x1200 display. You could use the fromhd= option too, but in this case, the Knoppix init process finds the correct option and runs that.

10. If you haven't got it exactly right with GRUB, so GRUB won't boot Knoppix, you can still boot from USB. But, please, don't try anything fancy. You don't have to change the device.map file, you should NOT use the chainloader option etc here. Just give GRUB the kernel and the minirt.gz to chew on, and everything will run just fine. BTW, this is a great way to try out modifications. Just make more boot subdirectories for the alternatives, and you can try other kernel options, make new minirt.gz versions etc. Without breaking anything that is up and running. If you issue a df command after booting, you will not find /dev/sda7. It's not mounted. That's very nice: It's just used for booting up, you have no chance of damaging i accidentally afterwards. But /dev/sda2 is mounted as /mnt-system.

11. Now is the time to look at rc.local, for permanent setup tweaks. I tend to be very conservative and not start services that are not needed, mount volumes that aren't regularly used etc. Mine looks like this:

#!/bin/bash
#
# rc.local
#
# Start local services after hardware detection

SERVICES="cups"

for i in $SERVICES; do
 [ -x /etc/init.d/"$i" ] && /etc/init.d/"$i" start >/dev/null 2>&1
done

# Bug in initial 6.2.1 loop devices created wrong! Only one, create the rest

mknod -m660 /dev/loop/1 b 7 1
mknod -m660 /dev/loop/2 b 7 2
mknod -m660 /dev/loop/3 b 7 3
mknod -m660 /dev/loop/4 b 7 4
mknod -m660 /dev/loop/5 b 7 5
mknod -m660 /dev/loop/6 b 7 6
mknod -m660 /dev/loop/7 b 7 7


# Mounting extra persistent storage + creating directories
mkdir /store
mkdir /store/local
mkdir /store/var
mkdir /store/share
mount -o loop /mnt-system/KNOPPIX/knoppix-data2.img /store/share
mount -o loop /mnt-system/KNOPPIX/knoppix-data3.img /store/var
mount /dev/sda11 /store/local

export GDK_NATIVE_WINDOWS=1


exit 0

I have set up two additional volumes of persistent storage that get loop-mounted, as /store/share and /store/var, and the big harddisk volume is mounted on startup. Nothing more. I try to stay away from the NTFS volume. But there are a few bugs that have to be fixed, like the missing loop devices, and that is done in rc.local.

That's it. I'm writing this on the fresh install, using wifi that works right out of the box. Buliding on a Knoppix that was set up on an entirely different machine, just copying over the vmware virtual machines to the harddisk here etc. The machines could also be run from USB harddsik, but that's less efficient.

[kl522]

# Bug in initial 6.2.1 loop devices created wrong! Only one, create the rest
mknod -m660 /dev/loop/1 b 7 1
mknod -m660 /dev/loop/2 b 7 2
mknod -m660 /dev/loop/3 b 7 3
mknod -m660 /dev/loop/4 b 7 4
mknod -m660 /dev/loop/5 b 7 5
mknod -m660 /dev/loop/6 b 7 6
mknod -m660 /dev/loop/7 b 7 7

The reason for this is due to the different versions of mount.
Knoppix 6.2 uses util-linux-ng 2.13.1.1, it is using /dev/loopX, ignoring /dev/loop/X.
New versions of mount found in newer version of knoppix try to use /dev/loop/X, if it is present.

To fix the problem, alternatively :-

   rm -rf /dev/loop

This can be done in either rc.local and any other places suitable.

Cheers

[Capricorny]

The reason for this is due to the different versions of mount.
Knoppix 6.2 uses util-linux-ng 2.13.1.1, it is using /dev/loopX, ignoring /dev/loop/X.
New versions of mount found in newer version of knoppix try to use /dev/loop/X, if it is present.

To fix the problem, alternatively :-

   rm -rf /dev/loop

This can be done in either rc.local and any other places suitable.

Cheers

Maybe. But this is 6.2.1, and /dev/loop/0 is created. And used. But that's the only one, and we need more. So I'm not sure the problem is as you describe.

[kl522]

Try it.

[Capricorny]

Try it.

Yes, it works. What I still am not sure about, is the problem description

[kl522]

There is always two sides to a coin. Either you call it knoppix created not enough loop devices or you call it knoppix created one too many loop device/directory.

Furthermore, if you could just extract a copy of /bin/mount from a knoppix 6.2 and test use it on your system ( you could copy it to say /tmp, and then issue command as /tmp/mount), then you will appreciate what I mean:- That extra loop device/directory is not disturbing the system at all with /bin/mount from knoppix 6.2. If you use a newer /bin/mount, yes, it matters.

[Capricorny]

There is always two sides to a coin. Either you call it knoppix created not enough loop devices or you call it knoppix created one too many loop device/directory.

Furthermore, if you could just extract a copy of /bin/mount from a knoppix 6.2 and test use it on your system ( you could copy it to say /tmp, and then issue command as /tmp/mount), then you will appreciate what I mean:- That extra loop device/directory is not disturbing the system at all with /bin/mount from knoppix 6.2. If you use a newer /bin/mount, yes, it matters.

I still don't understand this. Knoppix 6.2.1 created /dev/loop/0 - that's enough for Knoppix to mount on, but not for other purposes. So it's not one too many directories, it conforms to what newer versions try to use, just as you write. And we can, as I did, create more ourselves. I thought it seemed better to follow the development, but basically, I just wanted it to work. (And I'm not interested in more details than I absolutely need to know..)

Using your rm -rf /dev/loop trick, /dev/loop0../dev/loop7 are created afterwards - the old way. Seems to work just nice, BUT if some programs expect the newer organization, at least in theory it could be safer to use that? Instinctively, I'm not too happy with recursively deleting devices in init scripts.

[Capricorny]

Trying to find out more about this, I really get confused, as the /dev/loop/X way of naming seems to be associated with the deprecated devfs nomenclature. So it should be /dev/loopX? I would very much like to stay out of such silly naming discussions, but that Knoppix bug just placed me there

[mecho]

I read somewhere that if /etc/mtab is a symbolic link to /proc/mounts, then the problem of system running out of loop devices occurs. In Knoppix /etc/mtab is a symlink by default. You might try to google /etc/mtab symlink loop or something like that.There is a lot of info on the subject.