[SOLVED] Slackware 14.0 with generic kernel results in "LZMA data is corrupt"

atelszewski · 11-30-2012, 04:08 PM

Hi,

I'm running Slackware 14.0.
The huge kernel works fine without any problem.
The problem appears when I use generic kernel with initrd. For a few times the system boots properly, but eventually it stops booting with the message:

Code:

LZMA data is corrupt
-- System halted

Running LILO solves the problem for some time, but it comes back again at random time.
I don't remember having this problem with previous versions of Slackware.

Any ideas?

--
Best regards,
Andrzej Telszewski

volkerdi · 11-30-2012, 05:05 PM

Quote:

Originally Posted by atelszewski

Hi,

I'm running Slackware 14.0.
The huge kernel works fine without any problem.
The problem appears when I use generic kernel with initrd. For a few times the system boots properly, but eventually it stops booting with the message:

Code:

LZMA data is corrupt
-- System halted

Running LILO solves the problem for some time, but it comes back again at random time.
I don't remember having this problem with previous versions of Slackware.

Any ideas?

The "LZMA data is corrupt" error is most commonly caused when the block map used by LILO to load the kernel no longer aligns with the actual data blocks for the kernel file. Usually it happens when a new kernel is installed, but lilo is not run afterwards to rebuild the kernel map. But, since you say that running LILO again solves the issue temporarily, I suspect this isn't the case here. My best guess is that it's something to do with the filesystem that the kernel is on. Are you possibly using an unusual filesystem? Some filesystems can rearrange files through automatic defragmentation or for other reasons. If so, you might try creating a /boot partition using ext2 or ext3 and running LILO again.

atelszewski · 12-01-2012, 03:33 AM

Hi,

Quote:

Are you possibly using an unusual filesystem?

Nope, I'm using ext4 (I believe it's not unusual). But anyway, then why would the huge kernel work all the time without this issue? If the generic kernel image can be corrupted, then I think in the same way the huge image could be corrupted.

For completeness here are my disk partitions:

Code:

/dev/sda1        swap             swap        defaults         0   0
/dev/sda3        /mnt/windows     ntfs-3g     defaults,noauto  0   0
/dev/sda5        /                ext4        defaults         1   1
/dev/sda6        /home            ext4        defaults         1   2

Any clue?

--
Best regards,
Andrzej Telszewski

H_TeXMeX_H · 12-01-2012, 05:32 AM

Run memtest and maybe a SMART long test.

atelszewski · 12-02-2012, 03:41 PM

Hi,

Quote:

Run memtest and maybe a SMART long test.

SMART went fine, but memtest found one of my memory modules to be faulty.
I've replaced the module and will now see if this has fixed the problem.
I'll be back to this topic in one month to tell it's solved or earlier if the problem appears again

BTW, it is strange that it was happening with generic and not with huge kernel, because both of them need to be decompressed to the memory. Really strange. But anyway I think it was about the memory, because the faulty memory region was around ~20MB at the beginning, and I assume that's the region where the kernel is more less decompressed.

Thanks for now and I hope the one month test will succeed.

--
Best regards,
Andrzej Telszewski

atelszewski · 01-02-2013, 01:46 PM

Hi,

I'm back to report that so far everything is running smoothly, I mean the problem with loading the generic kernel seems to be not appearing any more after one month or so.

Thanks to everybody for your help!

--
Best regards,
Andrzej Telszewski