BTRFS restoring old snapshots after a kernel update fails

[Tarballwalf]

Which ISO version are you using?

2025.08.01

The installation log

https://0x0.st/8FK8.log

Description of the issue

Restoring an old snapshot after a kernel update, the system fails to boot. Last boot log, tested in a VM, after restoring a snapshot with an older kernel: 8FPz.log

This makes restoring as a last resort when something does goes wrong, go horribly wrong (been there)

Virtual machine config:

Oracle VirtualBox

[svartkanin]

Can you share how you attempted to restore from snapper? If the snapshots are there and created by snapper than everything should have been setup correctly from archinstall's end

[Tarballwalf]

I have a video of doing exactly that

https://github.com/user-attachments/assets/373d50cd-e2e9-4b56-93b3-e19dc8a6a174

[svartkanin]

I tried this out now and these are the conclusions

• Installed a new system with btrfs and snapper -> successful
• Tried a restore process with the https://gitlab.com/btrfs-assistant/btrfs-assistant tool -> successful
• Tried restoring the same downgraded kernel as in the recording -> failed

Given that snapper restore worked for regular restores without the kernel downgrade scenario I would say everything is installed and setup correctly. The restore of a downgraded kernel upgraded my have wider implications which goes beyond what archinstall is meant to do for a system installation.

[Tarballwalf]

Perhaps looking into what 3rd party arch distros (like endeavor) are doing to see which could actually be the cause of this?

I've been running archinstall and other arch based distros on other systems with mostly the same (timeshift instead of snapper) and those seems to be fine. Perhaps they are doing something different with their installation?

If it's out of the scope you can just close this issue

[svartkanin]

Most other distros - including EndeavourOS - use https://github.com/calamares/calamares, I'm not aware that it provides any feature that sets up snapper/timeshift

[Tarballwalf]

Could it be due to the fact that the kernel is kept on a vfat partition? I could check to see what they're exactly doing to get this working on their part.

It's probably not the way snapper/timeshift is set up but how the kernel might be kept within the snapshot (if kept at all) or some other btrfs related thing?

[svartkanin]

Maybe you would have to rebuild initramfs after applying the snapshot?

[Tarballwalf]

I don't think since none of the other arch based distros did that when I used them. You'd just restore the snapshot and immediately work. (maybe they did that im the background and I'm not aware?)

I'll give it a try in arch later in the day and come back with the results but I doubt that's the cause.

[svartkanin]

While you're at it would you mind checking if the /etc/fstab looks odd in any way

[Tarballwalf]

So I tried just that. Rebuilt the kernel right before rebooting after applying the snapshot and no luck. System still failed to boot. I also tried to chroot, and got this error Checking the modules directory seems to only have modules available for 6.16 (kernel before restoring and downgrading)

Here's the arch fstab contents:

I have also tried EndeavourOS with snapper, it also seems to fail. First try it worked and I thought I had forgotten to downgrade the kernel, did it again and it failed. I remember this working on eos, maybe I'm totally wrong. Maybe it was Manjaro that got it working? I dunno.

Shall we close the issue since it might not actually be archinstall's fault? Or should we keep it open just in case? At this point I'm feeling like I'm going way too much beyond what this project does

[Tarballwalf]

AH! It was EndeavourOS with GRUB and Timeshift that worked! I have also tested it with snapper and it seems to work. But Arch with GRUB does not work.

Here's a screenshot of all the VMs I tried (top systemd, bottom grub, left arch, right eos)