Bug 248926 - fedora unable to boot after moving to another machine
Summary: fedora unable to boot after moving to another machine
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-19 17:10 UTC by cornel panceac
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-07-19 20:27:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description cornel panceac 2007-07-19 17:10:01 UTC
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 .

Comment 1 Jarod Wilson 2007-07-19 20:27:45 UTC
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.

Comment 2 cornel panceac 2007-07-20 14:17:16 UTC
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 ...

Comment 3 Jarod Wilson 2007-07-20 16:28:26 UTC
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.

Comment 4 cornel panceac 2007-07-20 18:39:58 UTC
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)

Comment 5 cornel panceac 2007-07-20 18:40:51 UTC
eh i meant 'grub entry' ...

Comment 6 Jarod Wilson 2007-07-20 21:05:49 UTC
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...


Note You need to log in before you can comment on or make changes to this bug.