Remaster Knoppix without chroot or lengthy test cycle...

[bilkusg]

Knoppix remaster testing - new approach?.

I've been experimenting with building a customised Knoppix disk,
using the Knoppix Remastering Howto as a base.
Among my objectives was to incorporate captive-ntfs driver support,
to permit write access to NTFS drives on XP machines.

The technique described, of building a chroot environment to mimic the
final environment, and then add-remove packages as required is fine for normal software, but fails when, for example, new usernames are created, as both CHROOT/etc/passwd and the real /etc/password need to be updated.
In any particular case, it's possible no doubt to get round this, but it set me to wondering if I could set up my environment so that it was closer at design time to the runtime one.

The idea was that my hard disk should contain:
a) at top level, two directories, /knx and /KNOPPIX
b) under /knx, master and source structures as per the howto.
In particular, there's a directory called source/KNOPPIX which contains a copy of the root filesystem structure desired as the starting point.
c) symbolic links in /KNOPPIX to source/KNOPPIX/*.
It would be easier just to make a symbolic link from source/KNOPPIX to / but the linuxrc script on the boot floppy checks for a directory and I didn't want to modify that script if I could avoid it.

The idea is then that booting from a KNOPPIX floppy with no CD will find the KNOPPIX directory on the hard disk, and use that. After a successful boot, one can then remount /cdrom read-write, customise as required, and test trivially, just by rebooting. No remastering required. When everything is working, the instructions in the HOWTO still work just fine.

In practice, there were a few minor changes I had to make to the boot floppy to work and a couple of other issues.
Firstly, /etc/fstab is wrong, although /proc/mounts is right.
fstab thinks that its still the cdrom mounted on /cdrom whereas actually it's the hard disk.
mount -w -oremount /dev/hda1 /cdrom
will still work.

Secondly, more seriously, the /KNOPPIX directory on the boot filesystem on the floppy image (which is the bootstrap environment for the cd as well) in master/boot.img has some symbolic links missing. Normally that doesn't matter, as the loop mount of KNOPPIX to /KNOPPIX overwrites this directory, but when there's a KNOPPIX directory already
on the hard disk, nothing happens to that.

I solved this by adding some symbolic links to the directory to include everything in /KNOPPX on the hd. Thus when the boot occurs, we have a /KNOPPIX with lots of links to /cdrom/KNOPPIX which point in turn to /cdrom/knx/source/KNOPPIX. (remember /cdrom is really the hard disk during the development).

Redoing the boot image is a little complex for people who haven't done it. It involves mounting the boot.img file with
mkdir flopdir;mount -o loop boot.img flopdir extracting the zipped filesystem with gunzip <flopdir/miniroot.gz >miniroot
(Don't try to create the bootimage file inside the floppy directory!)
mounting that system with
mkdir bootdir;mount -o loop miniroot bootdir
adding the links into bootdir;
ln -s /cdrom/KNOPPIX/dev bootdir/KNOPPIX/dev etc ( a simple loop will work )
umount bootdir
gzip –best <miniroot >flopdir/miniroot.gz
umount flopdir

It's worth checking the result is still the right size, and copying it to a floppy to test:
dd if=boot.img of=/dev/floppy bs=18k

I'd be interested in feedback about this from any Knoppix gurus out there regarding whether this approach breaks anything subtle, as my experience with Knoppix is currently only a weekend's worth ( although I've been using linux since version 0.96 ).
In particular, I suspect that it might be cleaner to change the linuxrc script slightly. However, I'm happy because my objective succeeded and I can now write my NT partition data.

Gary Bilkus

[chaz]

Someone posted a similiar suggestion on the mailing list recently. They used it for remastering an earlier version of Knoppix.

I would really like to know how you got the write access to NTFS to work?

Thanks,
Chaz

[bilkusg]

As far as getting the ntfs write support to work, I used the interesting
captive-ntfs approach www.jankratochvil.net/project/captive/
which relies on a sandbox and the availability (legally!) of ntfs.sys and a few other files from a compatible windows installation.

My post above was inspired by the fact that when I originally tried to install captive-ntfs just by using the script provided in a chroot environment, it failed ( not surprising really ), but mainly because it tries to add a user and group 'captive'

Please note, I have not used this driver extensively in a production environment so I can't comment on how stable it is, but it basically seems to work, and since my interest in having it on a knoppix disk is to help rescue systems which are already in deep doodoo, this hardly matters.

Gary

[henrique]

c) symbolic links in /KNOPPIX to source/KNOPPIX/*.

Please, how can we do this ?

Thanks

[henrique]

Someone posted a similiar suggestion on the mailing list recently. They used it for remastering an earlier version of Knoppix.

Where is it please ?

Thanks