

Corrupted initramfs during boot (2012) - yew
http://blog.krill.se/2012/12/06/corrupted-initramfs-during-boot

======
jwise0
That's a pretty good one! There are many ways for the bootloader to screw you
even after it has passed control away from itself. I think my favorite similar
story is when Matt Garrett discovered this on a Mac which forgot to shut off
its wireless card's DMA controls before passing control into a UEFI client:
[http://mjg59.dreamwidth.org/11235.html](http://mjg59.dreamwidth.org/11235.html)

------
alexdowad
Great debugging work there! (Try doing that on a closed-source OS!)

------
fubarred
Sounded like too small of a debouncing cap/s on/around the nic, undersized
vcc/gnd planes and/or too small of a power supply to handle peak current.

The other thing, once a system is booting, is always make sure RAM, storage,
CPU and nics are all working, so test those individually: memtest86+ (or
rowhammer or latest memtest86 non-plus), iozone, prime95, iperf or their
equivalents.

~~~
duskwuff
The real explanation is near the end of the post -- the Ethernet controller
was inadvertently left doing DMA to a buffer that overlapped with the
initramfs.

------
userbinator
I'd go ahead with debugging without the debug symbols - it's not hard at all
if you know Asm and have the source code available as it's usually quite easy
to figure out where in the source you are.

Then again, gdb is a relative pain to use without source so it does seem to
discourage doing that.

------
convivialdingo
Sometimes it makes sense to start from the kernel level and work downward.
With symbols and source loaded, it's often faster to fully debug a complex
userspace problem. You can jump in and out of kernel space easily.

