LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware 14.0 with generic kernel results in "LZMA data is corrupt" (https://www.linuxquestions.org/questions/slackware-14/slackware-14-0-with-generic-kernel-results-in-lzma-data-is-corrupt-4175439502/)

atelszewski 11-30-2012 04:08 PM

Slackware 14.0 with generic kernel results in "LZMA data is corrupt"
 
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 (Post 4840460)
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


All times are GMT -5. The time now is 01:03 AM.