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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
