Strange behavior of squashfs remaster /sbin/init etc 7.0.2

[Capricorny]

After a minimal modification of minirt init, the squashfs 7.0.2 image could be booted, and there is seemingly nothing wrong with it. But I thought it was, for the booting procedure seemed to get stuck after syslog init, probably at the hw step. I tried remastering from an earlier, smaller version of 7.0.2, with or without persistent store, but nothing seemed to help Knoppix init past this step.

Then, by chance, I happened to leave the computer alone for a few minutes, and suddenly Knoppix was up and running. I have used squashfs for quite a few remasterings, and never experienced something like this. Could it be Knoppix having gotten more hard-wired to cloop lately? I could not tell that for sure from a brief look at at the occurences of "cloop" in /etc and subdirectories.

Another issue is the impaired functionality of busybox (the version in minirt.gz) loop handling. Something should be done about this, I think. There is no problem creating and using "real" /dev/loop10, but busybox maps it to /dev/loop1 - which may cause serious trouble. It's not even able to handle /dev/loop7..

[Capricorny]

Update:
The problem isn't confined to just one machine, and it may have to do with something being unstable under hw detection, I get a error message of the same kind as seen earlier with init from cloop. Maybe it's something with timing, because the squashfs loading may run at a different speed from cloop? (I would guess faster in that case.) Still no problems running the thing.

[Capricorny]

Update:
I have tried all mentioned cheatcodes for skipping HW detection/setup, to no avail. Did it in 3 alternatives.

1. nohwsetup noapci noapic
2. nosound nolapic nopcmcia noapm
3. noideraid noswap noudev nodhcp

So there really seems to be something with init/hardware detection that in some may gets uncovered with squashfs packaging.
No trouble whatsoever observed when the system is up and running.

[Capricorny]

I had suspected udev init for this initial system hang, but it seems that syslog init is in some way the culprit. I moved syslog init to the end of knoppix-autoconfig, and the timing of a typical init of a 7.0.3 remastering under qemu is as folllows:


Knoppix autoconfig
Mon Jul 9 17:00:57 UTC 2012
knoppix-autoconfig: Before start_udev Mon Jul 9 17:00:57 UTC 2012
knoppix-autoconfig: After start_udev Mon Jul 9 17:01:01 UTC 2012
knoppix-autoconfig: After start_devpts Mon Jul 9 17:01:01 UTC 2012
knoppix-autoconfig: After start_hwsetup Mon Jul 9 17:01:02 UTC 2012
knoppix-autoconfig: After start_dbus Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_hal Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_acpi Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_net Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_scr Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_swap Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_services Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: Det proc finished, before start_log Mon Jul 9 17:01:05 UTC 2012
knoppix-autoconfig: After start_log Mon Jul 9 17:06:05 UTC 2012
The rest of autoconfig seems to run just fine, but it hangs on start_log for five full minutes. With 7.0.3 I get this with both cloop and squashfs remastering. This hasn't happened before 7.0.2, and I haven't changed anything in the remastering scripts, so it's hard for me to tell what it is. With squashfs it might be that I have used 7.0.2 minirt squashfs init, but cloop init is unchanged 7.0.3 minirt.

Anybody having any idea of what this might be?