Control: retitle -1 RFP: grub-btrfs -- provides grub entries for btrfs snapshots (boot environments/restore points) Control: noowner
Hi Pascal! Pascal Jäger <pascal.jae...@leimstift.de> writes: > am one of the devs of grub-btrfs and I am the one responsible for the last > few updates to it. > Thank you for your work on grub-btrfs, it looks like it's matured a lot since I filed this ITP years ago :) I've converted this ITP to an RFP, because I suspect everyone feels like I'm taking too long haha. > Recently the idea arose to make a Debian package for it. [1] > While researching how to do that I found this ITP. > Now this kind of is on ice, the last reply was more than a year ago, and I > wonder why. And how we should proceed on this. > I already filed another ITP which should be closed, I guess. Bart took care of that ;) > We have a package already from the dev of Kaisen Linux which that dev wanted > to contribute to Debian after getting a sponsor. > So if you are still interested into packaging grub-btrfs I would suggest the > guy from kaisen linux prepares his Debian package and you sponsor it maybe? > What is Kaisen Linux? I read issue #236 that you linked to, and it seems like geckolinux (author of Spiral Linux or Gecko Linux?) should possibly be part of this conversation. Kali Linux also has its own packaging. To get grub-btrfs into the unstable->testing->stable stream of Debian (which is what an Intent to Package is about, long-term), there are a couple of TODOs: 1. The Debian package needs a committed, motivated, *long-term* maintainer with free time. I've been short on free time and extra energy for a while, which is a shame, because btrfs integration was once my #1 priority in Debian. 2. Whether manually, or with CI, there needs to be one or more regularly tested configurations. For example, a Snapper-based snapshot layout, Timeshift, or some_other_tool-based snapshot layout. I hope geckolinux can help with this. This one is important to critical. If a normal user loses data while doing something completely reasonable, then we've failed to consider the problem with due diligence. I'm also aware that Neptune OS and Linux Mint are using Timeshift. 3. Does Timeshift's (already in Debian) GRUB menu entry support (is this enabled yet?) conflict with grub-btrfs? Are there any other conflicts? For example, ZFS stuff? Any other pitfalls that may cause data lose? This one is important to critical. 4. I think everyone will agree that users who install this will have a reasonable expectation of automatic boot environments/system restore points. This requires an apt trigger in whatever tool is used to make the snapshots. This one is normal. 5. A decision needs to be made about what layouts will be supported, and what layouts will be "if it breaks, you're on your own". It's possible (but unlikely, as far as I can tell) that additional Debian Installer work will be necessary. This is arguably just another aspect of #1. As far as I can tell, the following are the cases this package will encounter, in order of most common to least common: a) Our default @rootfs, no other subvolumes. b) @roots, and @home -- Ahem! This seems like it will be required, to not lose user data! Yes, this is why I stalled for so long. Debian Installer is not fun to work on. c) Either support old installations directly on subvolid=5, or loudly declare that they're not supported somewhere in the description and documentation. Seems like user data will be lost similarly to "b" d) How to protect /var/www as well as databases? e) Snapper/SUSE style, which is a superset of Ubuntu-style, as far as I can tell, or maybe Ubuntu-style is a subset of SUSE? Does anyone know? f) Ubuntu-style @ and @home 6. And what happens when a user has both Debian stable and unstable/sid (or Ubuntu) installed to the same drive, and both have grub-btrfs installed? What is "The Right Thing" in this case, and will grub-btrfs Do The Right Thing? This question prompted the discussion that led to rootfs on "@rootfs" rather than "@" like Ubuntu/SUSE or "rootfs" like Fedora. I can't commit to reviewing anyone's work in time for the freeze due to poor availability of free time in the coming months. That said, I will be happy to help with coordination and staging in the experimental suite during the freeze, and the features can be introduced via bookworm-backports so users of Debian stable can still benefit. Other than all this, I suspect that the following is probably what users expect will happen: 1. Boot from read only subvolume (how to check for bootable subvolumes?) with an overlayfs and prominent warning that any changes will not be written to disk. The tool that handles the GRUB config would need to do this. If it can't be done with kernel command line, then an initramfs (with hooks) could be used. * Alternatively, I guess a pure btrfs solution could make a writeable snapshot of the known-good read-only one, and then boot that. At the initramfs stage, run the RW snapshot creation trigger, then boot into that. * "Restore points" are like immutable tags, and "boot environments" are like branches. Maxim: A read-write save point is not truly safe. 2. If the snapshot is good, rename the HEAD (well, newest...) rootfs snapshot to something with -bad, and rotate the good snapshot into the default position. If I remember correctly Snapper has some sort of functionality like this--at least on SUSE. Regards, Nicholas
signature.asc
Description: PGP signature