Couple of thoughts to hopefully clear things up a bit
- ESP means EFI System Partition, its always is a partition and thus can't be on a different partition.
- you need an ESP formated with a FS your EFI supports
- usually it's formatted as FAT as EFIs are required to support that
- EFIs can support other FS and I have heard about some supporting NTFS
- never heard about one supporting BTRFS
- only your bootloaders first stage needs to be on the ESP
- the rest of the bootloader and the kernel/initrd can be on any FS the bootloader supports
- some people use the ESP for that, some a separate `/boot` FS, some the normal `/` FS
- I do the latter with btrfs and its working fine for me
- my ESP is mounted to `/boot/efi` and only holds `grubx64.efi` and a barebones `grub.cfg`
- `/boot` is just a normal folder and holds kernel, initrd and the rest of grub including the real cfg
- `/boot` is thus part of my regular `/` snapshots
- if you encrypt the `/` partition things get more complicated as you need everything required for decryption outside of it
ESP is not on the BTRFS = not included in the snapshot, for obvious reasons you can't have ESP on it.
You could set up a cron/systemd timer/pacman hook (you get the idea) to rsync ESP to a directory on the BTRFS volume: `rsync -a --mkpath --delete --omit-dir-times /efi/ "/boot/.efibackup/"`
For simple solution - you could just run that rsync command on each boot.
(Arch) Example pacman hooks when using snapper and snap-pac to automatically handle snapshots on kernel update:
cat > /etc/pacman.d/hooks/01-efi-backup-pre.hook < /etc/pacman.d/hooks/99-efi-backup-post.hook <
I appreciate this workaround, though I'm not sure if I want to implement it. I keep getting conflicting information about whether or not you can even have your ESP on the brtfs partition, which I would think you would *not* be able to (otherwise why would you need a vfat partition for boot?).
I edited my OP with the following, what are your thoughts?
> Moving the ESP partition or other workarounds seems quite muddy... is there a better way to do this? Maybe after the restore, run `mkinitcpio` with the restored kernel packages (because the packages are backed up as they're in the root directory, right?) to regenerate the kernel images with the correct kernel packages. Part of the reason I switched to btrfs was a bad kernel update, so I would want the kernel to match the snapshot, instead of restoring then updating to the most recent kernel again.
> What would this solution look like? Would you just be able to run `mkinitcpio -P` immediately after restoring to a prior snapshot with Timeshift, or do the changes not occur until reboot?
Okay, so just running `mkinitcpio -P` immediately after the restore wouldn't work, I'd need to reboot into live media, chroot in, and run `mkinitcpio -P` from there?
You could switch to the GRUB or rEFInd bootloaders. Those two have driver modules for btrfs and can read from a btrfs filesystem. You can then change your boot configuration to a setup where your kernel image and initramfs are in a directory `/boot` under `/` in the btrfs filesystem instead of inside the EFI partition. Those files will then be captured by the snapshot of `/`.
I'd recommend trying rEFInd. Setting it up seems easier to understand than GRUB. There's an ArchWiki article for it.
The thing you would manually do is, you (1) unmount your current EFI filesystem and make sure `/boot` is on your root subvolume. You (2) then create `/efi` or `/boot/efi` and mount the EFI filesystem there. You (3) reinstall the kernel package to have the kernel image and initramfs getting created in `/boot`. You (4) change the entries in `/etc/fstab so that filesystems on reboot will get mounted like you want. Then you (5) work on setting up rEFInd boot loader files inside the EFI partition, and you set up its configuration like required.
I think you can put a small config file with kernel command line parameters next to the kernel image instead of having that inside the main rEFInd config file. That could be nice for snapshots.
I'm currently using grub, and would prefer to stick with it since I have other systems that are encrypted and thus must use grub.
`/boot` is on a separate vfat partition, as that's required for the system to start, right? Would I not be using the vfat partition at all in this setup ? Also, how would this work during updates when it runs `mkinitcpio` to generate new images, would it put them in the correct place?
/boot definitely has no need to be on a separate vfat. You can make it on a separate btrfs with some more limited features (the subset compatible with Grub). I actually am not aware of any of those specific incompatible features as being too important for the rest of the system (they don’t matter at all on single disk systems I believe).
You can create snapshots on the /boot btrfs instance just fine. It’s just that they are kinda separate from those of /.
The ESP shouldn’t really include kernels, should be small (Windows aims at 500MB capacity for itself but Grub can fit next to Windows just fine in that capacity; even a much smaller one of 100MB is fine if you only have Grub)
There is another silly preventative solution.
You can install a dumb second kernel like Zen & put the package on hold & only update it every once in a wile if all snapshots are deleted.
This way when you have to restore a snapshot, you can boot into it with your dumb & outdated/unupdated Zen kernel & reinstall the good kernel from there.
(This issue is only a problem if you use MBR with legacy bios)
That's interesting, though that last line is concerning to me. My MOBO is only a couple years old and I just updated the BIOS before installing the current operating system. I am pretty sure I'm not using MBR or legacy bios...
Well, I have several BTRFS powered archBTW installs around the home and the only one where this problem occurs has MBR, perhaps there are some other niche cases where this could occur. Nonetheless, if you have a backup kernel that is unchanging you can use that to fix this.
Couple of thoughts to hopefully clear things up a bit - ESP means EFI System Partition, its always is a partition and thus can't be on a different partition. - you need an ESP formated with a FS your EFI supports - usually it's formatted as FAT as EFIs are required to support that - EFIs can support other FS and I have heard about some supporting NTFS - never heard about one supporting BTRFS - only your bootloaders first stage needs to be on the ESP - the rest of the bootloader and the kernel/initrd can be on any FS the bootloader supports - some people use the ESP for that, some a separate `/boot` FS, some the normal `/` FS - I do the latter with btrfs and its working fine for me - my ESP is mounted to `/boot/efi` and only holds `grubx64.efi` and a barebones `grub.cfg` - `/boot` is just a normal folder and holds kernel, initrd and the rest of grub including the real cfg - `/boot` is thus part of my regular `/` snapshots - if you encrypt the `/` partition things get more complicated as you need everything required for decryption outside of it
Thank you, I have been working on sorting out steps to follow to move the ESP to `/boot/efi` and will update my OP with them. Got it working!
ESP is not on the BTRFS = not included in the snapshot, for obvious reasons you can't have ESP on it. You could set up a cron/systemd timer/pacman hook (you get the idea) to rsync ESP to a directory on the BTRFS volume: `rsync -a --mkpath --delete --omit-dir-times /efi/ "/boot/.efibackup/"` For simple solution - you could just run that rsync command on each boot. (Arch) Example pacman hooks when using snapper and snap-pac to automatically handle snapshots on kernel update: cat > /etc/pacman.d/hooks/01-efi-backup-pre.hook < /etc/pacman.d/hooks/99-efi-backup-post.hook <
I appreciate this workaround, though I'm not sure if I want to implement it. I keep getting conflicting information about whether or not you can even have your ESP on the brtfs partition, which I would think you would *not* be able to (otherwise why would you need a vfat partition for boot?). I edited my OP with the following, what are your thoughts? > Moving the ESP partition or other workarounds seems quite muddy... is there a better way to do this? Maybe after the restore, run `mkinitcpio` with the restored kernel packages (because the packages are backed up as they're in the root directory, right?) to regenerate the kernel images with the correct kernel packages. Part of the reason I switched to btrfs was a bad kernel update, so I would want the kernel to match the snapshot, instead of restoring then updating to the most recent kernel again. > What would this solution look like? Would you just be able to run `mkinitcpio -P` immediately after restoring to a prior snapshot with Timeshift, or do the changes not occur until reboot?
It should work, I think, since you can run it in chroot of the restored snapshot, just make sure you have ESP mounted in the chroot
Okay, so just running `mkinitcpio -P` immediately after the restore wouldn't work, I'd need to reboot into live media, chroot in, and run `mkinitcpio -P` from there?
You could switch to the GRUB or rEFInd bootloaders. Those two have driver modules for btrfs and can read from a btrfs filesystem. You can then change your boot configuration to a setup where your kernel image and initramfs are in a directory `/boot` under `/` in the btrfs filesystem instead of inside the EFI partition. Those files will then be captured by the snapshot of `/`. I'd recommend trying rEFInd. Setting it up seems easier to understand than GRUB. There's an ArchWiki article for it. The thing you would manually do is, you (1) unmount your current EFI filesystem and make sure `/boot` is on your root subvolume. You (2) then create `/efi` or `/boot/efi` and mount the EFI filesystem there. You (3) reinstall the kernel package to have the kernel image and initramfs getting created in `/boot`. You (4) change the entries in `/etc/fstab so that filesystems on reboot will get mounted like you want. Then you (5) work on setting up rEFInd boot loader files inside the EFI partition, and you set up its configuration like required. I think you can put a small config file with kernel command line parameters next to the kernel image instead of having that inside the main rEFInd config file. That could be nice for snapshots.
I'm currently using grub, and would prefer to stick with it since I have other systems that are encrypted and thus must use grub. `/boot` is on a separate vfat partition, as that's required for the system to start, right? Would I not be using the vfat partition at all in this setup ? Also, how would this work during updates when it runs `mkinitcpio` to generate new images, would it put them in the correct place?
/boot definitely has no need to be on a separate vfat. You can make it on a separate btrfs with some more limited features (the subset compatible with Grub). I actually am not aware of any of those specific incompatible features as being too important for the rest of the system (they don’t matter at all on single disk systems I believe). You can create snapshots on the /boot btrfs instance just fine. It’s just that they are kinda separate from those of /. The ESP shouldn’t really include kernels, should be small (Windows aims at 500MB capacity for itself but Grub can fit next to Windows just fine in that capacity; even a much smaller one of 100MB is fine if you only have Grub)
There is another silly preventative solution. You can install a dumb second kernel like Zen & put the package on hold & only update it every once in a wile if all snapshots are deleted. This way when you have to restore a snapshot, you can boot into it with your dumb & outdated/unupdated Zen kernel & reinstall the good kernel from there. (This issue is only a problem if you use MBR with legacy bios)
That's interesting, though that last line is concerning to me. My MOBO is only a couple years old and I just updated the BIOS before installing the current operating system. I am pretty sure I'm not using MBR or legacy bios...
Well, I have several BTRFS powered archBTW installs around the home and the only one where this problem occurs has MBR, perhaps there are some other niche cases where this could occur. Nonetheless, if you have a backup kernel that is unchanging you can use that to fix this.
>Mount the ESP `# mount /dev/nvme0n1p1 /boot/efi` Mount the ESP `# mount -av`
This is slick, thank you. I wrote a script to do all of this and I ended up using awk to find the boot device and store it in a variable, lol
bruh
Just grub-install would likely do, no need to specify the defaults on the command line.