Moving F7
Lamar Owen
lowen at pari.edu
Fri Sep 28 15:26:36 UTC 2007
On Thursday 27 September 2007, Karl Larsen wrote:
> Mikkel L. Ellertson wrote:
> > No, the initrd is generated as part of the kernel install scripts.
> Well then if you copy your f7 to another hard drive and load a new
> kernel rpm your system should boot without a kernel panic. Is this correct?
Not necessarily. It depends upon whether the grub (or lilo) configuration
needs changing, too. Booting is a multistage process, and moving from one
drive to another touches all the stages of booting.
Hey, Karl, let me ask you a Ham question. If I have a 40 meter QRP rig that
is working with a 1:1.05 VSWR into a Butternut 40 meter antenna, can I use it
with a Communications Specialties whip and expect the same performance?
(For those who are not hams, that question is intentionally missing some
critical data, and it really is on-topic, as I'm using it as an analogy)
Karl, the point I'm making is, as you well know from your extensive QRP
experience, is that the answer to my intentionally poorly worded question
is 'it depends: what QRP rig do you have, which tuner are you using, what
model Butternut, and what model Communications Specialties whip, cut for what
band?' This same thing is true for any Linux; there are details that matter
that on the surface don't appear to matter, but can bite you if you don't pay
attention to them.
Think of the kernel modules in the initrd as being the 'tuner' that matches
the Linux QRP rig to the PC hardware's antenna. Change antenna, you might
(probably will!) have to change tuner, right? Now at QRP you're not likely
to damage anything if you run into a poor match (your efficiency and signal
will stink, of course); run full 1.5K PEP and things change, of course; same
with booting and kernel panics; there are certain hardware moves that will
not panic the kernel; there are others, however, that can prevent booting,
for any number of reasons (most common is that the kernel can't find the root
filesystem because it doesn't have the driver module for that hardware (grub
gets the kernel and initial ramdisk loaded by using the BIOS, which has its
own driver, and that's a whole different issue, something like that your
Butternut has a PL-259 pigtail but the CommSpec has a TNC and just won't plug
into your rig with the SO-239 without an adapter 'module')).
In order to determine which module (tuner) you need, you need to know what PC
hardware exactly (antenna) you have and how it differs.
While the BIOS is calling your SATA drive an IDE drive (which it is,
technically) the Linux kernel may not see things that way, depending upon
which kernel module is needed for that particular chip you have. Kindof like
how a QRP rig with an autotuner sees antennas differently than a rig without
one; the BIOS is pre-tuned to your hardware, Linux is not.
An Intel ICH6R will need a different module than a SiI 3124, for instance. If
the initrd was built for booting, that is, for a root filesystem located on,
an ICH-driven PATA IDE drive, and now you want to boot on a SiI 3124-driven
SATA IDE drive, you now need to make sure the SiI 3124 module is loaded in
the initrd in order for this to work (this particular combination is found on
several motherboards, but your hardware will likely be different). Or if you
move a SATA boot drive from a, for instance, VIA KT600 motherboard to an
nVidia nForce-4 Ultra motherboard (upgraded from an Athlon XP to an Athlon 64
X2, perhaps) then you will most definitely need different modules (in the
PATA case, most PATA controllers are compatible with each other and will
work, but even this isn't always true).
How do you find which hardware you need? Just like in antenna work, there are
tools to determine these things. For antenna work, several tools are
available; SWR bridges, simple impedance meters (like the MFJ unit), and
complex network analyzers (Agilent stuff, for instance). Same is true for
Linux; several tools will give you the information you need to determine
which modules are needed: there is the simple 'lspci' command, the slightly
more complex 'lspci -v' command, and the significantly more
detailed 'dmidecode' command.
And just like getting a good match from your rig to the chosen antenna can be
a challenge, finding the information in the places it is hidden in the Linux
boot process can be a challenge; just like an impedance of 19+j72 requires a
vastly different tuner than an impedance of 19-j72 would (looks like an
insignificant detail to those who ignore reactance), the exact details of
your particular system matter, and a seemingly insignificant detail can have
broad repercussions as to the bootability of your system.
And, again, just like in antenna work, you need to consult some references to
determine what you need. For an antenna and a tuner to match, you need the
manufacturer's impedance curves (unless you have the equipment to derive them
yourself, or use something like NEC2 to model the curves); for the module
case you need to research which particular module matches your hardware (for
a SiI 3124, for instance, you need, for the current kernel on my laptop
here, /lib/modules/2.6.22.5-76.fc7/kernel/drivers/ata/sata_sil24.ko to get
loaded; a SiI 3112 needs sata_sil.ko instead; an nVidia needs one of several
modules, depending upon exact chipset AND how the BIOS setup has set up the
SATA controller (some, in 'RAID mode' gives you the better AHCI mode rather
than the nVidia IDE mode, but it depends on the exact chipset and setup), and
other chipsets need the particular module designed for that chipset.
Fresh and repair installations detect this for you through the anaconda
installer; if you are just moving the data to another drive and system you
have to do by hand what anaconda does for you automatically at install time.
And that brings up a possible anaconda rescue mode enhancement; a 'redetect'
sort of thing, like the X server already does for the video card if you
change cards (I just did this; changed from an Athlon 64 on an nVidia
nForce-3 250 motherboard with an nVidia GeForce AGP card to an Athlon 64 X2
on an nVidia nForce-4 Ultra with an ATI FireGL PCI-e video card; the system
booted, the screen flashed a few times, a text dialog came up, and the system
reconfigured itself for the new video card, all automatically, and it all
works), but for the root filesystem. This isn't an uncommon thing to want to
do for a 'hobbyist', and no distribution currently makes it easy.
Having the live system do this would mean more stuff would need to be in the
initrd, and that might be a problem. The root filesystem device drive module
is needed at a much lower level than the X server video card driver is, so it
would be harder to do properly. That's why I mention it as a rescue mode
option; boot from CD with a 'repair' mode that can go in and rebuilt the
initrd for you and do all those things anaconda does for you on initial
install.
As it stands now, using the rescue mode from the boot CD is a lot like using
the Windows Recovery Console, and just as arcane. I'm comfortable in both
these environments; but only after a lot of trial and error and experience in
doing it. Hmmph, doing this in Windows is just as hard for some things; I
tried once moving a Windows XP hard drive (Ultra320 SCSI) from an Adaptec
controller to an LSI Logic controller; no can do (even moving from an Adaptec
29160 to an Adaptec 39160 blue-screened WinXP on one box).
I did the same move with the CentOS 4 Linux distribution, and was able to make
it happen. Now, it was NOT easy, and it took a lot more work and time (most
of the time spent on researching mkinitrd and running it several times before
the right modules got loaded) than it should have, but I was able to rebuild
the initrd with the right modules and bring the system back up on the other
controller.
Now, specifics: If I move a root filesystem from one drive to another, and
the source drive was on a PATA IDE channel, and the destination is on a SATA
IDE channel driven by a SiI 3124 chip, I need to boot the CD, go into rescue
mode, have it mount the filesystems, chroot to /mnt/sysimage, find out what
initrd and kernel is already there (I'm going to use the 2.6.22.5-76.fc7 for
the specific example here), find out the module dependencies using lsmod (my
experience with the Adaptec to LSI Logic move I mentioned above is that all
the module dependencies have to specified on the mkinitrd command line), back
up the existing initrd (this is located in /boot, and is named for the
example kernel below 'initrd-2.6.22.5-76.fc7.img'), and issue the appropriate
mkinitrd command. Editing /etc/modprobe.conf at this point isn't necessary,
but is useful, and might even eliminate some of the --with's I use below; I
found that kudzu on the next boot handled /etc/modprobe.conf for me.
Unless I've missed something, the command that should work for this specific
example would be (all on one line):
mkinitrd --with=libata --with=sata_sil24 --with=scsi_mod --with=sd_mod
initrd-2.6.22.5-76.fc7.img 2.6.22.5-76.fc7
This gets your initrd. Now, you DO need to see how grub sees the new disk;
please see the GRUB HOWTO for these details (the best practical information I
have found on running grub to find things and change things is actually the
Software RAID and grub HOWTO; I found a copy at
http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/008898.html that
has helped me greatly in my understanding of grub).
Also note that, on the system I successfully moved from an Adaptec to an LSI
Logic controller, trying the 'reinstall kernel RPM to get the initrd built'
did not work, but that was CentOS 4 and not F7, so things in the kernel %pre
and %post scriptlets may have changed to handle this better; I don't know.
In any case, hope this helps.
--
Lamar Owen (aka KF4MYT)
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
More information about the fedora-list
mailing list