Hide Forgot
Description of problem: after moving my (pata) hard disk to a newer machine (ga-m55s-s3 rev 2.0 mobo), fedora was unable to boot. the errors were: unable to access resume device (label=swap-hdb3) and mount: could not find filesystem '/dev/root' and concluded with kernel panic Version-Release number of selected component (if applicable): 2.6.21-1.3228.fc7 and below, including the two most recent *xen How reproducible: move fully updated f7 pata hddrive from via chipset + amd barton , to nvidia 550 chipset + amd x2 dual core 5600+ Steps to Reproduce: 1. 2. 3. Actual results: failed to boot Expected results: boots perfectly Additional info: - the newer machine has no sata drive - i've tried to disabe sata support in bios, reinstall grub, replace labels with device names, recreate initrd in rescue mode (the new initrd failed with errors: insmod: error inserting <module>: -1 required key not available module signed with unknown public key ) -finally, ivazquez suggested that removing and reinstalling the newer kernel may fix the problem, and indeed, the reinstalled kernel booted fine as a side note, i tried to replace f7.69 (wich failed too) with a new f7 but when anaconda was about to install the rpms, exits with an error wich complains about some labels, afaik, unfortunately this error was not written to paper. same thing happened with centos 5 .
Chances are pretty good your other machine used different hard disk controller drivers, so your initrd has drivers for the old machine, but not for the new machine. You'll have to boot off of a rescue disk and manually fix things up -- figure out what the correct drivers are, make sure /etc/modprobe.conf is correct, and re-run mkinitrd, and then you should be okay.
as i've said above, running mkinitrd in rescue mode ended with errors at boot time. i wonder if it is not better for the sake of portability to include more sata/pata drivers in initrd by default ...
I didn't say to simply re-run mkinitrd, you have to also fix up some bits so the right drivers are detected/loaded. I've done this before myself. If done right, there should be no difference between re-running mkinitrd for an already-installed kernel and reinstalling the kernel. In any case, no, we're not going to include a bunch of extra unused drivers in the initrd generated at kernel install time. To do what you're asking, we'd have to include every sata, pata and scsi driver in the initrd and try loading every single one of them, which is not going to happen.
ok, i'm just wondering, if a new linux user upgrades his computer and gets into this kinda situation, what is he gonna do to have fedora working again? can we find a solution to this? like having always an non-default grub wich _has_ in it's initrd all scsi/sata/pata? maybe some documentation too ?(on fedoraproject.org)
eh i meant 'grub entry' ...
Boot off the rescue CD, chroot into /mnt/sysimage, look at loaded hard disk controller modules, fix up modprobe.conf, re-run mkinitrd. Honestly, that's really all there should be to it. Reinstalling a kernel doesn't even do *that* much (rpm -q --scripts kernel), so I'm not quite sure how that worked for you, but re-running mkinitrd didn't. The stuff about modules signed with a different key make me think you didn't run mkinitrd against the right kernel, and/or didn't run it within the chroot. Anyhow, for the ata/pata case, I believe 'lsmod | grep ata_' should show all the necessary drivers that have to go into modprobe.conf and the initrd (less certain about the scsi case). With that properly set up, mkinitrd should just Do The Right Thing. (I'm actually not even sure manually editing modprobe.conf is needed). Pretty much anyone is free to write up documentation in the fedoraproject.org wiki...