Moving F7

[Lamar Owen]

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