Philip Prindeville wrote: > I recently decided that my build server was running too slow (disk > bound) and went out and bought a 3ware 9650SE controller and disks. > > Got the array configured as a single RAID 5 logical unit (yes, I know, > RAID 5 has slow writes...) and ran fdisk on the unit to create partitions. > > I formatted the partitions... > > I mounted each of the partitions and did the following: > > # cd /old-fs-mnt-point > # find . -depth -mount -print0 | cpio --null -pdv /new-fs-mnt-point > > then I ran: > > # mkswap ... > # hal-device | less > > to get the UUID's. I edited the new /boot/grub/grub.conf and /etc/fstab > and rebooted. Oops. Didn't quite work. Needed to change the BIOS > drive assignment order so that the array was now /dev/sda. > > Rebooted. > You also have to tell Grub about the BIOS drive changes. Grub use the BIOS to access the drives. The first stage is dumb, and only know the physical location of stage 1.5, and if you change the BIOS ordering, it looks on the wrong drive. > System hung: forgot to install the boot blocks. > > Hmmm... Tried to run "install-grub /dev/sda" from the Live CD, but that > didn't work. Something about not being able to figure out the BIOS > drive number... don't understand why that's relevant, but that's a > different story... > Grub uses the BIOS to access the hard drive. So you need to know the BIOS number of the drive as Grub will see it. This may not be the same numbering as when you boot from a CD/DVD. > So I reran the installer, using a small partition that I had left for > whatever... and it wrote the boot blocks and MBR. > > Editted /boot/grub/grub.conf to change back the default to what I > wanted... and rebooted. > > Now the system hangs at: > > Red Hat nash version 6.0.52 starting > Unable to access resume device (/dev/sda3) > mount: error mounting /dev/root on /sysroot as ext3: No such file or > directory > setuproot: moving /dev failed: No such file or directory > setuproot: error mounting /proc: No such file or directory > setuproot: error mounting /sys: No such file or directory > Mount failed for selinuxfs: on /selinux: No such file or directory > switchroot: mount failed: No such file or directory > > > > This is FC9 (updated) x86_64 on a Phenom/NVidia MB. > > What have I forgotten? > You need to rebuild the initrd. > Moving filesystems used to be a lot easier (these are plain ol' ext3 > filesystems... I'm not using LVM)... and I thought the whole UUID > support was to simplify moving drives around, etc. > > Doesn't seem to be the case. (Ah, for the days when just about > everything that caused a booting system to hang was pretty much > self-evident and transparent...) > > There's a certain amount of tweaking I've done of the configuration, the > rpm's I've installed, accounts created, kernel variables that I tune... > it's kind of painful to have to do a reinstall from scratch. > > Also, I wanted to peek inside the initrd.*.img files and see if there > was anything in there choking up... but I couldn't figure out how to > mount them as loopback filesystems. > > Any revelation of these mysteries appreciated. > > -Philip > One problem with changing the root file system to a drive on a different controller is that the driver may not be in the initrd, so the kernel can not access the drive. This is inherent with building a kernel with all the driver controllers as modules. But with all the different controllers, the only other way to handle it would be to have a much larger kernel with lots of unneeded drivers build in, or have a initrd with all the drivers. Both would wast a lot of memory. One other thing you are going to run into if you use SELinux is the the new drive is going to have the wrong contexts. You are going to have to relabel the files. 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
