Rick Stevens wrote:
> Mikkel L. Ellertson wrote:
>> Phil Meyer wrote:
>>>
>>> after chroot to /mnt/sysimage
>>>
>>> #!/bin/sh
>>>
>>> kernel=`ls /boot/vmli* | 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
>>> #
>>>
>> I normally move the drive, and see if it boots. If it does not, then
>> I boot with the rescue disk. (Or USB key.) After that, it is about
>> the same as you do, except I do not use the --preload options. I
>> don't do it often enough that I have a script for it, and I only
>> make a new initrd for the latest kernel.
>
> I'd suggesting adding a "-f" to the mkinitrd command to force an
> overwrite of any existing initrd image. And you may also have to do
> a "grub-install" as well if the primary controllers are dissimilar.
> It's burned me before.
>
Phil deleted the old one in his script - I do it manually. But the
-f option would probably be a better way, as you suggest.
As far as doing a grub-install, I would not think a change of
primary controller would matter, because Grub uses the BIOS to
access the drive. I can see problems if the BIOS drive numbering
changed, but I am not sure just running grub-install would catch
that. If you changed the drive addressing mode to/from LBA you could
also run into problems...
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
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
