I'm back now, with an updated system. In order to copy a system to a new disk and Volume Group, one needs, along with a fresh install of Grub, a new initrd with info from the new updated /etc/fstab. It's not necessarily an LVM issue. On 09-07-27 14:14:45, Mikkel L. Ellertson wrote: > Tony Nelson wrote: > > On 09-07-27 10:08:50, Mikkel L. Ellertson wrote: > >> What do you mean by boot from each drive? Are you talking about > >> selecting what drive to boot from in the BIOS, or selecting what > >> drive is / by setting the root=<something> in /boot/grub.conf? > > > > Either way (with suitable changes to grub.conf). > > > It gets a bit complicated because Grub uses the BIOS to access the > drives. To use the BIOS to select the drive to boot from, you need a > grub first stage on the MBR of both drives. But the first stage on > the second drive has to point to /boot on the first drive. The > things is, when you change the boot drive in the BIOS, the boot > drive becomes (hd0) and the original drive becomes (hd1). This can > be made to work, but you need to mount /boot from the first > installation in the second installation. It works much better to > have a /boot partition on the second drive. Please keep in mind that > the /boot partition can not be in an LVM. All this was fine, as booting had started (kernel loaded, initrd loaded). > >> Second question - do the two VGs have different names? > > > > Yes. > > > > Even when the boot drive is set in the BIOS to be the drive > > containing the Volume Group to use, VolGroup01, all Volume Groups > > are recognized, and then VolGroup00's volumes are activated. I see > > that nash has started. In the initrd, the nash script "init" > > contains the offending settings. I suppose I need to use mkinitrd > > to fix this, so that VolGroup01 (and also VolGroup00 which contains > > the swap partition) is activated. Doing `mkinitrd -f /boot/initrd-<kernel version> <kernel version>` fixed the problem. Note that mkinitrd trusts /etc/inittab, so that had better be right. > It would help to see /boot/grub/grub.conf - I suspect that is part > of the problem. If you run the Gnome desktop, you can run System --> > Administration --> Logical Volume Management for an easy way to > manage LVMs. None of that had anything to do with the problem. As I mentioned previously, nash had started (so Grub was well out of the picture) and then not all needed Logical Volumes were activated. I'd heard of nash, but had never known quite where it was in the boot process. I'd never looked into the initrd either. Thank you for your efforts. -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' <http://www.georgeanelson.com/> -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
