Package name : grub-btrfs Version : 4.1 Upstream Author : Antynea <anty_fab@hotmail.fr> URL : https://github.com/Antynea/grub-btrfs License : GPL-3+ Programming Lang: bash Description : GRUB entries for btrfs snapshots (boot environments/restore points) Grub-btrfs generates grub entries for btrfs snapshots, thus making it easy to roll back to a known-good state. Other operating systems call this functionality "system restore points" or "boot environments" (aka: BEs). This package supports booting from manual snapshots stored in a predefined location, and appears to also support snapper (it seems the snapper support may be buggy in the v4.1 release). At present, snapshots must be the read-write type, but it should be possible to extend this software to the following from an initramfs: make a rw BE from a ro snapshot during the premount stage. I've been waiting for this software to mature for a couple of years before filing an ITP, and it looks like it's finally ready to validate. I've blocked this ITP by "debian-installer: Add btrfs subvolume setting for snapshot" because I do not believe that this package is useful until a default Debian installation using btrfs provides separation between rootfs and user data. That said, I believe that it is appropriate to work on it in the experimental suite. It is probably most useful for people who want to track sid, but with insurance against having to back out of an upgrade when they don't have any free time. Ideally I'd like to form a btrfs-task force to work on related issues and maintain this package there, but as of yet no one has shown interest in such a team. If you are interested, please speak up! I will need a sponsor for the initial upload. Regards, Nicholas
Hi, is there any news about this? thanks for any reply
Hi Fabio, Fabio Fantoni <fantonifabio@tiscali.it> writes: so the first major blocker is gone :-) While investigating how to add subvolume support to the Debian Installer Rescue Mode, I started wondering if os-prober might be the right place to add support for the detection of bootable subvolumes; bootable subvolumes are the minimum requirement for "boot environments". In particular, if other (potentially non-Debian) OSs need subvolume support in os-prober, then I will need to take care to not cause duplicates, shadowed entries and/or various other grub menu bugs by introducing grub-btrfs. There are also existing users who install multiple OSs to the same volume, using different subvolume naming schemes; yes, this may be admittedly a minority case, but I'd also like to avoid creating problems for these users with an insufficiently researched solution. Then there's the question of how grub-btrfs will interact with Snapper and btrbk. I guess I could upload something to experimental for users who want a "YOLO!" experience, but I'd prefer to complete my cautious investigation first. What would you prefer? Of course I won't say no to a volunteer early-adopter, who wants to give it a try before it's ready ;-) Oh, one more thing, I'd like to put together a btrfs enablement team--probably in mid-September. If you'd like I can CC the announcement email to you. At any rate, please ping me in mid-September if you haven't seen further progress! Regards, Nicholas
Il 04/08/2021 20:30, Nicholas D Steeves ha scritto: Thanks for you reply, I think is good investigate and implement at best as possible, at least for the most common cases, I cannot assure you that I will be an "earlytester", I don't have much time but you can put me in cc here and in other discussions about it. I started consider it for some debian server at work now with btrfs root when I'll use snapshot before upgrade for faster restore in case of issue, I was looking also for grub entry to snapshot for even faster restart in production. It would also be useful on desktop, the goal would be to restart quickly and easily after a bad update, it is more very rare than in windows but unfortunately I have seen it happen a few times, for me and other users that can fix it using terminal and/or a live cd is not an issue, for other yes. Recently I started to use timeshift (with rsync) on ext4 (backup of only root without /home before any upgrade) but since now almost all of them have ssd on desktop and btrfs seems very stable in latest year (excluding some rare exception) so I could switch to use btrfs too, possibly in some cases I'll keep /home out still in ext4. Thanks for your work and sorry for my bad english.
am one of the devs of grub-btrfs and I am the one responsible for the last few updates to it. 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. 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? Best, Pascal [1] https://github.com/Antynea/grub-btrfs/discussions/236 (https://github.com/Antynea/grub-btrfs/discussions/236#discussioncomment-4237797)
Hi Pascal!
Pascal Jäger <Pascal.jaeger@leimstift.de> writes:
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.
Bart took care of that ;)
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
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>: 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. 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. 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. 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. 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. 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. 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
I need this package for day work (for teaching). The kaisen linux is suitable for me to be imported and sponsored. Kaisen do you want some sponsoring and comaintain debian side this package ? I only need that dracut is supported and tested. Kaisen could you support dracut ? Bastien
Il 27/09/2023 12:04, Bastien Roucariès ha scritto: Hi, is there any news? I think grub-btrfs could add to Debian even without waiting for subvolume setting support to be added in the installer, I have seen many howtos for Debian and derivatives, the latest was https://github.com/orgs/linuxmint/discussions/549, so it seems quite used and wanted, i think it's good to make it easier and faster to use thanks to the package in Debian. I give a fast look to https://github.com/kaisenlinux/grub-btrfs, have timeshift support "only" and as default, I think is better have it in specific package like grub-btrfs-timeshift (but on same source) as done by other distro, so as not to hinder support for other backup programs or snapshots with custom scripts.
Le lundi 19 août 2024, 08:00:10 UTC Fabio Fantoni a écrit : Hi If you want to work I can sponsor you Work need here: - https://github.com/Antynea/grub-btrfs/issues/314 Long term (for disaster recovery bash is not nice): - https://github.com/Antynea/grub-btrfs/issues/300 Note dracut support is needed due to for instance this https://github.com/Antynea/grub-btrfs/issues/260 Dracut upsteam is reactive https://github.com/dracut-ng/dracut-ng so you could open a bug Bastien
Il 19/08/2024 10:41, Bastien Roucariès ha scritto: grub-btrfs is one of the many projects I would like to contribute to but unfortunately I don't have the time. I was planning to use it for some desktop installations with timeshift and some servers at work (maximum a few dozen) with other backup software (I was still hesitant about the choice). in the meantime for the server part where I would have needed it more, my employer wanted to use proxmox instead of a Debian base on which I had more "flexibility", I have not yet had time to look at how the default btrfs configuration is and if it would be usable for backup the root and use grub-btrfs. In the tests of years before there had been more problems with proxmox updates while at the moment I have only had one with the 6.8 kernel that I quickly bypassed with the grub entry already present in the old kernel. so I guess I would have enough time to work with grub-btrfs if proxmox proved unstable with updates like the first uses I made of it many years ago