1 To install FC16 onto an external drive (say, your new SSD in a USB enclosure) you must select the radio button for "specialist storage devices". (The "basic drives" button won't see your USB drives.) The installation can then be carried out as for an internal drive.
2 Fedora likes to choose a default Volume Group name; and this will be the same for a new Volume Group on an external drive as for the one on your existing internal drive. This isn't the end of the world; we can change it later.
This relates to FC14 but will probably apply to other versions.
1 The GUI Disk Utility (/usr/bin/palimpsest) should list "Multi-disk Devices" in the list of Storage Devices. If it doesn't, or if it isn't showing all the Volume Groups you have available (perhaps because you jave just plugged in your USB drive) run udevadm trigger (as root). Then open palimpsest again. You should now see the Volume Groups listed under Multi-disk Devices.
2 Palimpsest should now allow you to change the Volume Group name.
3 However, if it has already picked up on the details of the Volume Group in your (new) external drive, it will probably refuse to execute. In my case it came up with:
Error setting name for Volume GroupAn error occurred: The operation failed
Error setting name for LVM2 Volume Group: vgrename exited with exit code 5: Couldn't find device with uuid Rve8hi-lxaz-0ZDY-rA31-4MMB-KVdi-gko3px. Cannot change VG vg_serpentine while PVs are missing. Consider vgreduce --removemissing.
4 This is easy to fix from the command line:
[plega@serpentine lvm]$ sudo lvm lvscan Couldn't find device with uuid Rve8hi-lxaz-0ZDY-rA31-4MMB-KVdi-gko3px. ACTIVE '/dev/vg_serpentine/lv_root' [24.31 GiB] inherit ACTIVE '/dev/vg_serpentine/lv_swap' [5.62 GiB] inherit inactive '/dev/vg_serpentine/swap240' [5.59 GiB] inherit inactive '/dev/vg_serpentine/fedora16' [28.31 GiB] inherit inactive '/dev/vg_serpentine/data240' [144.78 GiB] inherit [plega@serpentine lvm]$ sudo lvm vgreduce --removemissing vg_serpentine Couldn't find device with uuid Rve8hi-lxaz-0ZDY-rA31-4MMB-KVdi-gko3px. WARNING: Partial LV swap240 needs to be repaired or removed. WARNING: Partial LV fedora16 needs to be repaired or removed. WARNING: Partial LV data240 needs to be repaired or removed. WARNING: There are still partial LVs in VG vg_serpentine. To remove them unconditionally use: vgreduce --removemissing --force. Proceeding to remove empty missing PVs. [plega@serpentine lvm]$ sudo lvm vgreduce --removemissing --force vg_serpentine Couldn't find device with uuid Rve8hi-lxaz-0ZDY-rA31-4MMB-KVdi-gko3px. swap240 is expected to have only one segment using it, while it has 0 Failed to find mirror_seg for swap240 fedora16 is expected to have only one segment using it, while it has 0 Failed to find mirror_seg for fedora16 data240 is expected to have only one segment using it, while it has 0 Failed to find mirror_seg for data240 Wrote out consistent volume group vg_serpentine [plega@serpentine lvm]$ sudo lvm lvscan ACTIVE '/dev/vg_serpentine/lv_root' [24.31 GiB] inherit ACTIVE '/dev/vg_serpentine/lv_swap' [5.62 GiB] inherit
5 The GUI Disk Utility (/usr/bin/palimpsest) should now allow you to rename the Volume Group without error. Confirm the results using lvm again:
[plega@serpentine lvm]$ sudo lvm lvscan ACTIVE '/dev/vg_serpentine_old/lv_root' [24.31 GiB] inherit ACTIVE '/dev/vg_serpentine_old/lv_swap' [5.62 GiB] inherit
Full details of what you have done should be stored in /etc/lvm/archive.
6 However, there are several things that could go wrong with this. /etc/fstab is now incorrect, although it is meant to update next time you boot, from the (correct) information in /dev/disk. I didn't care to risk this, so I edited it by hand, anyway. It has been suggested that you will need to update grub.conf to point to the new location of your root partition, but that referred to RHEL 5.5 and does not seem to be necessary in FC14, where grub.conf uses UUIDs to identify the root location.
I would like to think that this is of historical interest only, but I'm not convinced, so I'm making a note of it here. For previous distros (FC14 and prior) you could only get direct rendering to work if you used the nvidia drivers, as I recollect it. If, like me, you installed kmod-nvidia with FC16, you're not going to be able to get EFI boot to work. You're stuck with BIOS boot, which takes longer and breaks reboot/suspend. However, the FC16 nouveau drivers support EFI as well as direct rendering, so I now have the MacBookAir3,1 running with suspend, sleep etc. just like real Jobs-ware, which is stunning. For reference, here are the relevant partition setup (parted) and kernel commands (/boot/grub2-efi/grub.cfg):
Model: ATA OWC Mercury Aura (scsi) Disk /dev/sda: 240GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI System Partition boot 2 210MB 16.2GB 16.0GB hfs+ Mac OS/X 3 16.2GB 16.2GB 1049kB bios_grub 4 16.2GB 16.7GB 524MB ext4 ext4 boot 5 16.7GB 240GB 223GB lvm
menuentry 'Fedora Linux, with Linux 3.3.5-2.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd0,gpt4)'
search --no-floppy --fs-uuid --set=root a8cf3860-f374-4bc4-9337-cf3058ef015d
echo 'Loading Linux 3.3.5-2.fc16.x86_64 ...'
linux /vmlinuz-3.3.5-2.fc16.x86_64 root=/dev/mapper/vg_serpentine-lv_root ro rd.lvm.lv=vg_serpentine/lv_root rd.md=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 KEYTABLE=us-acentos rd.lvm.lv=vg_serpentine/lv_swap LANG=en_US.UTF-8 selinux=0
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.3.5-2.fc16.x86_64.img
}