Bug#941627: Packaging grub-btrfs
Hi Nicholas,
it's good we get this process going again. It looks like every other
Debian spin-off has a package already, so let's get one into Debian. ;-)
Let me clarify some things below.
Quoting Nicholas D Steeves <sten@debian.org>:
Control: retitle -1 RFP: grub-btrfs -- provides grub entries for
btrfs snapshots (boot environments/restore points)
Control: noowner
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.
Kaisen is a Linux distribution for IT-Admins that is based on Debian
testing. They got their own grub-btrfs .deb package already and the
dev of them (KaisenCAS in that conversation) has declared his will to
maintain the Debian package in the future.
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.
Yes, this is something we need to consider. I think grub-btrfs is
'wild'-tested in many different configurations by our users already,
mostly by people who have the live build of it on Arch and Gentoo, but
we have to put his into regulated procedures. I think regarding tests
on Debian based distros geckolinux and Kaisen are doing this already.
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.
I will try this out, but I don't think it will. We just generate a
grub-submenu with snapshot entries and do not touch the snapshots
themselves no do we touch the other grub-submenues.
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.
I don't think this is in the scope of grub-btrfs. We are generating
the grub menu entries, that's it. We don't generate snapshots and
there are already programs out there that are doing this way better we
ever could.
But I totally understand the need for Debian to integrate something
like that. On Arch they seem to have hooks in pacman and users can
just put there own commands there. There is Timeshift-Autosnap [1]
(and many similar scripts) for that.
There is also a apt version of that already. However, grub-btrfs is
just looking for the snapshots and generates the grub submenu from the
list that 'btrfs subvolume list' gives it.
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
This is mostly relevant to snapshot generation program like timeshift
and snapper, but I can see that this could be important for us when
booting with overlayfs.
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 see that this could get very complicated. I think the right
thing would be to generated to submenues, one from Debian stable and
one for Ubuntu. But I don't think we could tell which snapshot and
which kernel/initramfs in /boot belongs to which snapshot. I will look
into this.
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.
I see that you have a greater vision of btrfs on Debian. But
grub-btrfs can only play a part in this greater vision. We make grub
submenues of snapshots, that's all. :-)
There already are other tools for making snapshots and restoring them.
We should get the overlayfs working on however, because that is
something we only support for archs mkinitcpio right now.
Regards,
Pascal
[1] https://gitlab.com/gobonja/timeshift-autosnap
Reply to: