Control: retitle -1 RFP: grub-btrfs -- provides grub entries for btrfs snapshots (boot environments/restore points)
Control: noowner
Hi Pascal!
Pascal Jäger <Pascal.jaeger@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
Attachment:
signature.asc
Description: PGP signature