custom knoppix halts at creating directories on ramdisk

Hello, I remastered a knoppix in the following way:

I took the small knix cd, removed even more of the software on the iso, installed gcc and compiled some newer software. This all went fine, I burned a new knoppix cd and it booted.

Now i wanted to change the kernel:

I compiled a new kernel, 2.4.22; it has support for ramdrive and vesafb; generic IDE and scsi_generic for cdrom. I compiled cloop 0.68 ( that one seems to work best with the cd?) for my kernel, and replaced it with cloop.o in miniroot.gz, and removed the scsi modules ( I dont need them) adjusted some config files correspondently ( boot with us keymap, etc)
put the img on a floppy, it booted my older knoppix cd's with that just fine ( of course it couldnt use the kernel modules and so on, but I got to a shell)

Now, I customized the KNOPPIX image, to have the right kernel modules and software, and put it all on cd; the cd boots, but doesn't seem to go beyond this point:

Creating /ramdisk(dynamic size=996020k) on /dev/shm...Done.
Creating directories and symlinks on ramdisk....

here it just keeps blinking.
with a bootfloppy (either one, the official too) it's the same
where does this go wrong? is there something I missed out on the kernel configure( I thought not, the floppy booted just fine) or a faillure in the compressed image, or some software package I thought I could remove? or did the burning software make a faulty cd..? I used Nero (windows)to burn the ISO image since I don't have a burner in my machine ( but one on the network does)

If anyone can give me a hint, please. I've been rebooting many times now ;)

MvH

Ok, here is to this:
I wanted to double check my story, so I

1. created a fresh bootfloppy from the original cd.
2. booted with the floppy and my custom cd
3. I booted directly into knoppix with my modifications

so...the cd was OK
then I did:
copy my custom kernel and a fresh cloop.o to the *working* boot floppy
booted with the floppy and the original cd
...and booted straight into knoppix

then I tried:

booting with the custom floppy AND the custom cd...got stuck again as described above

so, where does it go wrong? is it a module that gets insmodded and hangs the system?
someting else? I'm at the end here.

ciao

mvh

have you tried to turn off the 'quiet' flag ? Also, just remove those >/dev/null 2>&1 lines in linuxrc so you can have a better understanding of which line may be causing the problem.

That is my dumb way of debugging. Sorry can't think about more.

Your kernel is 2.4.22, where and how did you get cloop.o?

Regards,

Hugo

Cloop is available source code wise from the developer site:

http://www.knopper.net/knoppix/sources/

I had the EXACT same problem, unfortunately my solution was voodoo, but it was one of two things.

I used a 2.4.22-xfs build and cloop 0.68 and 1.00, by the way, if you switch cloops, switch compressloop, create_compressed_fs and extract_compressed_fs... a KNOPPIX image file created with a new one can't be decompressed by an old cloop and vice versa... sounds obvious, and after the fact it was obvious, but it hung me up for an hour. I also switched from syslinux to isolinux and added "echo mark #1", #2, #3, etc... throughout the linuxrc file to see where exactly it hung at load... and it hung right at an inocuous copy from the ISO to ramdisk, long long into the load, and it had already done many such copies.

Enough backstory, voodoo solution:

I finally got it to work by compiling optimized i386 down from i586... this might have been the solution, but I'm willing to be the real solution was the fact that the kernel image itself was about 30% smaller. Maybe its running out of room on the ramdisk? I dunno, but go ahead and try that. My kernel ended up being:

989792 bytes

Which is just a little larger then the 2.4.20-xfs bzImage that I replaced...

Also, since the remastering I'm doing is DamnSmall Linux, I never had a single problem with using the: "KNOPPIX toram" boot parameter with the disks that would normally freeze. (120Mb uncompressed disk image loads fine on a Athy 1.0 with a 256 stick), so again... I think its a limitation of the initial ramdisk being too small?

I hope at least.

Cheers,

Finegan

I spoke too soon, the same bug crept up 1 build later with the exact same kernel...

Bloody hell...

Cheers,

Finegan