[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Moving Fedora 9 Hard Disk To Another System



Paul Johnson wrote:
> On Thu, Nov 20, 2008 at 2:42 PM, Mikkel L. Ellertson
>> What I have done in the past is to boot off the install media,
>> select the rescue mode, and then chroot to where the root file
>> system is mounted. I thin build the new initrd, making sure it
>> matches the kernel I plan to boot from. In the future, installing a
>> new kernel will build the initrd, using the information from the
>> running kernel. At least it has worked correctly for the last 5
>> updates on this machine sense I moved the drive here, and rebuilt
>> the initrd for this motherboard.
>>
>> Mikkel
>>
> Unless you understand the mechanism through which the new initrd is
> built, you cannot be confident in your statement that the new kernel
> will be "using the information from the running kernel," as you put
> it.  As far as I know, that is just wrong.  The initrd is built by the
> new-kernel script, and it has no way of "talking to" the existing
> kernel and getting the correct modules.
> Instead, it is reading some configuration files under /etc, and
> apparently you are lucky to have those files set correctly, but you
> don't have any good reason to expect OP has same lucky configuration.
> 
> I'm not on a Fedora 9 system now, but I can tell you about Centos 52,
> and it matches my memory of Fedora 8.  Fedora uses a script
> 
> /sbin/new-kernel-pkg
> 
> to handle the building of the initrd.  In that file, it calls
> mkinitrd.  That file does not specify any options or modules to
> pre-load.  When I want to be absolutely sure a module is loaded, I
> have sometimes written them into that file.  But you see it just uses
> mkinitrd without options.  So you go read mkinitrd man page, and it is
> not entirely too clear about how the required modules are to be
> specified, but it does say it reads "/etc/modprobe.conf" and
> "/etc/modules.conf".   Note the preload option in mkinitrd is probably
> where you need to focus.  Look in /etc/modprobe.conf on this Centos
> system, and it has components like this:
> 
> alias scsi_hostadapter ata_piix
> 
> I am pretty sure that mkinitrd is taking note of that and using the
> modules for ata_piix to get motherboard connectivity.
> 
> In the past, when I have wanted to know FOR SURE what modules are
> needed, I make a small custom install on the machine in question.
> Don't bother about configuring it.  Then I copy the modprobe.conf file
> and the stuff in modules.conf if it exists.  Then you can go ahead and
> install your standard disk image.  THen boot off a rescue disk, use it
> to go into the new system and fix the modules so they are proper and
> rebuild initrd.  Because you have fixed modprobe.conf, then new
> kernels installs will get the right settings.
> 
> Sorry if this appears pedantic. I'm a teacher :)
> 
> PJ
> 
You may want to take a closer look at the /sbin/mkinitrd script, and
all the hardware probing it does by default. Among other things, it
makes sure you have the modules for the root file system, and the
device it is mounted on by default. (PROBE="yes" is one of the
defaults.)

About the only time I could see having problems is if your
modprobe.conf is not valid for the running system. I have not
tracked down witch has priority - the information found by probing,
or found in modprobe.conf. Not that it matters much to me - I always
clean up /etc/modprobe.conf as well as the udev persistent rules as
part of moving the drive to a new system. (Delete the persistent
rules, and run kudzu on the new system.)

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]