In my notes on moving a software RAID-1 root filesystem around, I mentioned that I still had a separate /boot partition on my home and office machines and I wanted to merge it into the root filesystem at some point as I no longer believe in a separate /boot under most circumstances. Having now done this both in a test Fedora 25 virtual machine and on my office workstation, it's time to write up the procedure. For a slight extra complexity, my /boot and root filesystems are both in Linux software RAID-1 arrays.

First, make sure you're actually booting off your root drives, which may require BIOS fiddling. I probably still have to do this at home (on my new SSDs), but it was already done on my office machine a while back. Then my process is:

• Make the directory that will be the new mount point of your old separate /boot filesystem. I use /boot2.
• change /etc/fstab to have your separate /boot filesystem mounted there.
• unmount /boot and remount it on /boot2. With fstab updated, this is just 'umount /boot; mount /boot2'.

• copy what is now /boot2 to /boot. I reflexively do this with dump:

  cd /boot && dump -0f - /boot2 | restore -xf -
  

  (We don't need to remake /boot, because unmounting the filesystem from it leaves behind an empty directory that previously was the mountpoint.)

• You need to know the UUIDs of the root filesystem and your root software RAID device. You can get these from /etc/fstab and /etc/mdadm.conf, or you can use commands such as 'lsblk --fs /dev/mdNN' and 'mdadm -D /dev/mdNN'.

  The software RAID UUID will have :'s in it, for example '35d6ec50:bd4d1f53:7401540f:6f971527'. You're going to need a version of the UUID without them, ie just one long string of hex digits.

• Also find the filesystem UUID of what is now /boot2 and the software RAID UUID of its array. One convenient way to do this is to look in your current /boot/grub2/grub.cfg for lines of the form:

  set root='mduuid/05a2f6e13830b3a102f7636b98d651f3'
  

  and

  search --no-floppy --fs-uuid --set=root 91aed8b1-c145-4673-8ece-119e19f7038f
  

  Those are the MD UUID and the filesystem UUID respectively. As you may have guessed, you need a version of the MD UUID without colons, because that's what Grub2 wants.

• Now you need to edit /boot/grub2/grub.cfg to make two sets of changes. The first one is to change the old /boot2 MD UUID and filesystem UUID to the MD UUID and filesystem UUID of your root filesystem, so that Grub2 is looking in the right filesystem for everything. This should be easy with something like_vim_ search and replace, but remember to make sure your command changes all occurrences on a line, not just the first one (eg, vim's g modifier on the s command).

  (Note that the MD UUIDs used in grub.cfg must be the version without :'s in it. Grub2 probably won't like you too much if you use the other form, although I haven't tested it. Yes, it is a bit annoying that Grub wants a different form of MD UUID than the tools normally produce.)

  However, this isn't sufficient by itself, because grub.cfg contains filesystem-relative paths for the Linux kernel and its initial ramdisks. In your old /boot2 these were in the root of the filesystem, but now they are /boot/vmlinuz-*, because /boot is now a filesystem subdirectory. So you need to edit every set of lines that are like:

  linux  /vmlinuz-[...]
  initrd /initramfs-[...]
  

  Change them to add a /boot at the front, like so:

  linux  /boot/vmlinuz-[...]
  initrd /boot/initramfs-[...]
  

  Some versions of grub.cfg may use 'linux16' and 'initrd16' as the directives instead.

• Finally, run grub2-install to reinstall the Grub boot blocks onto your boot drives, eg 'grub2-install /dev/sda'. This updates the embedded Grub so it knows about your new location for /boot; if you skip this step, your Grub boot blocks will probably quietly keep on using what is now /boot2.

To test that this is working, reboot your machine and go into the Grub menu during boot. When you look at the text for a specific boot entry, you should see that it's using 'linux /boot/...' and so on; the presence of the /boot bit is your proof that Grub is actually reading your updated /boot/grub2/grub.cfg instead of the old, un-updated grub.cfg in /boot2.

(As a final test you can erase everything in /boot2 and then fill it up with data from /dev/zero or /dev/urandom to overwrite all of the disk blocks. If the system still boots happily, you are definitely not using anything from the now thoroughly destroyed /boot2. I feel that going this far is only appropriate in a test environment; I did it with my Fedora 25 test virtual machine, but not on my office workstation.)

At some point in the future when you decommission the /boot2 filesystem, you will want to edit the kernel command lines in /boot/grub2/grub.cfg to take out the 'rd.md.uuid=<...>' argument that is telling dracut to try to bring up that software RAID array.

(You might wonder why we didn't have to add or change a rd.md.uuid kernel command line argument for the /boot migration. The answer is that since /boot is now on the root filesystem, the kernel's command line already has a rd.md.uuid argument to bring it up on boot. Or at least it should.)

Sidebar: Why I haven't done this to my home machine yet

One version of why is that rebooting my home machine usually feels like more of a pain than rebooting my office machine, because I'm usually doing something with my home machine that I don't want to interrupt. So I drag my heels on anything and everything that can call for a reboot, such as Fedora kernel upgrades.

A more complete version is that not only do I have to reboot my machine, but I should really also open it up to take out my two old 500 GB system HDs, which won't really be in use after this shuffle (on my home machine, I put my small swap partition on my SSDs). And the reason I want to do this is that right now my pair of SSDs aren't actually mounted in drive bays, because I don't have enough. Instead they're just resting loose in a 5.25" drive bay, and the problem with that is the 5.25" drive bays get clearly less air circulation than the 3.5" drive bays.

I should really just do all of this shuffling, but I may have recently mentioned that I'm lazy. I really do want to do it soon, though. Hopefully having written this will motivate me to do it tomorrow.