Arch Linux

You should add more details about your setup (partitions, file systems etc)

I don't think that this is relevant, because it worked with every previous kernel and I didn't change anything at my setup except of doing some tests. And I think that adding details about my setup will lead to a wrong direction. The new kernel26.img looks pretty the same as the old kernel26.img at first glance.

Nevertheless I've got a pure SATA system with a Radeon HD 3450.

This is the relevant output of fdisk -l, /etc/crypttab and /etc/fstab:

fdisk -l:
/dev/sda5 5476 5480 40131 83 Linux
/dev/sda6 5481 5612 1060258+ 82 Linux Swap / Solaris
/dev/sda7 5613 8224 20980858+ 83 Linux
/dev/sda8 8225 121601 910700721 83 Linux

/etc/crypttab:
swap /dev/sda6
home /dev/sda8

/etc/fstab:
/dev/sda5 /boot ext2 defaults,noatime 0 1
/dev/mapper/swap swap swap sw 0 0
/dev/mapper/root / ext3 defaults,noatime 0 0
/dev/mapper/home /home ext3 defaults,noatime 0 0

/boot/grub/menu.lst:
title Arch Linux
root (hd0,4)
kernel /vmlinuz26 cryptdevice=/dev/sda7:root root=/dev/mapper/root ro 5
initrd /kernel26.img

The same problem occurs with these kernel parameters:
nomodeset
radeon.modeset=0
vga=0x324 (stands for 1280x1024 on my system)

I also added and removed the module radeon from MODULES in /etc/mkinitcpio.conf.
So this doesn't seem to be radeon related.

I tried to change the compression method in /etc/mkinitcpio.conf. But the problem appears with lzma as well as with gz.
So there must be a bug in kernel26 or its config.

/etc/mkinitcpio.conf is attached.

I found the reason. It's an outdated package in [core]. Unfortunately I don't know yet which package exactly but I guess it's mkinitcpio.
After upgrading the system to testing and generating a new kernel26.img the system boots again.
So, please, either move the packages currently in [testing] to [core] or move kernel26 2.6.32.2-2 back to [testing]. The first would be the best solution I think.

These packages were updated during my system update to [testing]:

device-mapper (2.02.53-1 -> 2.02.56-1)
udev (146-2 -> 149-1)
initscripts (2009.08-1 -> 2009.11-1)
iptables (1.4.5-1 -> 1.4.6-1)
klibc (1.5.15-3 -> 1.5.15-4)
klibc-extras (2.5-4 -> 2.5-5)
klibc-kbd (1.15.20080312-10 -> 1.15.1-2)
klibc-module-init-tools (3.8-1 -> 3.8-2)
klibc-udev (141-3 -> 141-4)
mdadm (2.6.9-1 -> 3.1.1-1)
mkinitcpio (0.5.26-1 -> 0.5.26-2)
pcmciautils (015-2 -> 016-1)
pm-utils (1.2.6.1-2 -> 1.2.6.1-3)
xz-utils (4.999.9beta-1 -> 4.999.9beta-2)
zlib (1.2.3.3-3 -> 1.2.3.4-3)

The packages which are involved into the boot process/the initrd need urgently be moved from [testing] to [core].

I suspect most mkinitcpio but every other package including the device mapper related packages could also be the reason because I've encrypted my whole system with dm-crypt/LUKS. The /boot partition is of course not encrypted.

mkinitcpio is unchanged, it has only been adjusted to some kbd change. As the klibc stuff in testing/x86_64 will never be moved to core, this is not necessary for core. I would love to move the device-mapper, udev, initscripts to core, but there are still unsolved problems with the device mapper stuff. I don't see any of those packages needed for 2.6.32 - there was probably a problem when generating your initramfs and simply regenerating it was the solution.

Simply regenerating was not the solution because I regenerated the initramfs several times with only [core] installed and with several different settings in /etc/mkinitcpio.conf. Always the same kernel panic. Only after updating the system to [testing] and regenarting the initramfs then removed the kernel panic and this with every /etc/mkinitcpio.conf settings I tested with [core].

So the reason must be one of the above mentioned packages.

If mkinitcpio is unchanged, why was it updated and has an incremented release version? I can't exclude it but I don't really think that it was the device mapper because the device mapper shouldn't have anything to do with /init in the initramfs. Or am I wrong?

Maybe later I'll downgrade each package one by one to [core] again and see when the kernel panic reappears.

It was upgraded for a fixed klibc-kbd dependency only. The code itself is unchanged. I am afraid the very small excerpt of your boot process is not enough information. Please compare the kernel26.img files (zcat kernel26.img | cpio -t) generated in each case and give a bigger excerpt of the boot process.

I don't know what was going on here but now I downgraded my system to [core] again each package one by one and the system booted every time without a kernel panic.
There was likely something broken but I can't imagine what, maybe some file permissions have been change or some files have been changed or deleted by whatever and these files were overwritten by the reinstalling/updating. Probably a reinstall of the involved package from [core] had been sufficient.

closing this now, since not reproducable at all.