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
on it. Having created them as
/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
mdadm.conf by hand. Once you have updated
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
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
/etc/fstab to use the UUIDs of the new filesystem and swap
/ and, well, swap. The easiest way to get these UUIDs
is to use
blkid, as in '
blkid /dev/md10' and '
(For now I'm mounting the old HD-based root filesystem on
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
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
already reported these UUIDs for us and we can just take them from
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
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
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
/ in the process of such a move and I'm sure there will be
(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
/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
PS: The obvious thing to do for merging
/ 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
PPS: It's possible that
grub2-mkconfig will do a lot of this work
for me (even things like the
root= changes). But
I have an old
grub.cfg that I like and
totally change it around. It's easier to hand modify
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
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).