RE: Moving Fedora 9 Hard Disk To Another System
>When the kernel is updated, the Fedora 9 framework will rebuild a new >initrd and it will NOT have the special modules in it. On the CentOS list, a similar discussion revealed a procedure to facilitate this: http://lists.centos.org/pipermail/centos/2008-November/067688.html jlc -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
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! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
Paul Johnson wrote:
On Thu, Nov 20, 2008 at 2:42 PM, Mikkel L. Ellertson
<[EMAIL PROTECTED]> wrote:
Paul Johnson wrote:
When the kernel is updated, the Fedora 9 framework will rebuild a new
initrd and it will NOT have the special modules in it. On fedora
systems, I found no simpler solution than to edit the new-kernel
script and change the modules that were assumed. Otherwise, the boot
up will fail just like you have been seeing. On Ubuntu linux, I've
learned that the required modules can be configured in
/etc/modprobe.conf or someplace similar, and the initrd builder takes
notice of it.
...
Sorry if this appears pedantic. I'm a teacher :)
Well, my solution is even more so ...
I got tired of fighting it. My requirements are to build a bootable
disk in a VM and have it run on any i686 based platform. Exceptions are
SAN based ...
In my post install I do this:
# make sure drivers are in the initrd image
kernel=`ls /boot/vmli* | tail -1 | awk -F\- '{printf("%s-%s\n", $2,$3)}'`
initrd="/boot/initrd-${kernel}.img"
rm $initrd
/sbin/mkinitrd --preload=ehci-hcd --preload=ahci --preload=libata
--preload=jbd --preload=ohci-hcd --preload=uhci-hcd
--preload=scsi_wait_scan --preload=usb-storage --preload=scsi_mod
--preload=sd_mod --preload=pata_amd --preload=ata_generic
--preload=pata_cs5536 --preload=pata_acpi $initrd $kernel
THAT will boot. :)
Good Luck!
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
On Thu, Nov 20, 2008 at 2:42 PM, Mikkel L. Ellertson <[EMAIL PROTECTED]> wrote: > Paul Johnson wrote: >> >> When the kernel is updated, the Fedora 9 framework will rebuild a new >> initrd and it will NOT have the special modules in it. On fedora >> systems, I found no simpler solution than to edit the new-kernel >> script and change the modules that were assumed. Otherwise, the boot >> up will fail just like you have been seeing. On Ubuntu linux, I've >> learned that the required modules can be configured in >> /etc/modprobe.conf or someplace similar, and the initrd builder takes >> notice of it. >> > 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 -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
Paul Johnson wrote: > > When the kernel is updated, the Fedora 9 framework will rebuild a new > initrd and it will NOT have the special modules in it. On fedora > systems, I found no simpler solution than to edit the new-kernel > script and change the modules that were assumed. Otherwise, the boot > up will fail just like you have been seeing. On Ubuntu linux, I've > learned that the required modules can be configured in > /etc/modprobe.conf or someplace similar, and the initrd builder takes > notice of it. > 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 -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
On Wed, Nov 19, 2008 at 7:23 PM, Manish Kathuria <[EMAIL PROTECTED]> wrote: > For a large installation of Fedora 9 we are cloning an updated system > on identical hard disks and then using that hard disk on other > systems. Most of the systems are either Pentium 4 or Core Duo > processor based and are capable of running the same kernel (i686) The > minor problems being faced include difference in network card drivers > requiring reconfiguration . However in certain cases, though we are > able to successfully boot Fedora 9 on a system using a cloned hard > disk but if the same hard disk is moved to another system having a > different motherboard, the system boot process comes to a halt after a > few steps as it is not able to locate the file systems on the hard > disk. The GRUB screen is displayed indicating that the MBR is being > read properly. Can there be a likelihood of the disk geometry being > interpreted in different manner leading to non recognition of > filesystems ? I would appreciate any tips or suggestions. > I have done this and seen this same problem. The previous poster's suggestion about the modules is probably right. If you google for "installing Fedora 5 on an external usb hard disk", you will probably learn about this the same way I did. The install on a PC selects some hardware devices and compiles the into the initrd file, and if you take the disk to another system (assuming you do not use UUID in the grub.conf file) , then it will often work, but not always. The hard part is to figure which module is missing. So, with the CURRENT KERNEL on the working disk, you can put the modules for usb and scsi in the initrd like so: mkinitrd --with-usb --preload=ehci-hcd --preload=usb-storage --preload=scsi_mod --preload=sd_mod ./usbinitrd-`uname -r` `uname -r` Then you reconfigure grub.conf to use that initrd. Here's the bad news for you. When the kernel is updated, the Fedora 9 framework will rebuild a new initrd and it will NOT have the special modules in it. On fedora systems, I found no simpler solution than to edit the new-kernel script and change the modules that were assumed. Otherwise, the boot up will fail just like you have been seeing. On Ubuntu linux, I've learned that the required modules can be configured in /etc/modprobe.conf or someplace similar, and the initrd builder takes notice of it. > Thanks, > -- > Manish Kathuria > > -- > fedora-list mailing list > fedora-list@redhat.com > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines > -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
Michael Cronenworth wrote: > Original Message > Subject: Re: Moving Fedora 9 Hard Disk To Another System > From: Mikkel L. Ellertson <[EMAIL PROTECTED]> > To: Community assistance, encouragement, and advice for using Fedora. > > Date: 11/19/2008 08:08 PM > >> What is more likely is that the motherboard is using a different >> hard drive controller. The new controller requires a different >> module from the original one. So you have to build a new initrd for >> that system. This was covered in detail on the list a while back. >> >> Depending on the other hardware, you may have to run kudzu, or you >> may have to delete some or all of the >> /etc/udev/rules.d/??-persistent*.rules files. >> >> Mikkel >> > > > He won't need to build a new initrd. The UUID specified in his grub.conf > is wrong. Correct me if I'm wrong, but the UUID is specific to a hard > drive, so even if he cloned the image, the UUID would be for the > original hard drive and wouldn't work on the cloned image. > > Try setting root to "root=LABEL=/" or "root=/dev/sda2" or generate a new > UUID. > I would agree with you, except that the cloned drives worked on some machines, and not others. It depended on the hardware. If it did not work on any of the machines, that would support a UUID problem. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
On Thu, Nov 20, 2008 at 10:30:26AM -0600, Michael Cronenworth wrote: > Original Message > Subject: Re: Moving Fedora 9 Hard Disk To Another System > From: Mikkel L. Ellertson <[EMAIL PROTECTED]> > To: Community assistance, encouragement, and advice for using Fedora. > > Date: 11/19/2008 08:08 PM > >> What is more likely is that the motherboard is using a different >> hard drive controller. The new controller requires a different >> module from the original one. So you have to build a new initrd for >> that system. This was covered in detail on the list a while back. >> >> Depending on the other hardware, you may have to run kudzu, or you >> may have to delete some or all of the >> /etc/udev/rules.d/??-persistent*.rules files. >> >> Mikkel >> > > > He won't need to build a new initrd. The UUID specified in his grub.conf > is wrong. Correct me if I'm wrong, but the UUID is specific to a hard > drive, so even if he cloned the image, the UUID would be for the > original hard drive and wouldn't work on the cloned image. > > Try setting root to "root=LABEL=/" or "root=/dev/sda2" or generate a new > UUID. The UUID is part of the file system superblock, not tied to the physical hard disk, IIRC. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug pgpqCWKMz8uIv.pgp Description: PGP signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
Original Message Subject: Re: Moving Fedora 9 Hard Disk To Another System From: Mikkel L. Ellertson <[EMAIL PROTECTED]> To: Community assistance, encouragement, and advice for using Fedora. Date: 11/19/2008 08:08 PM What is more likely is that the motherboard is using a different hard drive controller. The new controller requires a different module from the original one. So you have to build a new initrd for that system. This was covered in detail on the list a while back. Depending on the other hardware, you may have to run kudzu, or you may have to delete some or all of the /etc/udev/rules.d/??-persistent*.rules files. Mikkel He won't need to build a new initrd. The UUID specified in his grub.conf is wrong. Correct me if I'm wrong, but the UUID is specific to a hard drive, so even if he cloned the image, the UUID would be for the original hard drive and wouldn't work on the cloned image. Try setting root to "root=LABEL=/" or "root=/dev/sda2" or generate a new UUID. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
Aldo Foot wrote: > On Wed, Nov 19, 2008 at 6:08 PM, Mikkel L. Ellertson > <[EMAIL PROTECTED]> wrote: >> What is more likely is that the motherboard is using a different >> hard drive controller. The new controller requires a different >> module from the original one. So you have to build a new initrd for >> that system. This was covered in detail on the list a while back. > > Do you have a date reference? I'd like to take a look at the thread. > > thanks > ~af > About mid October - Two threads come to mind: Trying to reconfigure F9 to new computer hardware... firstboot? fedora 9 and swapping motherboards Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
On Wed, Nov 19, 2008 at 6:08 PM, Mikkel L. Ellertson <[EMAIL PROTECTED]> wrote: > What is more likely is that the motherboard is using a different > hard drive controller. The new controller requires a different > module from the original one. So you have to build a new initrd for > that system. This was covered in detail on the list a while back. Do you have a date reference? I'd like to take a look at the thread. thanks ~af -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
On Wed, Nov 19, 2008 at 6:08 PM, Mikkel L. Ellertson <[EMAIL PROTECTED]> wrote: > What is more likely is that the motherboard is using a different > hard drive controller. The new controller requires a different > module from the original one. So you have to build a new initrd for > that system. This was covered in detail on the list a while back. Do you have a date reference? I'd like to take a look at the thread. thanks ~af -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Moving Fedora 9 Hard Disk To Another System
Manish Kathuria wrote: > For a large installation of Fedora 9 we are cloning an updated system > on identical hard disks and then using that hard disk on other > systems. Most of the systems are either Pentium 4 or Core Duo > processor based and are capable of running the same kernel (i686) The > minor problems being faced include difference in network card drivers > requiring reconfiguration . However in certain cases, though we are > able to successfully boot Fedora 9 on a system using a cloned hard > disk but if the same hard disk is moved to another system having a > different motherboard, the system boot process comes to a halt after a > few steps as it is not able to locate the file systems on the hard > disk. The GRUB screen is displayed indicating that the MBR is being > read properly. Can there be a likelihood of the disk geometry being > interpreted in different manner leading to non recognition of > filesystems ? I would appreciate any tips or suggestions. > What is more likely is that the motherboard is using a different hard drive controller. The new controller requires a different module from the original one. So you have to build a new initrd for that system. This was covered in detail on the list a while back. Depending on the other hardware, you may have to run kudzu, or you may have to delete some or all of the /etc/udev/rules.d/??-persistent*.rules files. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup! signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
