Full 64 bits Knoppix - a project for this site?

[Capricorny]

To avoid any extra complications, I have switched from cloop to squashfs, and by stripping down minirt init, I can get /UNIONFS correctly mounted. But there is still no way I can get next step started: With manual chroot into /UNIONFS, I can start /sbin/init, but it won't run correctly, it seems. So there must be something with busybox and full 64-bits mounting. Different versions of 64-bits busybox don't help, and compiling latest version (1.1 from source only makes things worse for me. The last resort, as I see it now, is to include mount and bash, with necessary libraries, in minirt. This is by no means far-fetched, as the two functioning 64-bits initrds I have checked, Debian 6.0.1 and Kanotix 2011/5, both include a lot of system programs, while Knoppix only has busybox and ntfs-3g. I have compiled and started using kernel 2.6.39.2-64, but it doesn't help much, it seems. (Nor did a freshly compiled cloop from Debian-Knoppix, before I turned to squashfs.)

As far as I can see, there is no need for a special init for 64-bits, just other programs. But it may be a small challenge to modify init to include squashfs handling in an optimal way.

Knoppix "pure" 64 bits full HD install works well, including qemu, which I use for testing images and minirt.gz versions. So remastering from this version should be possible.

[Capricorny]

Finally, I was able to get the remastered 64-bits image to work. I'm now booting with a minimally modified init, based on squashfs, and I got /sbin/init started by chrooting into /UNIONFS.

1. Squashfs seemed to be simpler in this case, one less thing that could go wrong.
2. Busybox and ntfs-3g turned out to be the only programs needed in minirt bin.
3. Busybox is not busybox is not busybox. Neither freshly compiled nor binary downloads of busybox 1.18 would work. Nor did Busyboxes from other live Debian distros. (As far as I could tell.). Busybox 1.17 from the Debian package worked - in a way. It wasn't able to run programs like in 32 bits init, but what it was able to do, was enough.
4. The ld-linux-x86-64.so.2 had to be used in place of ld-linux.so.2.
5. I copied dev from minirt into /UNIONFS/dev, but just dropped /proc and /sys. Trying to include those turned out to be a mistake - they are mounted and used in the first init, but if dropped, they are taken up again later.
6. Qemu was fully adequate for testing - only it has a terrible habit of not updating the minirts between invocations. I will call that a bug.
7. After working through it for quite a few days, and having compared it with alternatives, I like the minirt init script a lot, but I think it could benefit from a bit stricter and more transparent organization. As it is a primary target for smaller modifications, it should be as readable as possible.
8. The only recompiled component I have retained, is the 2.6.39.2 kernel, and I don't know if I really had to do it. So full 64 bits remastering was indeed possible with minimal compilation.
9. There are quite a few pecularities in this first version. /mnt-system is not accessible, as the system has never recovered from the initial chroot, for example

[Capricorny]

1. Now I have done remastering from cloop and squashfs images, running from squashfs, and everything seems to work quite well. Because of the chroot in init, remastering from live system should not be attempted, rather make a /tmp/UNIONFS mount (just like the version you are running from) of the files of a a working system and remaster from that.

2. As for packages, the squashfs image is now ca 3.9GB,which means I don't want to stuff in much more, I'd rather look for removal candidates. I have duplicated office in 64-bits OpenOffice and 32-bits LibreOffice, but I have found that those have different incompatibilities with M$ Office, so for the time being, I'll keep them. As soon as things settle a bit more, I'll upload the package list, and I'm interested in suggestions both for removal and inclusion.

3. 64 bits is definitely less thoroughly debugged than 32 bits. For example, Iceweasel has become unstable lately, and it's hard to tell why. For this reason, I have become a bit unsure how wise it is to stuff everything into one large package (eventually distributed on several squashfs images). Keeping the whole thing smaller seems more safe right now. But with increasing use of 64-bits, those things change.

4. Stock Knoppix 6.4.4 kernel (2.6.37) works quite fine, except for situations where bugs are exposed. (Like running on a HP Elitebook 8540p, where one of the cores is kept busy looping).

5. I have run into few hardware-related problems thus far, things seem to work more or less exactly like in 32-bits. But I'm not quite sure about this.

6. Gnome's gvfs has given me quite a few problems. I don't know if it has anything to do with 64-bits, but I decided to purge it, troubles disappear. Out went Brasero with it - making a basic utility like CD/DVD burning completely dependent on an end-user oriented add-in like gvfs is a design flaw to me. Opportunistically using available services is a much better strategy for basic utilities.

7. The 32-bits compatibility libs are definitely not enough for all actual uses, but mounting a 32-bits system and copying necessary files from that to fill in the gaps has worked perfectly for me so far.

8. Legacy grub has been essential to work efficiently with testing boot configurations and mnirts.

9. So far, I haven't found anything whatsoever that needs to be changed in the basic Knoppix system architecture to fully accomodate 64-bits. Taking an ordinary install, putting in a 64-bits minirt, changing compressed and persistent images is enough.

10. I don't think it is very smart to distribute 64-bits Knoppix without a basic persistent image. Configuration-related parts of /var will often be rewritten quite soon, leaving dead space in the cloop image which could have been used for programs. Also, it is needed for last-minute bugfixes and updates. And compressing it, we are not talking of a very large increase in download/copying size.