To make backing up easier, I would like to merge the default-created 1 Gb boot partition into the root partition, which is formatted BTRFS.
I have subvolumes for root var home
I am aware that Grub does not fully support BTRFS, and that I will probably have issues with changing the boot order.
But is this possible, and how?
Fedora 39 Workstation.
My plan is to use btrfs send in order to have a backup of all subvolumes. Then, if I need to migrate my system to another disk, I can reinstall Fedora with the same subvolumes, and restore the snapshots onto it.
But if the boot partition is separate, and I reinstall, the boot is likely to have a different kernel than what is in the snapshot.
It is possible (though a bit complicated) to re-create the “boot” partition from the contents of a root partition. Essentially, you have to use the chroot command (from the Live CD or whatever you are using to restore the backup) and then re-install/re-copy your boot loader and kernel to /boot. You’ll probably need to do something along those lines anyway because the ESP cannot be Btrfs.
Another, and to me much simpler way, would be to convert the root partition to an ext4 partition. Once that is done then /boot can easily reside within that partition with no fussing with btrfs and the need to " force" the boot loader to load the btrfs driver before reading and loading the kernel and initramfs image.
Yes, it supposedly can be done. It does require that grub be able to load the btrfs driver before it could load the initramfs and the kernel. That is not as straight forward as it may sound.
One other thing to note is that UEFI requires a FAT partition, so /boot/efi still needs to live on its own. btrfs can be /boot otherwise, but it might not be compatible with all systems. If you’re being experimental about it, there is a ext4 to btrfs conversion utility and you could also do custom partitioning during install. I’m not aware of any tool that can directly convert from btrfs back to ext4.
Obviously, back up everything before you attempt this regardless.
The practice of using ext4 for / and btrfs for data (/home etc.) works well with or without capturing the install/configuration with kickstart/ansible or suchlike.
According to that link and LWN the change is not currently scheduled for anything except cloud and VM installs. Apparently while this is a great idea, the variety of hardware which forces a need for a locally built initramfs image still limits the wide spread of that plan for use directly on the hardware. VMs and cloud use seems relatively easy with the limited variety of hypervisor software and means that fewer variations in the virtual machine interfaces are easier to over come.
I have not found the reference again but I think that a switch to systemd-boot also includes moving everything currently in /boot to the ESP. If I find it again I’ll add it here.
Once a shim is signed such that uki and sd-boot can work without managing my own keys and signing things myself it will be interesting to see what fedora signs beyond that.
I once considered trying to use systemd boot, but halted before completing that switch because of the inability to use secure boot.
Yes, it was apparent that almost everything in /boot would have been moved to the ESP and that what is currently /boot/efi would have become /efi instead.
It appears that security and the fact that systemd boot cannot and would remain unable to use secure boot may have been why that seems to have stalled. Apparently systemd boot could not use the shim that allows fedora to use secure boot.
The uki approach would allow for secure boot, but at the moment the multiple hardware platforms and configs seems a sticking point for overall usage.
Work on getting a signed shim that can be used so secureboot sd-boot works seems to be stalled or at least not visible.
But the uki work needs a new signed shim as well. If fedora can sign ukis they should also be able to sign sd-boot and use the same new shim? We can hope.
What format is used by default for /boot? Is it ext? Gparted can’t read the format type of /boot.
Windows imaging tools such as Macrium Reflect are pretty good at imaging and restoring linux ext partitions that are GPT or MBR.
Defaults appear to be: /boot/efi is VFAT, /boot is EXT4, the remainder is BTRFS.
This seems to apply to most of the workstation spins regardless of the DE used.
AFAIK the only thing that may be different is the server and possibly the IoT release.
I have found it useful to look at what fedora does to build all the various iso images that are published by investigating the kickstart files.
I also find instructive information by browsing through the anaconda files on those isos. I would like to find where that code is hosted though. It is the anaconda code that is used to partition and format storage.
I think this makes backing up even harder. It sounds simpler but in practice I would shy a way from doing it. I have systemd-boot and /boot/efi needs to be fat32.
This would require separate backups.
One of the btrfs partition, one of the /boot partition, and one of the efi partition.
However restoration to a new drive would create separate and different UUIDs for each so the restoration would be difficult since the UUIDs are required for both machine ID and partition ID to properly configure boot.
In case of a need to reinstall, simply reinstall. That makes the proper UUIDs within the config problems.
Apps can be easily reinstalled, upgrades done, and everything would work. The only data that would be required to restore from backup would be the users data located in /home.
Keeping track of the apps you have personally installed and reinstalling them would be much easier than trying to keep backups of the OS in sync with every time something was updated. That would avoid the problems with mismatched UUIDs during a restore.
Snapshots are great and work well as long as the drive does not fail and need replaced.
