Bug#1124108: bookworm-pu: package rescue/1.93+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-boot@lists.debian.org, Martin-Éric Racine <martin-eric.racine@iki.fi>
Control: affects -1 + src:rescue
Hi,
[ Reason ]
Please take the following with a grain of salt, I don't have first-hand
knowledge about FS-specific things… Btrfs provides a lot of features and
is not just “yet-another-FS”. That means having to make design choices
regarding its integration into an installation system, and those design
choices have evolved over time.
During the trixie release cycle, the installer's “rescue mode” received
support for a number of scenarios, covering the default layouts used in
various Debian Installer and also Debian Live installations. We've had
requests early on to have that made available in bookworm as well, and
given the following that didn't seem unreasonable:
- rescue mode is not in the critical installation path (it's even a
different path that one has to pick at the bootloader stage…);
- the changes are very much focus on a single instruction.
[ Impact ]
Users would have to know about the limitations of this and that specific
Debian releases when it comes to rescue mode, and pick the right one
(which would be trixie+ in that case). In my eyes, the installer's
rescue mode is nice if it works (since there's some nice integration and
some specific gameplans, like fixing bootloader stuff), but it's not top
priority.
[ Tests ]
I've tested the proposed package with a custom netinst ISO, first
breaking a system of mine (using good ol' ext4), then rescuing it with
that ISO. Martin-Éric Racine (who requested the backport) confirmed one
of the three supported scenarios. Pascal Hambourg (who coauthored those
changes) tested all three supported scenarios.
[ Risks ]
Non critical code path (outside the actual installation), targeted fix
(trying alternative, more specific mount instructions if relevant,
keeping the existing, generic one, as the fallback)… this seems rather
safe to me.
Also, that's a source package that only builds udebs.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Initially we have a simple `mount` call without any options for the root
filesystem.
Now, if and only if btrfs is detected, we try 3 sets of options and we
fall back to the simple mount call. Comments were added to remember:
# Try the most plausible case first, then try more setups we know about:
# - subvol=@rootfs used by Debian >=11, via d-i
# - subvol=@ used by Debian Live, via Calamares
# - subvolid=5 used by Debian <=10, via d-i
Thanks for your time!
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru rescue-1.93/debian/changelog rescue-1.93+deb12u1/debian/changelog
--- rescue-1.93/debian/changelog 2023-05-23 19:16:40.000000000 +0200
+++ rescue-1.93+deb12u1/debian/changelog 2025-12-27 23:27:48.000000000 +0100
@@ -1,3 +1,23 @@
+rescue (1.93+deb12u1) bookworm; urgency=medium
+
+ [ Pascal Hambourg and Nicholas D Steeves ]
+ * Add preliminary support for rescuing Debian installed to a btrfs
+ subvolume (Closes: #1018894, #1103476). Supported rescue cases are:
+ 1. The default installation to @rootfs (bullseye and later)
+ 2. The default installation to subvolid=5 (buster or earlier).
+ "subvolid=5" was chosen over "subvol=/" for maximum disambiguation.
+
+ [ Pascal Hambourg ]
+ * Add support for rescuing btrfs systems installed via the Calamares
+ installer found on Debian Live images: it uses subvol=@ (instead of
+ subvol=@rootfs as seen with debian-installer).
+
+ [ Cyril Brulebois ]
+ * Cherry-pick the first part from the 1.100 and 1.102 uploads.
+ * Cherry-pick the second part from the 1.103 upload.
+
+ -- Cyril Brulebois <kibi@debian.org> Sat, 27 Dec 2025 23:27:48 +0100
+
rescue (1.93) unstable; urgency=medium
* Team upload.
diff -Nru rescue-1.93/debian/rescue-mode.postinst rescue-1.93+deb12u1/debian/rescue-mode.postinst
--- rescue-1.93/debian/rescue-mode.postinst 2023-01-08 19:35:25.000000000 +0100
+++ rescue-1.93+deb12u1/debian/rescue-mode.postinst 2025-12-27 06:33:33.000000000 +0100
@@ -189,7 +189,15 @@
mkdir -p /target
umount_all
- if ! log-output -t rescue mount "$RESCUE_ROOTDEV" /target; then
+ # Try the most plausible case first, then try more setups we know about:
+ # - subvol=@rootfs used by Debian >=11, via d-i
+ # - subvol=@ used by Debian Live, via Calamares
+ # - subvolid=5 used by Debian <=10, via d-i
+ if ! { [ "$(blkid -s TYPE -o value "$RESCUE_ROOTDEV")" = btrfs ] && \
+ { log-output -t rescue mount -t btrfs -o subvol=@rootfs "$RESCUE_ROOTDEV" /target || \
+ log-output -t rescue mount -t btrfs -o subvol=@ "$RESCUE_ROOTDEV" /target || \
+ log-output -t rescue mount -t btrfs -o subvolid=5 "$RESCUE_ROOTDEV" /target; }; } && \
+ ! log-output -t rescue mount "$RESCUE_ROOTDEV" /target; then
log "mount '$RESCUE_ROOTDEV' /target failed"
db_subst rescue/mount-failed DEVICE "$RESCUE_ROOTDEV"
db_input critical rescue/mount-failed
Reply to: