Re: Moving Fedora 9 Hard Disk To Another System

2008-11-20 Thread Mikkel L. Ellertson
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

2008-11-20 Thread Michael Cronenworth

 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. 
fedora-list@redhat.com

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

2008-11-20 Thread Paul W. Frields
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.  
 fedora-list@redhat.com
 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

2008-11-20 Thread Mikkel L. Ellertson
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.
 fedora-list@redhat.com
 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

2008-11-20 Thread Mikkel L. Ellertson
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

2008-11-20 Thread Paul Johnson
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

2008-11-20 Thread Phil Meyer

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

2008-11-20 Thread Mikkel L. Ellertson
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

2008-11-20 Thread Joseph L. Casale
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

2008-11-19 Thread Mikkel L. Ellertson
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