Possible bug with kernel decompressor.

List,

I think I found a bug here because I can repeatably get the same kernel (checked with md5sum) to decompress and to fail with the error:

invalid compressed format (err=2)

--System halted

Here is how I can reproduce the problem:

Boot 2.6.8-rc1
Run md5sum on 2.6.8-rc1 kernel
Turn power off (this is an embedded system with only ramdisk mounted) Turn power on
Kernel fails to boot with "invalid compressed format (err=2)" Restart system
Boot 2.4.26
Run md5sum on 2.6.8-rc1 kernel (matches md5sum above) Shutdown properly
boot 2.6.8-rc1 (works fine)
Run md5sum on 2.6.8-rc1 kernel (matches md5sum above)

So you see if I don't shutdown properly (which shouldn't be required for an embedded system using a ramdisk) my kernel won't decompress itself until I run another kernel and shutdown properly. I know that the kernel didn't change so something else must be causing it to fail.

I call this a bug simply because a power failure could cause someone to loose the ability to boot their machine.

Here is the hardware:
Whistle Interjet (486 SBC)
64MB of memory
IDE disk.
Can reproduce with linux 2.6.5, 2.6.6, 2.6.7, and 2.6.8-rc1
Both kernel images and the initrd image both live on a fat16 partition and are started with syslinux. I can reproduce this problem with any version of syslinux I have tried.

Please CC me in any replies since I am not on the list.

Thanks,

schu

Sorry, for the long post, I'm more doing this for the archive than anything else so others can google instead of ask.

I thought that this might be something with syslinux too, but didn't go down that road because something in the new 2.6 kernel doesn't handle this as gracefully as the 2.4 kernel.

That said, I thought I would try a different boot loader so I installed grub on the system and it seems to work fine.

I should note that this hardware requires the linux mem/memmap= params because of the buggy memory detection in the bios so I was required to use the uppermem command in grub to make it detect the memory and put the initrd image in the right place.

So in the end it looks like it is a syslinux issue loading the initrd image but for some reason the 2.4 kernel seems to be just fine with whatever isn't working right.

I can troubleshoot more if someone wants to track this down, but at this point I have a work around and now it's documented on both lists.

Thanks,

schu

Specify, please.

-hpa

This is what I am using in grub and it works:

title Linux (2.6.8)

        root (hd0,0)
        uppermem 62464k
        kernel /linux26 memmap=exactmap memmap=640K@0 memmap=63M@1M 

console=ttyS0,9600n8 load_ramdisk=1 root=/dev/root ramdisk_size=32768 ether=9,0x320,0,0x3c509,eth0 ether=10,0x330,0,0x3c509,eth1 ide0=ali14xx
initrd /rootfs.gz

This is what I was using in syslinux that broke with "invalid compressed format (err=2)" after a improper shutdown (only ramdisk mounted).

LABEL linux
KERNEL linux26
APPEND memmap=exactmap memmap=640K@0 memmap=63M@1M
console=ttyS0,9600n8 load_ramdisk=1 initrd=rootfs.gz root=/dev/root ramdisk_size=32768 ether=9,0x320,0,0x3c509,eth0 ether=10,0x330,0,0x3c509,eth1 ide0=ali14xx

hope that helps,

schu

What happens if you specify mem=64M, which should be the exact equivalent to the above?

-hpa

MS> invalid compressed format (err=2)
MS>
MS> --System halted

I had the same on Digital Celebris 5133. One debian Woody boot floppy I tried (don't remember which flavour) gave exactly this. Debian Sarge boot floppies worked fine.

Additionally, lilo didn't work, just hung.

Grub does work but something (BIOS?) garbles some of the kernel command line. I used the following kernel command line as a workaround:
abrakadabra my_real_options...
and this became
PAMSkadabra my_real_options...

Other than that it worked fine - Pentium 133, 64M RAM, onboard Adaptec SCSI, onboard Matrox video.

Meelis Roos