Red Hat Bugzilla – Bug 248926
fedora unable to boot after moving to another machine
Last modified: 2007-11-30 17:12:10 EST
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)
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
move fully updated f7 pata hddrive from
via chipset + amd barton , to
nvidia 550 chipset + amd x2 dual core 5600+
Steps to Reproduce:
failed to boot
- 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
Pretty much anyone is free to write up documentation in the fedoraproject.org