You are not logged in.
This particular boot error seems to come and go as if it has a mind of it's own, and I'm hoping someone can shed some light on this. I'll try to be brief.
Before installation on a rather old IBM ThinkCentre with a Pentium 4 2995MHz and 1015M Memory Intel chipset i915P/G (using an old Compaq monitor and Ps2 hardware) I couldn't get Arch to boot without it freezing with the message "XZ-Compression is Corrupt. System Halted" error. I ran Memtest (apparently helps fix this as I saw in another thread) which found no errors in memory. After doing so, Arch booted properly. To experiment to make sure it wasn't a fluke, I powered off the machine and tried booting again without memtest ran and it failed to boot. I read more into the wiki and found ACPI settings could create the error, so I appended the acpi=off to the image. This worked in succession. I powered off the machine, and did so again appending the kernel image but then it failed to boot once more.
After actually installing Arch on this particular machine, the error comes and goes whether or not I append the acpi=off to the kernel image to boot (I'm using GRUB)
It seems if the machine "warms up" for a great deal of time, the error doesn't happen (like during a memtest).
To illustrate that the actual CD and data is fine (checksum integrity checks out), I tested this on a Dell Inspiron 1525 laptop. No XZ-Compression error on both pre and post installation. Another Dell PC (non laptop) also checks out fine.
So my question is, what exactly could be the cause and how I can fix this on this particular machine? Is it a power thing?
(No other threads on this particular issue I've found so far seem to shed light on this)
Offline
This is a tough bug. While this certainly smells like a memory problem, it doesn't need to be. Don't forget that it has to read that big kernel file from the disk (or CDROM) without borking it. Since it failed from both the hard drive and CDROM, the kernel filesystem portion is less likely the problem, but that still leaves the bus and disk drive adapter (PCI, PATA, etc) in the picture... along with many other things unfortunately.
So here's some suggestions off the top of my head...
Verify that the memory settings (clock, voltage, etc.) in BIOS are something (very) safe.
On a "good" boot, run "cat /proc/interrupts" and verify that the disk drive isn't sharing interrupts with another device that generates many interrupts (cough... like video). I'm going for the missing interrupt angle here.
Go on the internet and find the "kernel-parameters.txt" file that ships in the "Documentation" directory of the kernel source. Try some of those, looking slightly more closely at those in the "LIBATA" and "PCI" groupings. But certainly don't ignore the others. You can turn on the "debug" kernel parameter for verbose output during the decompression stage, but I doubt it will help much. Turning on high precision timers used to be a problem in the old days, but I'm not sure that still applies.
To possibly help with kernel parameter candidates, see if you can find a Linux LiveCD that caters to older hardware. I'm assuming that they've already suffered the pain of finding good parameters. If you can get it to boot, look at their boot parameters by running "cat /proc/cmdline and also check their modprobe options. If it fails to boot, a hardware issue on your box becomes more suspicious.
If you really want to get down and dirty, I went down the chain (I think) of that error message in the kernel source code. If you want to follow along:
In arch/x86/boot/compressed/misc.c - Function: decompress_kernel()
In lib/decompress_unxz.c - Function: unxz() <- produced message
In lib/xz/xz_dec_stream.c - Function: xz_dec_run()
What I found interesting, but I'm sure is unrelated to your problem, is that the kernel decompresses a XZ kernel directly over itself on a X86. Wild.
Perhaps others have some better ideas.
Good luck.
Last edited by pigiron (2012-06-28 15:44:26)
Offline