Using snapper to snapshoot and restore a system

I have installed the bootloader from each OS on it’s own ESP. Thought perhaps if I ever were to delete or remake the partitions I would be left with at least one bootable system. Might have got it all wrong.

@pebcak
I have installed Arch with Btrfs and snapper and i also don’t really understand a lot of it. I followed a youtube tutorial just to get more familiar with things. It is hard and that’s why i don’t rely on the Arch wiki because there are too many lines of knowledge in between that is missing. Anyway i have it working also but would like to do it on EOS but the process is different because the subvolumes already get created. I have to have more understanding before i can do it myself.

[ricklinux@archsnap ~]$ snapper list
  # | Type   | Pre # | Date                        | User      | Cleanup  | Description     | Userdata
----+--------+-------+-----------------------------+-----------+----------+-----------------+---------
 0  | single |       |                             | root      |          | current         |         
 1  | single |       | Sun 15 Aug 2021 01:00:08 PM | root      | timeline | timeline        |         
 5  | single |       | Sun 15 Aug 2021 02:00:05 PM | root      | timeline | timeline        |         
 6  | single |       | Sun 15 Aug 2021 03:41:45 PM | root      | number   | boot            |         
 7  | single |       | Sun 15 Aug 2021 03:47:02 PM | root      | number   | boot            |         
 8  | single |       | Sun 15 Aug 2021 04:00:48 PM | root      | timeline | timeline        |         
 9  | single |       | Sun 15 Aug 2021 05:35:15 PM | root      | number   | boot            |         
10  | single |       | Sun 15 Aug 2021 06:00:49 PM | root      | timeline | timeline        |         
11  | single |       | Sun 15 Aug 2021 06:13:13 PM | ricklinux | timeline | AfterVmInstalls |         
[ricklinux@archsnap ~]$ 
1 Like

I wouldn’t say it is “wrong” because you can setup a system however you like. I just wouldn’t do it that way. :wink:

Unless you are planning to delete the ESPs themselves, it shouldn’t matter if you delete the other partitions.

On the other hand, if you have some type of partition deleting compulsion which requires you to keep spares around I totally get it.

1 Like

This is partly what I had in mind when I planned the partitioning.

And this explain the rest :sweat_smile:

2 Likes

Thanks for the post @ricklinux !
I appreciate you sharing your experience. I feel I am not in this alone.

Thanks to @dalto I am beginning to see the light in the end of the tunnel. Hopefully I will get around during this week to read up on the subject a bit.

By the way @dalto, what would be the ideal partition scheme for a multiboot system on one BTRFS partiton and systemd-boot?

It depends how many distros. On my laptop I am booting 7 right now so I have a 1.5GB EFI partition, ~10GB of unpartitioned space for emergencies and the rest of the disk as one btrfs partition. If you hibernate, you might want to consider a swap partition.

I don’t think I would install more than 5-7 distros mainly because I could not keep up maintaining them all. And no separate boot partition then? So:

ESP around 1.5G
one big BTRFS partition
10 GB left unformatted.
and perhaps swap

In the system I posted about before, I wouldn’t care about anything but the EnOS Gnome system on it. Is it possible, in order to back it up, send it to an external drive and when the partitioning is done, send it back, chroot into it and convert the booting to systemd-boot?

With systemd-boot there is no point to a separate boot partition. You kernels and initrds live in the ESP. That is why it needs to be so large.

For example, this is a systemd-boot system of mine:

>> ls -l /boot                                                                                                                                                                                                                                                                 
total 0

If it was a physical machine it would only have the ucode files in it.

Yes, unless you want it encrypted with luks. My btrfs is encrypted but it is just a personal preferences.

It is definitely possible but it will be easier if you convert to systemd-boot first and populate /etc/kernel/cmdline. Once in the chroot, the running kernel command line isn’t very helpful.

Also, I wouldn’t bring your gnome system back first. I would use the opportunity to install another distro using the installer straight onto the laptop. Then bring back your gnome system as a 2nd distro.

Alright, thanks! I’ll take in this and let it sink a bit. I will need to head over to your tutorial for systemd-boot and read up on it.

Should it be some distro with systemd-boot out of the box?

It doesn’t matter, I would choose something that is more difficult to inject later.

If you need instructions on converting distros to systemd-boot, let me know. I have documented it for ubuntu/debian, fedora and mageia.

Since this is a whole new area for me, I have no idea which ones might be easier or more difficult to inject.

What I have in mind in terms of distros are some Debian/Ubuntu -based (perhaps Pop,Mint, MX Linux), Fedora maybe Solus, and of course EnOS/Arch (-based).

Another thought: since EnOS is aleady there on BTRFS, so wouldn’t be an idea to delete the other partitions and enlarge its ESP and expand it to the free space after I have it backed-up of course.

  • Solus doesn’t support btrfs on root.
  • MX Linux will have to be converted to systemd before you convert it to systemd-boot
  • Fedora is the easiest to install after the fact. The installer actually supports installing into an existing btrfs partition.

Of that list I would probably install MX Linux first.

Yes, you could. You may have to also move it a little to enlarge your EFI partition depending on how your disk is laid out.

1 Like

Ok, thanks!

MX Linux does have support for systemd if I remeber correctly. It is not just enabled by default. It was a good while ago I had it installed. The installer could install on BTRFS but it didn’t create any subvolumes. I tried to move things to @ and @home but it rendered the system unbootable. I guess I missed to reinstall the grub.

Let me think through the whole thing a bit. I’ll let you know.

It definitely supports it but last I tried it, it had to be installed.

Many installers are like that. It actually works out well when I am transferring from a VM because I can just take a snapshot of /, transfer it and then split it out after the fact.

So if you think it is not that much of a complicated process to convert MX, perhaps I’ll go for this then. Just see if I get things right:
installing MX on BTRFS
converting it to systemd
spliting it to @ and @home
converting it to systemd-boot

ps: I need to check if they have published the latest stable relese. I know that the Beta was out not that long ago.

You probably should decide on a naming convention. They can’t all be @ and @home :wink:

I don’t think so. Debian just released yesterday so I think it will come after that.

1 Like

Yes, I know, I was just using them here as a sort of placeholder. I’ll think i’ll skip the @ as much as I can hereafter.

That gives me some time to think things though.

I’ve still got to read up a bit on BTRFS, snapper etc.

@pebcak
I managed to install snapper and set it up on Xfce in virtual-box. I did an EOS install from the online installer with btrfs and then manually did the rest. It was a little confusing but again i have it working. I’m sure it’s not correct by looking at the subvolumes. Because the install created the original subvolumes for btrfs & i tried to add the snapshots but i think i missed one thing. It should have been ./snapshots?

[ricklinux@rick-virtualbox ~]$ sudo btrfs subvolume list /
[sudo] password for ricklinux: 
ID 257 gen 159 top level 5 path @
ID 258 gen 155 top level 5 path @home
ID 259 gen 144 top level 5 path @cache
ID 260 gen 158 top level 5 path @log
ID 261 gen 29 top level 5 path @swap
ID 264 gen 27 top level 257 path var/lib/portables
ID 265 gen 28 top level 257 path var/lib/machines
ID 271 gen 44 top level 257 path mnt/@snapshots
ID 273 gen 141 top level 257 path .snapshots
ID 274 gen 89 top level 273 path .snapshots/1/snapshot
ID 275 gen 93 top level 5 path @snapshots
ID 276 gen 107 top level 273 path .snapshots/2/snapshot
ID 277 gen 140 top level 273 path .snapshots/3/snapshot
[ricklinux@rick-virtualbox ~]$ 

Edit: Maybe one day i get it.
This is hard for me … :thinking:

1 Like

Well, I am far from the right person to comment on your subvolumes and snaphot setups. Dalto surely will have word with you :wink:

This looks good to me, When it comes to the snapshots etc, I am myself trying to grasp the basic, so I don’t know.