Your message dated Thu, 20 Jul 2023 03:53:39 +0200
with message-id
<ljnp4dhpnniirgg2hkqgwqnzja53e3bqbeiuttkvvv7mpr5fie@5sazv2gw7thk>
and subject line Re: Bug#1032355: systemd-boot: bootctl install/update
completely broken with /boot on ZFS
has caused the Debian Bug report #1032355,
regarding systemd-boot: bootctl install/update completely broken with /boot on
ZFS
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1032355: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032355
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd-boot
Version: 252.6-1
Severity: important
Tags: patch upstream
Control: forwarded -1 https://github.com/systemd/systemd/pull/26660
Dear Maintainer,
I already forwarded this upstream, but I found this in Debian and I have
a patch that works for 252.6-1, so I'm hoping this can land for
bookworm.
In short, when updating sd-boot:
dpkg: error processing package systemd-boot (--configure):
installed systemd-boot package post-installation script subprocess
returned error exit status 1
And indeed:
❯ sudo bootctl update --graceful
❯ echo $?
1
With no more information. This is because statx(/boot) (when that's on
ZFS) returns stx_dev_major=0, which forces a "this filesystem is btrfs"
path, which errors out and silently exits 1 when it's actually not.
-- >8 --
$ git diff
diff --git a/src/shared/find-esp.c b/src/shared/find-esp.c
index fa234c8b5f..1af643da5e 100644
--- a/src/shared/find-esp.c
+++ b/src/shared/find-esp.c
@@ -814,7 +814,7 @@ int find_xbootldr_and_warn(
r = verify_xbootldr(p, /* searching= */ true, unprivileged_mode,
ret_uuid, ret_devid);
if (r >= 0)
goto found;
- if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR)) /* This one is not
it */
+ if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR, -ENOTTY)) /* This
one is not it */
return r;
return -ENOKEY;
-- >8 --
This patch, effectively, understands that -ENOTTY means "this is not an
XBOOTLDR partition" and lets the installation progress normally.
Please consider applying this.
наб
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-20-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages systemd-boot depends on:
ii libc6 2.31-13+deb11u5
pn libsystemd-shared <none>
pn systemd-boot-efi <none>
Versions of packages systemd-boot recommends:
ii efibootmgr 17-1
systemd-boot suggests no packages.
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 254~rc2-3
Can confirm 254~rc2-3 from sid (upstream #26660 + #28048) does fix it.
f26c794308975a875a98faf22a6650d7134f17c1 (#28048)
appears to not have been picked up for backport in a timely manner
(but the first, broken, part of the fix (#26660) was),
so I'd opened
https://github.com/systemd/systemd-stable/pull/308
Am I right to trust that if a stable v252.x tag is released
with this commit in it, it will make its way to bullseye-p-u?
Best,
наб
signature.asc
Description: PGP signature
--- End Message ---
