Syslinux - Jul 2004 - Re: Possible bug with kernel decompressor.

Matthew Schumacher wrote:
 > 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
 >
 >
 >
Tim Bird wrote:
> If I recall correctly, a number of read errors during the
> initial kernel loading can result in this error message
> (which means it is somewhat misleading.)  You may have
> to add some printks to narrow this down more (in both the
> 2.4 and 2.6 kernels)
> 
> Obviously there's something in the 2.4 code that handles
> the ungracefully-shutdown machine state better than 2.6.8.
> Or there might be some other difference between the syslinux
> boot of the 2.4 kernel and that of the 2.6.8 kernel.
> 
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

Matthew Schumacher wrote:
> 
> 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.
> 
Specify, please.

	-hpa

H. Peter Anvin wrote:
> Matthew Schumacher wrote:
> 
>>
>> 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.
>>
> 
> 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 at 0 memmap=63M at 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 at 0 memmap=63M at 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

Matthew Schumacher wrote:
> 
> 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 at 0 memmap=63M at 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
> 
What happens if you specify mem=64M, which should be the exact equivalent to 
the above?

	-hpa