Corrupted initramfs during boot (2012)

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

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

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.

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.

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.