Bugzilla – Bug 120973
Installation of SuSE 10.0 kernel panics when swap partition is on software raid
Last modified: 2005-10-22 18:32:38 UTC
RAID-0 is commonly used to improve performance of swap partitions. The SuSE 10 set up configures the swap partition to be the resume partition. If the swap partition is RAID then this results in a kernel panic after the first CD installs and the system reboots. To remedy the problem the user must choose the "fail safe" kernel option or edit the kernel arguments and remove the "resume=/dev/mdX" option (and possibly replace it with "noresume").
I don't expect this to be autoyast related. Kernel Panic - Hubert?
I already have a similar report but still I'm unsure what is actually meant: Does it mean a regular reboot fails or a resume? I think the latter since removing the "resume=" parameter makes a difference.
Thanks for looking into this. Its the former of your options. A regular reboot causes a kernel panic so the installation fails after the first CD. This behaviour also happened with RC1. To fix it you can either choose failsafe or edit the resume line to noresume. I have not tried a suspend/resume on this machine and doubt it would work without the resume line for grub.
i can easily imagine a bug in the "resume from initrd"-code when swap is on a RAID device. Maybe Hannes can shed some light on this.
Do you have actual messages? Can you verify if /dev/mdX is set up correctly at the time when resume is attempted by initrd code? [swap on raid seems like very strange thing to do. Unless someone audited raid code, it might randomly deadlock etc under high load. We may want to discourage that combination.]
Thanks for your help. Sorry but I have no boot messages, I'd need a camera of VMWare to capture them - there isn't any specific debug information for this problem anwyay. The software RAID is correctly configured and detected, without the resume statement the kernel will successfully boot the machine. The only issue is when resume is specified, it causes a kernel panic if want is pointed to by the resume argument is a software RAID. I don't believe there is any deadlock issue - many people have used this configuration for many years. According to: http://www.tldp.org/HOWTO/Software-RAID-HOWTO-2.html You may want to discourage swap on software RAID as they say the kernel can do swap striping without it anyway. If I'd known this I may well have partitioned the disks differently. Thanks again.
anyway - we should not crash during normal boot, this needs to be fixed.
I thought I replied on this one already?! can you try to boot into single user mode, setup raid manually, and try to resume system by hand? It should complain that swap has no suspend signature, but not panic.
Aha, now I see... see the other bug, there's better descirption there. *** This bug has been marked as a duplicate of 121829 ***