Migrating a separate
/boot filesystem into the root filesystem
In my notes on moving a software RAID-1 root filesystem around, I mentioned that I still had a
/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
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
/bootfilesystem. I use
/etc/fstabto have your separate
/bootfilesystem mounted there.
/bootand remount it on
fstabupdated, this is just '
umount /boot; mount /boot2'.
- copy what is now
/boot. I reflexively do this with
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/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
/boot2and the software RAID UUID of its array. One convenient way to do this is to look in your current
/boot/grub2/grub.cfgfor lines of the form:
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.cfgto make two sets of changes. The first one is to change the old
/boot2MD 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
gmodifier on the
(Note that the MD UUIDs used in
grub.cfgmust 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.cfgcontains filesystem-relative paths for the Linux kernel and its initial ramdisks. In your old
/boot2these were in the root of the filesystem, but now they are
/bootis 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
/bootat the front, like so:
linux /boot/vmlinuz-[...] initrd /boot/initramfs-[...]
Some versions of
grub.cfgmay use '
linux16' and '
initrd16' as the directives instead.
- Finally, run
grub2-installto 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
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
(As a final test you can erase everything in
/boot2 and then fill
it up with data from
/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
filesystem, you will want to edit the kernel command lines in
/boot/grub2/grub.cfg to take out the '
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
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.