Wandering Thoughts archives

Some notes on moving a software RAID-1 root filesystem around (to SSDs)

A while ago I got some SSDs for my kind of old home machine but didn't put them to immediate use for various reasons. Spurred on first by the feeling that I should get around to it sometime, before my delay got too embarrassing, and then by one of my system drives apparently going into slow IO mode for a while, I've now switched my root filesystem over to my new SSDs. I've done this process before, but this time around I want to write down notes for my future reference rather than having to re-derive all the steps each time. All of this is primarily for Fedora, currently Fedora 25; some steps will differ on other distributions such as Ubuntu.

I partitioned using GPT partitions, not particularly because I needed to with 750 GB SSDs but because it seemed like a good idea. I broadly copied the partitioning I have on my SSDs at work for no particularly strong reason, which means that I set it up this way:

Number	Size	Code	Name
1	256 MB	EF00	EFI System
2	1 MB	EF02	BIOS boot partition
3	100 GB	FD00	Linux RAID
4	1 GB	FD00	Linux RAID (swap)
5	<rest>	BF01	ZFS

Some of this is likely superstition by now, such as the BIOS boot partition.

With the pair of SSDs partitioned, I set up the software RAID-1 arrays for the new / and swap. Following my guide to RAID superblock formats I used version 1.0 format for the / array, since I'm going to end up with /boot on it. Having created them as /dev/md10 and /dev/md11 it was time to put them in /etc/mdadm.conf. The most convenient way is to use 'mdadm --examine --scan' and then copy the relevant output into mdadm.conf by hand. Once you have updated mdadm.conf, you also need to update the initramfs version of it by rebuilding the initramfs. Although you can do this for all kernel versions, I prefer to do it only for the latest one so that I have a fallback path if something explodes. So:

dracut --kver $(uname -r) --force

(This complained about a broken pipe for cat but everything seems to have worked.)

When I created the new RAID arrays, I took advantage of an mdadm feature to give them a name with -N; in particular I named them 'ssd root' and 'ssd swap'. It turns out that mdadm --examine --scan tries to use this name as the /dev/ name of the array and the initramfs doesn't like this, so on boot my new arrays became md126 and md127, instead of the names I wanted. To fix that I edited mdadm.conf to give them the proper names, and while I was there I added all of the fields that my other (much older) entries had:

ARRAY /dev/md10  metadata=1.0 level=raid1 num-devices=2 UUID=35d6ec50:bd4d1f53:7401540f:6f971527
ARRAY /dev/md11  metadata=1.2 level=raid1 num-devices=2 UUID=bdb83b04:bbdb4b1b:3c137215:14fb6d4e

(Note that specifying the number of devices may have dangerous consequences if you don't immediately rebuild your initramfs. It's quite possible that Fedora 25 would have been happy without it, but I don't feel like testing. There are only a finite number of times I'm interested in rebooting my home machine.)

After copying my root filesystem from its old home on SATA HDs to the new SSD filesystem, there were a number of changes I need to make to actually use it (and the SSD-based swap area). First, we modify /etc/fstab to use the UUIDs of the new filesystem and swap area for / and, well, swap. The easiest way to get these UUIDs is to use blkid, as in 'blkid /dev/md10' and 'blkid /dev/md11'.

(For now I'm mounting the old HD-based root filesystem on /oldroot, but in the long run I'm going to be taking out those HDs entirely.)

But we're not done, because we need to make some GRUB2 changes in order to actually boot up with the new root filesystem. A normal kernel boot line in grub.cfg looks like this:

linux   /vmlinuz-4.9.9-200.fc25.x86_64 root=UUID=5c0fd462-a9d7-4085-85a5-643555299886 ro acpi_enforce_resources=lax audit=0 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd.md.uuid=d0ceb4ac:31ebeb12:975f015f:1f9b1c91 rd.md.uuid=c1d99f17:89552eec:ab090382:401d4214 rd.md.uuid=4e1c2ce1:92d5fa1d:6ab0b0e3:37a115b5 rootflags=rw,relatime,data=ordered rootfstype=ext4

This specifies two important things, the UUID of the root filesystem in 'root=...' and the (software RAID) UUIDs of the software RAID arrays that the initramfs should assemble in early boot in the 'rd.md.uid=...' bits (per the dracut.cmdline manpage, and also). We need to change the root filesystem UUID to the one we've already put into /etc/fstab and then add rd.md.uuid= settings for our new arrays. Fortunately mdadm has already reported these UUIDs for us and we can just take them from our mdadm.conf additions. Note that these two UUIDs are not the same; the UUID of a filesystem is different than the UUID of the RAID array that contains it, and one will (probably) not work in the place of the other.

(In the long run I will need to take out the rd.md.uuid settings for the old HD-based root and swap partitions, since they don't need to be assembled in early boot and will actively go away someday.)

The one piece of the transition that's incomplete is that /boot is still on the HDs. Migrating /boot is somewhat more involved than migrating the root filesystem, especially as I'm going to merge it into the root partition when I do move it. In the past I've written up two aspects of that move to cover the necessary grub.cfg changes and a BIOS configuration change I'll need to make to really make my new SSDs into the BIOS boot drives, but I've never merged /boot into / in the process of such a move and I'm sure there will be new surprises.

(This is where I cough in quiet embarrassment and admit that even on my work machine, which moved its / filesystem to SSDs some time ago, my /boot still comes from HDs. I really should fix that by merging /boot into the SSD / at some point. Probably I'll use doing it at work as a trial run for doing it at home, because I have a lot more options for recovery if something goes wrong at work.)

PS: The obvious thing to do for merging /boot into / is to build a Fedora 25 virtual machine with a separate /boot and then use it to test just such a merger. There's no reason to blow up my office workstation when I can work out most of the procedure beforehand. This does require a new custom-built Fedora 25 VM image, but it's still probably faster and less hassle than hacking up my office machine.

PPS: It's possible that grub2-mkconfig will do a lot of this work for me (even things like the rd.md.uuid and root= changes). But I have an old grub.cfg that I like and grub2-mkconfig would totally change it around. It's easier to hand modify grub.cfg than write the new config to a new file and then copy bits of it, and in the process I wind up with a better understanding of what's going on.

Some views on the Corebird Twitter client

I mentioned recently that my Fedora 25 version of choqok doesn't support some of the latest Twitter features, like quoted tweets (and this causes me to wind up with a bit of a Rube Goldberg environment to deal with it). In a comment, Georg Sauthoff suggested taking a look at Corebird, which is a (or the) native Gtk+ Twitter client. I've now done so and I have some views as a result, both good and bad.

The good first. Corebird is the best Linux client I've run into for quickly checking in on Twitter and skimming my feed; it comes quite close to the Tweetbot experience, which is my gold standard here. A lot of this is that Corebird understands and supports modern Twitter and does a lot directly in itself; you can see quoted tweets, you can see all of the images attached to a tweet and view them full sized with a click, and Corebird will even play at least some animations and videos. All of this is good for quickly skimming over things because you don't have to go outside the client.

Corebird doesn't quite have all of the aspects of the experience nailed in the way that Tweetbot does, especially in the handling of chains of tweets. Tweetbot shows you the current tweet in the middle, past tweets (tweets it was a reply to) above it, and future tweets (tweets that replied to it) below, and you can jump around to other tweets. Corebird shows only past tweets and shows them below, in reverse chronological order, which kind of irritates me; it should be above with the oldest tweet at the top. And you can't jump around.

However, for me Corebird is not what I want to use to actively follow Twitter on an ongoing basis, and I say this for two reasons. The first is that I tried to do it and it seems to have given me a headache (I'm not sure why, but I suspect something about font rendering and UI design). The second is that it's missing a number of features that I want for this, partly because I've found that the user interface for this matters a lot to me. Things that Corebird is missing for me include:

• no unread versus read marker.
• you can't have multiple accounts in a single tabbed window; you need either separate windows, one for each account, or to switch back and forth.
• it doesn't minimize to (my) system tray the way Choqok does; instead you have to keep it running, which means keeping multiple windows iconified and eating up screen space with their icons.
• it doesn't unobtrusively show a new message count, so I basically have to check periodically to see if there's more stuff to look at.

(With multiple accounts you don't want to quit out of Corebird on a regular basis, because when it starts up only one of those accounts will be open (in one window), and you'll get to open up windows for all of the other ones.)

Corebird will put up notifications if you want it to, but they're big obtrusive things. I don't want big obtrusive notifications about new unread Twitter messages; I just want to know if there are any and if so, roughly how many. Choqok's little count in its tray icon is ideal for this; I can glance over to get an idea if I want to check in yet or not. I also wish Corebird would scroll the timeline with keys, not just the mouse scrollwheel.

I'm probably going to keep Corebird around because it's good for checking in quickly and skimming things, and there's plenty of time when it's good for me to not actively follow Twitter (to put it one way, following Twitter is a great time sink). I'm definitely glad that I checked it out and that Georg Sauthoff mentioned it to me. But I'm going to keep using Choqok as my primary client because for my particular tastes, it works better.

PS: It turns out that Choqok 1.6 will support at least some of these new Twitter features, and it's on the way some time for Fedora. Probably not before Fedora 26, though, because of dependency issues (unless I want to build a number of packages myself, which I may decide to).