Date: April 4, 2013

Introduction

For some reason as of Fedora 18, the Fedora "team" decided to overhaul the install process, and did a comprehensively bad job of it. I was able to upgrade my fedora 17 systems to 18 using yum and avoid the installer (until now). I advise anyone who is contemplating installing Fedora 18 from scratch to wait for Fedora 19, since it seems that every aspect of their installation process is now totally screwed up.

Alan Cox was so fed up with the mess that he reportedly switched from Fedora to Ubuntu calling Fedora 18 the "worst Red Hat distro ever". I am inclined to agree, and given the Fedora track record with stupid decisions like Gnome 3, systemd, and now this; I feel tempted myself.

What I had in mind to do was to clean up some of my systems which have multiple disk drives in them, so that the whole system would run off of a single new 1 or 1.5 terrabyte drive. Sounds simple enough. The first step in this would be to get the new drive partitioned and a bootable system on it, and the way I would usually have done this would have been to do a fresh install of a minimal system.

I tried and tried to manually partition a disk and do the Fedora install using the F18 install DVD. Ultimately I gave up and let it do its default partion scheme on the 1.4 TB disk I was using. Then end result was surprisingly like what I would have set up. What I had in mind was:

What the Fedora installer did was: I was surprised that it did not use Gnu Parted and create a BIOS boot partition (which is typically 2M or so). Apparently Fedora was using Gnu Parted globally back in Fedora 16 days, but changed their policy with Fedora 17. It is only necessary to use GPT with disks larger than 2 Tb, and now apparently Fedora only uses GPT when necessary, which suits me fine. So we have MBR style disks and GPT style disks.

Beat it with a big stick

Since the Fedora install DVD is no help, we have to roll up our sleeves and use all of the tricks we have learned over the years. We aren't going to put up with a buggy braindead installer forcing us into a partitioning scheme we don't like. Look on the bright side: at least it didn't create a bunch of LVM drives or something really awful.

I swap cables around on my system, use my new BIOS to specify that I boot from my old hard disk with a working Fedora 18 system, and the disk I just did the funky install on is /dev/sdc. When the smoke clears this will become /dev/sda and all the other disks will get removed from the system. I use fdisk to get rid of sdc3, sdc4, and sdc5, then I recreate them in the sizes I want (all this to reduce the size of my root partition from 52 to 20G). Even though it seems pointless, I keep the sdc4 extended partition. I also decide that a 512G /boot partition will be fine.
Then I run: 

mkfs -t ext4 /dev/sdc3
mkfs -t ext4 /dev/sdc5
I copy my current /boot on top of the new /boot fedora created (we will see how that works out). Then to copy my root partition, some special tricks are required to copy special files and other weird things that aren't really files: 
su
mkdir /x
mount /dev/sdc3 /x
cd /
find ./ -xdev -print0 | cpio -pa0V /x
Interestingly, cpio has a "pass through" mode to do what I have always done with tar piped to tar. The -xdev switch on find tells it not to wander out of the filesystem it starts in into other mounted filesystems. Away it goes printing lots of dots to let us know it is actually doing something. (If you don't want the dots, leave the "V" out of the cpio options.)

Note that the -print0 option on find and the -0 switch on cpio work together to allow null terminated filenames.
I got this, and a number of other tips from this blog:

He suggests running "watch df" in a separate terminal, which is a nice trick.

fstab

Once this is all done, there are some things that need to be tweaked. First is the fstab file. My file specifies devices to mount via UUID, which will break now that I have moved /boot and / to a new device. The easy fix is to use names like /dev/sda1 and /dev/sda3 and be done with it. But if I do want to continue to use UUID's, I can dig them out of 
ls -l /dev/disk/by-uuid/
I may do this later once the system is up and running on the new disk.

grub

Back in the old days we would edit the UUID stuff in /boot/grub/grub.conf and then do something like: 
chroot /mnt/sdb1 /usr/sbin/grub-install --recheck /dev/sdb
But we are now dealing with grub2, which is a different fish. We do need to straighten out some UUID values, but the game now is to edit the file /etc/default/grub and then do something like: 
mount /dev/sdc3 /xroot
mount /dev/sdc1 /xroot/boot
chroot /xboot grub2-mkconfig -o /boot/grub2/grub.cfg
This sounds clever, but gives me the error: 
/usr/sbin/grub2-probe: error: cannot find a device for / (is /dev mounted?)
So, I do the unthinkable and edit the UUID values in /boot/grub2/grub.cfg. Being lazy, I only edit the entries for the one kernel line I expect to be used to boot. Amazingly it works and I can now boot this disk.

I should do: 

grub2-mkconfig -o /boot/grub2/grub.cfg
As soon as I am up and running with all the disk partitions mounted as they should be in the final configuration.

Note - a second time through doing this (on a different system), I did this to install grub: 

mount /dev/sdb2 /x
mount /dev/sdb1 /x/boot
grub2-install --root-directory=/x /dev/sdb
The following article has a lot of interesting and useful information about grub2:

Move my u1 partition

On my system, this is the moral equivalent of a /home partition. I copied it via the venerable tar pipe scheme, which took a long time (it is 500G or so after all). I cleaned up loose ends afterwards by running an rsync: 
cd /u1
tar cf - . | (cd /new_u1 ; tar xf - )
rsync -var /u1/ /new_u1
I don't know if the cpio passthrough would have been any faster or better. For all I know running two tar processes with pipes on a multi core cpu could allow some scheduling and optimization, but fundamentally this is IO limited and a lot of data simply has to get moved around.

Move my entire home system onto a new disk

My home system is happily running F18 on a 500G sata drive. I just bought a nice new fast 1T sata drive, and would like to move the system onto it for two reasons. One is to get rid of an 80G windows dual boot partition that I thought I might have used to run photoshop (I just got another computer for that, dual boot is the worst of all worlds). Also the new drive is a 6G/s sata-3 drive. So away we go. Here is how I do it, avoiding having anything to do with the Fedora 18 install disk: The hand editing of grub.cfg is somewhat of a pain because you have to copy and paste UUID's that you get by inspecting /dev/disk/by-uuid. I only change 3 entries. I find the boot entry for the current kernel, and ignore all the others. I also don't need to change the UUID in the label line. I do need to change the UUID for the /boot partition in two places, and the root in one. All this gets redone and overwritten once I am up on the new drive via: 
grub2-mkconfig -o /boot/grub2/grub.cfg
So there is no point in doing anything more than absolutely necessary.
Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org