Bug#1069410: efitools: FTBFS on arm64: make[1]: *** [Make.rules:130: HelloWorld-signed.efi] Error 1
Control: tags -1 +confirmed On Sat, Apr 20, 2024 at 02:01:48PM +0200, Lucas Nussbaum wrote: >Source: efitools >Version: 1.9.2-3 >Severity: serious >Justification: FTBFS >Tags: trixie sid ftbfs >User: lu...@debian.org >Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64 > >Hi, > >During a rebuild of all packages in sid, your package failed to build >on arm64. ... >> Signature at: 40 >> sbsign --key DB.key --cert DB.crt --output HelloWorld-signed.efi >> HelloWorld.efi >> ./cert-to-efi-sig-list -g ----123456789abc PK.crt PK.esl >> Invalid DOS header magic >> make[1]: *** [Make.rules:130: HelloWorld-signed.efi] Error 1 I can reproduce this here. The HelloWorld.efi binary seems to be totally malformed. Digging further... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1059007: python-asyncssh: CVE-2023-48795
Hi!
On Tue, Dec 19, 2023 at 09:31:00AM +0100, Salvatore Bonaccorso wrote:
>Source: python-asyncssh
>Version: 2.10.1-2
>Severity: important
>Tags: security upstream
>X-Debbugs-Cc: car...@debian.org, Debian Security Team
>
>
>Hi,
>
>The following vulnerability was published for python-asyncssh.
>
>CVE-2023-48795[0]:
>| The SSH transport protocol with certain OpenSSH extensions, found in
>| OpenSSH before 9.6 and other products, allows remote attackers to
>| bypass integrity checks such that some packets are omitted (from the
>| extension negotiation message), and a client and server may
>| consequently end up with a connection for which some security
>| features have been downgraded or disabled, aka a Terrapin attack.
>| This occurs because the SSH Binary Packet Protocol (BPP),
>| implemented by these extensions, mishandles the handshake phase and
>| mishandles use of sequence numbers. For example, there is an
>| effective attack against SSH's use of ChaCha20-Poly1305 (and CBC
>| with Encrypt-then-MAC). The bypass occurs in
>| chacha20-poly1...@openssh.com and (if CBC is used) the
>| -e...@openssh.com MAC algorithms. This also affects Maverick Synergy
>| Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh
>| before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before
>| 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, and
>| libssh2 through 1.11.0; and there could be effects on Bitvise SSH
>| through 9.31.
We wanted this fixed in Pexip, so I've taken a look at this bug.
The upstream bugfix just needs a small rework so it applies cleanly to
the version in bookworm. Here's a debdiff for that that in case it's
useful.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
diff -Nru python-asyncssh-2.10.1/debian/changelog
python-asyncssh-2.10.1/debian/changelog
--- python-asyncssh-2.10.1/debian/changelog 2022-12-22 03:54:16.0
+
+++ python-asyncssh-2.10.1/debian/changelog 2024-04-29 11:45:47.0
+0100
@@ -1,3 +1,11 @@
+python-asyncssh (2.10.1-2+deb12u1) bookworm; urgency=medium
+
+ * Apply and tweak upstream security fix for CVE-2023-48795
+Implement "strict kex" support to harden AsyncSSH against Terrapin
+Attack. Closes: #1059007
+
+ -- Steve McIntyre Mon, 29 Apr 2024 11:45:47 +0100
+
python-asyncssh (2.10.1-2) unstable; urgency=medium
* Team Upload.
diff -Nru python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch
python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch
--- python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch 1970-01-01
01:00:00.0 +0100
+++ python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch 2024-04-29
11:45:47.0 +0100
@@ -0,0 +1,382 @@
+commit 0bc73254f41acb140187e0c89606311f88de5b7b
+Author: Ron Frederick
+Date: Mon Dec 18 07:41:57 2023 -0800
+
+Implement "strict kex" support to harden AsyncSSH against Terrapin Attack
+
+This commit implements "strict kex" support and other countermeasures to
+protect against the Terrapin Attack described in CVE-2023-48795. Thanks
+once again go to Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk for
+identifying and reporting this vulnerability and providing detailed
+analysis and suggestions about proposed fixes.
+
+Index: b/asyncssh/connection.py
+===
+--- a/asyncssh/connection.py
b/asyncssh/connection.py
+@@ -810,6 +810,7 @@ class SSHConnection(SSHPacketHandler, as
+ self._kexinit_sent = False
+ self._kex_complete = False
+ self._ignore_first_kex = False
++self._strict_kex = False
+
+ self._gss: Optional[GSSBase] = None
+ self._gss_kex = False
+@@ -1343,10 +1344,13 @@ class SSHConnection(SSHPacketHandler, as
+ (alg_type, b','.join(local_algs).decode('ascii'),
+ b','.join(remote_algs).decode('ascii')))
+
+-def _get_ext_info_kex_alg(self) -> List[bytes]:
+-"""Return the kex alg to add if any to request extension info"""
++def _get_extra_kex_algs(self) -> List[bytes]:
++"""Return the extra kex algs to add"""
+
+-return [b'ext-info-c' if self.is_client() else b'ext-info-s']
++if self.is_client():
++return [b'ext-info-c', b'kex-strict-c-...@openssh.com']
++else:
++return [b'ext-info-s', b'kex-strict-s-...@openssh.com']
+
+ def _send(self, data: bytes) -> None:
+ """Send data to the SSH connection"""
+@@ -1487,6 +1491,11 @@ class SSHConnection(SSHPacketHandler, as
+ self._ignore_first_kex = False
+ else:
+ handler = se
Bug#1066684: xpat2: FTBFS: loadsave.c:279:24: error: implicit declaration of function ‘cuserid’ [-Werror=implicit-function-declaration]
Here's an NMU diff that fixes the FTBFS. In incoming right now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross diff -Nru xpat2-1.07/debian/changelog xpat2-1.07/debian/changelog --- xpat2-1.07/debian/changelog 2016-11-02 10:32:41.0 + +++ xpat2-1.07/debian/changelog 2024-04-18 21:21:46.0 + @@ -1,3 +1,10 @@ +xpat2 (1.07-20+nmu1) unstable; urgency=medium + + * NMU + * Fix FTBFS for implicit declaration(s). Closes: #1066684 + + -- Steve McIntyre <93...@debian.org> Thu, 18 Apr 2024 22:21:46 +0100 + xpat2 (1.07-20) unstable; urgency=medium * maintainer address change diff -Nru xpat2-1.07/debian/patches/fix-implicit-declarations.diff xpat2-1.07/debian/patches/fix-implicit-declarations.diff --- xpat2-1.07/debian/patches/fix-implicit-declarations.diff1970-01-01 00:00:00.0 + +++ xpat2-1.07/debian/patches/fix-implicit-declarations.diff2024-04-18 21:21:46.0 + @@ -0,0 +1,11 @@ +--- xpat2-1.07.orig/src/loadsave.c xpat2-1.07/src/loadsave.c +@@ -26,6 +26,8 @@ + + #include + ++#define NO_CUSERID /* Disable, it's not there */ ++ + #ifndef _POSIX_NAME_MAX + # undef _POSIX_SOURCE/* seems that we have no POSIX system! */ + # define NAME_MAX14 /* every UNIX should have at least this */ diff -Nru xpat2-1.07/debian/patches/series xpat2-1.07/debian/patches/series --- xpat2-1.07/debian/patches/series2016-11-02 09:58:54.0 + +++ xpat2-1.07/debian/patches/series2024-04-18 21:21:46.0 + @@ -4,3 +4,4 @@ localization-improvement icon-removal patch-loadsave.diff +fix-implicit-declarations.diff
Bug#1061519: shim: CVE-2023-40546 CVE-2023-40547 CVE-2023-40548 CVE-2023-40549 CVE-2023-40550 CVE-2023-40551
On Mon, Apr 15, 2024 at 11:33:14AM +, Bastien Roucariès wrote: >Source: shim >Followup-For: Bug #1061519 >Control: tags -1 + patch > >Dear Maintainer, > >Please find a MR here >https://salsa.debian.org/efi-team/shim/-/merge_requests/13 ACK. Thanks for trying to help, but the merge isn't the hard bit here. Tthe new upstream is a little problematic and I'm debugging some boot failures in my local CI already. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#1067054: Debian 12 - Copy files on USB 3
pham...@bluewin.ch wrote: > >For complement of information : >The SSD used is a Samsung 850 Pro 256 GB and the case is a Satechi ST-TCDEM. >Write rates were high at the start of the copy (450 MB/sec then dropped before >the crash to +/- 30 Mb/sec). > > > Restoring the disk image with this same SSD but integrated in a Delock USB 3 > Type A case to a USB A socket on my computer works correctly with a transfer >rate of 60 to 90 MB/s. > > >The same SSD still plugged into the Delock USB 3 Type A box but connected to >my machine on a USB C port completes the restoration of the image with a >constant >transfer rate of +/- 41MB/sec. >Regards. What you're describing sounds just as likely to be a hardware problem with the enclosure, to be honest. Does it work 100% reliably elsewhere? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Bug#1066237: nas: FTBFS: main.c:125:9: error: implicit declaration of function ‘yyparse’ [-Werror=implicit-function-declaration]
On Wed, Mar 13, 2024 at 12:42:56PM +0100, Lucas Nussbaum wrote: >Source: nas >Version: 1.9.4-7 >Severity: serious >Justification: FTBFS >Tags: trixie sid ftbfs >User: lu...@debian.org >Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef Thanks for the report! Nas contains some really awful old C code, and it's taking a bit of fixing. But I'm getting there... -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1066264: cdrkit: diff for NMU version 9:1.1.11-3.5
Thanks! If you think this is a good bugfix, please go ahead and upload straight to unstable. On Thu, Mar 14, 2024 at 09:55:13PM +0500, Andrey Rakhmatullin wrote: >Control: tags 1066264 + patch >Control: tags 1066264 + pending > >Dear maintainer, > >I've prepared an NMU for cdrkit (versioned as 9:1.1.11-3.5) and >uploaded it to DELAYED/4. Please feel free to tell me if I >should delay it longer. > >Regards. > > >-- >WBR, wRAR >diff -Nru cdrkit-1.1.11/debian/changelog cdrkit-1.1.11/debian/changelog >--- cdrkit-1.1.11/debian/changelog 2022-06-24 19:56:39.0 +0500 >+++ cdrkit-1.1.11/debian/changelog 2024-03-14 21:53:13.0 +0500 >@@ -1,3 +1,10 @@ >+cdrkit (9:1.1.11-3.5) unstable; urgency=medium >+ >+ * Non-maintainer upload. >+ * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066264). >+ >+ -- Andrey Rakhmatullin Thu, 14 Mar 2024 21:53:13 +0500 >+ > cdrkit (9:1.1.11-3.4) unstable; urgency=low > > * Non-maintainer upload. >diff -Nru cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch >cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch >--- cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch >1970-01-01 05:00:00.0 +0500 >+++ cdrkit-1.1.11/debian/patches/fix-implicit-function-declaration.patch >2024-03-14 21:50:53.0 +0500 >@@ -0,0 +1,29 @@ >+Description: Add missing header includes. >+Author: Andrey Rakhmatullin >+Bug-Debian: https://bugs.debian.org/1066264 >+Last-Update: 2024-03-14 >+ >+Index: cdrkit-1.1.11/genisoimage/genisoimage.c >+=== >+--- cdrkit-1.1.11.orig/genisoimage/genisoimage.c > cdrkit-1.1.11/genisoimage/genisoimage.c >+@@ -54,6 +54,7 @@ >+ #include >+ #include "match.h" >+ #include "exclude.h" >++#include "checksum.h" >+ #include /* For UNICODE translation */ >+ #include >+ #ifdef UDF >+Index: cdrkit-1.1.11/genisoimage/jte.c >+=== >+--- cdrkit-1.1.11.orig/genisoimage/jte.c > cdrkit-1.1.11/genisoimage/jte.c >+@@ -27,6 +27,7 @@ >+ #include "ifo_read.h" >+ #include "endianconv.h" >+ #include "checksum.h" >++#include "md5.h" >+ #endif >+ #ifdef APPLE_HYB >+ #include >diff -Nru cdrkit-1.1.11/debian/patches/series >cdrkit-1.1.11/debian/patches/series >--- cdrkit-1.1.11/debian/patches/series2022-05-25 07:57:10.0 >+0500 >+++ cdrkit-1.1.11/debian/patches/series2024-03-14 21:48:02.0 >+0500 >@@ -4,3 +4,4 @@ > add-efi-boot.patch > gcc10.patch > fix_format-security.patch >+fix-implicit-function-declaration.patch -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Bug#1057606: shim: FTBFS: ./debian/generate_dbx_list: 23: efisiglist: not found
Control: tag -1 pending On Tue, Dec 05, 2023 at 11:11:17PM +0100, Santiago Vila wrote: >Package: src:shim >Version: 15.7-1 >Severity: serious >Tags: ftbfs > >Dear maintainer: > >During a rebuild of all packages in unstable, your package failed to build: > > >[...] > debian/rules build >dh build > dh_update_autotools_config > dh_autoreconf > dh_auto_configure > debian/rules override_dh_auto_build >make[1]: Entering directory '/<>' >./debian/generate_dbx_list x64 debian/debian-dbx.hashes dbx.esl > Adding 000f1547bb113601d65df9cb74ac62dd6d2ca85a0c2bb375c2f0ecedb59c84a4 to > dbx list >./debian/generate_dbx_list: 23: efisiglist: not found >make[1]: *** [debian/rules:52: dbx.esl] Error 127 >make[1]: Leaving directory '/<>' >make: *** [debian/rules:64: build] Error 2 >dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > > >The above is just how the build ends and not necessarily the most relevant >part. >If required, the full build log is available here: ACK, this is already known about. The pesign package no longer provides efisiglist in unstable. I already have the necessary changes made in shim in git, and we're due a new upload soon-ish. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Bug#1056348: FTBFS: tests fail in clean environment
Hey Nicolas! On Fri, Nov 24, 2023 at 11:26:25AM -0500, Nicolas Mora wrote: >Hello, > >I've forwarded the bug upstream [1] and they made a patch [2]. > >Can you test their patch on your package, to check if the problem is fixed on >your CI? > >Also, if this works, I suggest to apply their patch rather than yours to make >the code more consistent with upstream, do you agree? > >[1] https://github.com/libssh2/libssh2/issues/1240 >[2] https://github.com/libssh2/libssh2/pull/1241 Thanks, that looks sane enough here! :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#1056348: FTBFS: tests fail in clean environment
On Thu, Nov 23, 2023 at 10:46:34AM -0500, Nicolas Mora wrote: >Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit : >> >> Ah, apologies - that version is bogus, it's just the version on the >> bullseye machine I ran reportbug from. >> >> The tests are failing on current unstable source. >> > >OK, makes more sense then. > >Nevertheless I'm wondering about the seriousness of the bug, I can't >reproduce on my environment and all the buildd environments where libssh2 is >built don't have the problem. AFAICS in a non-interactive environment, USER isn't required to be set but LOGNAME is; see https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Alternatively, the tets should probably be calling get(e)uid and getpwent() rather than relying on the environment here. >Could your issue be fixed by running something like this? >USER=$LOGNAME dpkg-buiildpackage > >I'm just wondering if the patch is worth applying it to fix a less probable >case. The tests failed in a CI system we use at work, so I needed to fix it there. The patch just adds fallback here, and makes things more robust. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#1056348: FTBFS: tests fail in clean environment
On Thu, Nov 23, 2023 at 09:20:37AM -0500, Nicolas Mora wrote: >Hello, > >On Tue, 21 Nov 2023 13:30:31 +0000 Steve McIntyre wrote: >> Source: libssh2 >> Version: 1.9.0-2 >> Severity: serious >> Tags: ftbfs patch >> >> Hi! >> >> Building libssh2 using debuild in a clean local chroot, I get test >> failures and even a core dump! >> >Thanks for reporting the bug, although I have concerns on its scope. > >The package you have found the issue is the bullseye one, and the package >updates for oldstable are allowed mostly for security patches. > >Your bug is related to the test suite, and the patch won't change the binary >files in the package, so I assume the patch isn't going to be allowed for >proposed-updates. > >I've added the release team to ask for their opinion. > >Friends from the release team, do you have a feedback on this? Ah, apologies - that version is bogus, it's just the version on the bullseye machine I ran reportbug from. The tests are failing on current unstable source. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1056348: FTBFS: tests fail in clean environment
Source: libssh2
Version: 1.9.0-2
Severity: serious
Tags: ftbfs patch
Hi!
Building libssh2 using debuild in a clean local chroot, I get test
failures and even a core dump!
...
PASS: mansyntax.sh
PASS: test_simple
FAIL: test_sshd.test 1 - sshd-test_ssh2
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519
=
libssh2 -: tests/test-suite.log
=
# TOTAL: 4
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: test_sshd
===
Fingerprint: 12 FD AD 1E 3B 31 B1 0B AB B0 0F 2A 8D 1B 9A 62 C3 26 BD 2F
Authentication methods: publickey,password,keyboard-interactive
Authentication by public key failed!
all done
./test_sshd.test: line 131: 2476672 Segmentation fault (core dumped)
"${test}"
# sshd executable: '/usr/sbin/sshd' (OpenSSH_9.4, OpenSSL 3.0.12 24 Oct 2023)
# ssh executable: '/usr/bin/ssh' (OpenSSH_9.4p1 Debian-1, OpenSSL 3.0.12 24 Oct
2023)
1..2
not ok 1 - sshd-test_ssh2
FAIL: test_sshd.test 1 - sshd-test_ssh2
not ok 2 - sshd-test_auth_pubkey_ok_ed25519
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519
Testsuite summary for libssh2 -
# TOTAL: 4
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
These are both down to environment: the test code assumes that "USER"
is a valid environment varliable, which is not necessarily
true. Here's a patch which fixes this for these two tests, and fails
cleanly with diagnostics if there's a problem.
-- System Information:
Debian Release: 11.8
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldoldstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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
diff --git a/tests/session_fixture.c b/tests/session_fixture.c
index 3bb9da2..4671117 100644
--- a/tests/session_fixture.c
+++ b/tests/session_fixture.c
@@ -430,11 +430,18 @@ int test_auth_pubkey(LIBSSH2_SESSION *session, int flags,
/* Ignore our hard-wired Dockerfile user when not running under Docker */
if(!openssh_fixture_have_docker() && strcmp(username, "libssh2") == 0) {
-username = getenv("USER");
+if(getenv("USER"))
+username = getenv("USER");
+else if(getenv("LOGNAME"))
+username = getenv("LOGNAME");
#ifdef WIN32
-if(!username)
+else if(getenv("USERNAME"))
username = getenv("USERNAME");
#endif
+else {
+fprintf(stderr, "Failed to find a username from env\n");
+return 1;
+}
}
userauth_list = libssh2_userauth_list(session, username,
diff --git a/tests/test_ssh2.c b/tests/test_ssh2.c
index a637cdc..6e28598 100644
--- a/tests/test_ssh2.c
+++ b/tests/test_ssh2.c
@@ -63,10 +63,16 @@ int main(int argc, char *argv[])
if(getenv("USER"))
username = getenv("USER");
+else if(getenv("LOGNAME"))
+username = getenv("LOGNAME");
#ifdef WIN32
else if(getenv("USERNAME"))
username = getenv("USERNAME");
#endif
+else {
+fprintf(stderr, "Failed to find a username from env\n");
+return 1;
+}
if(getenv("PRIVKEY"))
privkey = getenv("PRIVKEY");
Bug#1054449: pesign: Missing Depends on passwd
On Sun, Nov 12, 2023 at 10:16:01PM +0100, Santiago Vila wrote: >found 1054449 116-1 >found 1054449 116-5 >affects 1054449 src:shim >thanks > >Hi. In commit e38e2a8af632a660d3c01a936796622fce186020 >it looks that you added passwd to the Build-Depends. > >The bug (after preinst moved to postinst) was about adding it >to the Depends field. > >In fact, the changelog was correct for what it had to be done, >just not for what it was actually done. > >(note: shim FTBFS in a clean chroot because of this bug) Oh, gah. :-/ Thanks for the prod, fixing now! -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:
>Hi Michael,
>
>Cyril Brulebois (2023-06-28):
>> Control: reassign -1 busybox-udeb 1:1.36.1-3
>
>[…]
>
>> With a local build, confirmed -3 is buggy, and that reverting only
>> busybox-udeb to -1 is sufficient to restore syslog support in the
>> installer.
>>
>> Reassigning there; the GRUB thing can be filed separately once we have
>> actual information via syslog.
>
>A fix would be appreciated, we've got reports piling up about things we
>have no logs for.
After weeks with this breakage, I've just uploaded a minimal NMU to
fix it, reverting the syslog changes since -1. I've buit and tested
successfully locally.
Here's the NMU diff.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
diff -Nru busybox-1.36.1/debian/changelog busybox-1.36.1/debian/changelog
--- busybox-1.36.1/debian/changelog 2023-06-14 22:01:54.0 +0100
+++ busybox-1.36.1/debian/changelog 2023-08-03 21:22:44.0 +0100
@@ -1,3 +1,11 @@
+busybox (1:1.36.1-3.1) unstable; urgency=medium
+
+ * NMU
+ * Revert recent changes that have broken syslogd in d-i.
+Closes: #1039710
+
+ -- Steve McIntyre <93...@debian.org> Thu, 03 Aug 2023 21:22:44 +0100
+
busybox (1:1.36.1-3) unstable; urgency=medium
* syslogd-avoid-nulling-devlog.patch - fix overriding dev/log
diff -Nru busybox-1.36.1/debian/patches/series
busybox-1.36.1/debian/patches/series
--- busybox-1.36.1/debian/patches/series2023-06-14 21:55:08.0
+0100
+++ busybox-1.36.1/debian/patches/series2023-08-03 21:22:44.0
+0100
@@ -14,6 +14,7 @@
platform-linux.diff
fix-non-linux-build.patch
#
-syslogd-decrease-stack-usage-50-bytes.patch
-syslogd-daemonize-after-init-make-errs-visible.patch
-syslogd-avoid-nulling-devlog.patch
+syslogd-fork-after-init-not-before.patch
+#syslogd-decrease-stack-usage-50-bytes.patch
+#syslogd-daemonize-after-init-make-errs-visible.patch
+#syslogd-avoid-nulling-devlog.patch
diff -Nru
busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
--- busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
1970-01-01 01:00:00.0 +0100
+++ busybox-1.36.1/debian/patches/syslogd-fork-after-init-not-before.patch
2023-08-03 21:22:44.0 +0100
@@ -0,0 +1,58 @@
+From: Michael Tokarev
+Date: Tue, 6 Jun 2023 17:08:18 +0300
+Subject: [PATCH] syslogd: fork after init on a regular system, not before
+
+Current syslogd performs all init after daemonizing, meanwhile
+main process exits successfully. This means any errors during init
+will not be even shown up because at this time the process has its
+stderr redirected to /dev/null already.
+
+On a MMU system, delay daemonizing to after init.
+On non-MMU system, keep current code.
+
+Signed-off-by: Michael Tokarev
+---
+ sysklogd/syslogd.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/sysklogd/syslogd.c b/sysklogd/syslogd.c
+index 6ddfd771a..2f9a727cd 100644
+--- a/sysklogd/syslogd.c
b/sysklogd/syslogd.c
+@@ -1025,7 +1025,6 @@ static void do_syslogd(void)
+ signal(SIGALRM, do_mark);
+ alarm(G.markInterval);
+ #endif
+- xmove_fd(create_socket(), STDIN_FILENO);
+
+ if (option_mask32 & OPT_circularlog)
+ ipcsyslog_init();
+@@ -1033,6 +1032,16 @@ static void do_syslogd(void)
+ if (option_mask32 & OPT_kmsg)
+ kmsg_init();
+
++ {
++ int fd = create_socket();
++#if BB_MMU
++ if (!(option_mask32 & OPT_nofork)) {
++ bb_daemonize(DAEMON_CHDIR_ROOT);
++ }
++#endif
++ xmove_fd(fd, STDIN_FILENO);
++ }
++
+ timestamp_and_log_internal("syslogd started: BusyBox v" BB_VER);
+ write_pidfile_std_path_and_ext("syslogd");
+
+@@ -1179,9 +1188,11 @@ int syslogd_main(int argc UNUSED_PARAM, char **argv)
+ G.hostname = safe_gethostname();
+ *strchrnul(G.hostname, '.') = '\0';
+
++#if !BB_MMU
+ if (!(opts & OPT_nofork)) {
+ bb_daemonize_or_rexec(DAEMON_CHDIR_ROOT, argv);
+ }
++#endif
+
+ do_syslogd();
+ /* return EXIT_SUCCESS; */
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
On Tue, Jul 11, 2023 at 02:20:32PM +0100, Luca Boccassi wrote: >On Tue, 11 Jul 2023 at 14:14, Simon McVittie wrote: >> >> Of course, d-i doesn't provide a way to not install systemd-sysv, but >> a vocal minority of users and developers use non-default installation >> mechanisms to get a different init system and consider that to be >> a critically important use-case; and I'm concerned that even if these >> users got a machine ID generated during installation, they would delete >> it as a perceived systemd'ism, and then complain loudly in the form of >> RC bugs when D-Bus doesn't work because /var/lib/dbus/machine-id is now >> a dangling symlink. > >Well, I don't think we should make the 99.5% of cases more fragile to >cater to an entirely hypothetical 0.5% that would actively damage >their own installation by deleting OS files for no good reason. If >someone wants to mess manually with /etc/machine-id and >/var/lib/dbus/machine-id it's fair that they are allowed to do that, >but it's also fair to tell them that they get to keep the pieces. Agreed, 100%. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation
Hi, and thanks for your bug report! On Mon, Jul 10, 2023 at 05:27:50PM +0200, yogg wrote: >Package: installation-reports >Severity: serious >Tags: d-i >Justification: https://wiki.debian.org/MachineId > ... >After installation was finished and the system has been restarted the >files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked >in any way (no soft or hardlink) and the ID inside the files differ >from each other. I've confirmed this bug just now, doing a clean installation from the 12.0.0 amd64 netinst. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#1032186: Further patch to improve things?
Hey,
The first patch committed here allows people to uninstall
raspi-firmware more easily. I suggest the attached to make things
easier for people even before that removal...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Getting a SCSI chain working is perfectly simple if you remember that there
must be exactly three terminations: one on one end of the cable, one on the
far end, and the goat, terminated over the SCSI chain with a silver-handled
knife whilst burning *black* candles. --- Anthony DeBoer
>From 75142eda35e6554d6f40ee2501e9cef1607a6f06 Mon Sep 17 00:00:00 2001
From: Steve McIntyre
Date: Sun, 9 Jul 2023 20:29:51 +0100
Subject: [PATCH] Don't attempt to do anything with /boot/firmware unless we're
running on an arm-based system. #1032186 again.
---
debian/kernel/postinst.d/z50-raspi-firmware | 14 ++
debian/raspi-firmware.postinst | 15 +++
2 files changed, 29 insertions(+)
diff --git a/debian/kernel/postinst.d/z50-raspi-firmware b/debian/kernel/postinst.d/z50-raspi-firmware
index 9b3bfa5..b4a2d75 100755
--- a/debian/kernel/postinst.d/z50-raspi-firmware
+++ b/debian/kernel/postinst.d/z50-raspi-firmware
@@ -27,11 +27,25 @@ pi_4_family() {
grep -q 'Raspberry Pi \(Compute Module \)*4' /sys/firmware/devicetree/base/model 2>/dev/null
}
+is_arm_system() {
+ # Check to see if the host is running an arm-based system
+ # (i.e. whether the raspi-firmware package is useful)
+ DPKG_ARCH=$(dpkg-architecture -q DEB_TARGET_ARCH)
+ case "$DPKG_ARCH" in
+arm64|armel|armhf)
+ return 0;;
+*)
+ return 1;;
+ esac
+}
if ischroot ; then
true # chroot detected - skip mount point check
elif [ -e /usr/bin/systemd-detect-virt ] && systemd-detect-virt -q ; then
true # virtualization detected - skip mount point check
+elif ! is_arm_system ; then
+ echo "$0: Not running on an arm-based system, doing nothing"
+ exit 0
elif ! mountpoint -q /boot/firmware ; then
echo "raspi-firmware: missing /boot/firmware, did you forget to mount it?" >&2
exit 1
diff --git a/debian/raspi-firmware.postinst b/debian/raspi-firmware.postinst
index 8ecc5f3..22e86d3 100644
--- a/debian/raspi-firmware.postinst
+++ b/debian/raspi-firmware.postinst
@@ -3,6 +3,18 @@
set -e
+is_arm_system() {
+ # Check to see if the host is running an arm-based system
+ # (i.e. whether the raspi-firmware package is useful)
+ DPKG_ARCH=$(dpkg-architecture -q DEB_TARGET_ARCH)
+ case "$DPKG_ARCH" in
+arm64|armel|armhf)
+ return 0;;
+*)
+ return 1;;
+ esac
+}
+
case "$1" in
configure)
@@ -10,6 +22,9 @@ case "$1" in
true # chroot detected - skip mount point check
elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
true # virtualization detected - skip mount point check
+elif ! is_arm_system ; then
+ echo "$0: Not running on an arm-based system, doing nothing"
+ exit 0
elif ! mountpoint -q /boot/firmware; then
echo "Error: missing /boot/firmware, did you forget to mount it?" >&2
exit 1
--
2.30.2
Bug#1035382: Bug#1032071: ARM firmware packages included in amd64 installation images
Control: severity 1035382 grave On Thu, Jul 06, 2023 at 06:29:49PM +0200, Magnus Wallin wrote: > >Hi Magnus, and thanks for the heads-up > >[ . . . ] > >Just because the raspi-firmware package is included on the d-i >installation media, it shouldn't necessarily be installed on an amd64 >host. Or is this coming from live images? > >Hi Steve! > >Speaking for myself: I installed from a live image on the release day of Debian >12. OK, that explains it. Let's try to get this fixed before 12.1... I can see that there is already #1035382 open on the live side, let's bump the severity on that. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Bug#1034610: grub-common no longer supports labels
Control: severity -1 important Hi! On Wed, Apr 19, 2023 at 02:52:31PM -0300, Dario Susman wrote: >Package: grub-common >Version: 2.06-8 >Severity: critical >Justification: breaks the whole system > >Dear Maintainer, > >After upgrading to latest version of grub-common and kernel, the system >wouldn't boot up with the latest kernel. The device paths changed, sda1 >to sdb1. I noticed that the grub config changed to use UUIDs, however >/etc/default/grub is set to use LABELS. Which is something I prefer to >do. > >It seems that grub-mkinfo no longer supports the GRUB_ENABLE_LINUX_LABEL >parameters and has to be re-written for it to work. Looking in the history, I can't see where we've ever supported this. Can you tell me which version(s) ever had this working for you please? -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Bug#1033913: partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in UEFI mode
I've just pushed an update to the code here... On Mon, Apr 10, 2023 at 05:45:15PM +0200, Pascal Hambourg wrote: >On 10/04/2023 at 15:13, Steve McIntyre wrote: >> >> Overall comment: I'm not trying to make the heuristics 100% reliable >> here, as I don't think that's actually possible. Instead, I'm trying >> to tread the fine line of: >> >> * minimising false negatives - let's try to pick up on the most >> common cases where people are dual-booting with other systems and >> might not understand the issues here. That's 99%+ going to be >> people with Windows installed >> >> * minimising false positives - the issue that angered Cyril in >> particular, with an incomplete LVM setup triggering the "bios >> bootable OS" warning > >IMO it is more important to avoid false positives, because switching to a >BIOS installation on systems which are not BIOS-boot capable would create a >non bootable system. In case oft is easier to install GRUB for BIOS boot on >an running EFI system than the other way around. No. The reason I added this check and warning in the first place is to avoid breaking existing (all-too-common) systems where Windows users have a BIOS-booting installation but their BIOS is set to boot both UEFI and BIOS. That's a stupid combination, but again all too common. :-( New users who are just trying to install Debian dual-boot are much less likely to be able to diagnose this kind of problem. >> > - Other BIOS boot loaders such as syslinux/extlinux do not need or use a >> > BIOS >> > boot partition. >> >> Also not a use case I'm particularly caring about, I'll be >> honest. They're also *really* not likely to work well without another >> filesystem in use, which I expect we'll detect anyway. > >Indeed other partitions are needed and will be detected, but they will not >increment $NUM_NOT_ESP if the disk is GPT and has no BIOS boot partition (so >$DISK_BIOS_BOOT=no), so it might cause a false negative. So why not just >treat MSDOS and GPT disk labels equally and treat BIOS boot partitions like >any other non-ESP ? It's a false negative that I really don't believe or care about very much, I'll be honest. This is getting to be an edge case on an edge case. >> > 1b) IIUC the patch fixes #1033913 because the disk selected for >> > installation >> > has received a new GPT disklabel without a BIOS boot partition, so further >> > checking is skipped. But IMO the root cause of #1033913 is that changes are >> > not committed to disk after setting the 'boot' and 'esp' flags to the newly >> > created ESP partition before stopping parted_server. > >I originally thought about fixing partman-auto-lvm but it appears that other >transient states can also trigger the "force UEFI installation" dialog during >partitioning, for example after setting up LVM in manual partitioning if >there is no ESP partition yet. As discussed in #debian-boot, a more general >fix might be to run the check only once because only existing partitions >before partitioning are relevant. Are there any use cases for which this >might cause a false negative ? So I've now modded the code to add a flag file - it'll only run the check and (maybe) raise the warning on the first entry into partman. Thanks for the suggection, this is clearly the correct answer. >> > 4) It appears that partman fails to detect the specially crafted partition >> > table on the installation media created with a debian image. Is it intended >> > or fortunately unintentional ? If partman could see the EFI partition on >> > the >> > installation media, the detection of BIOS-bootable systems would fail. >> >> That's not a worry for today... :-) > >Sure, but the issue can also happen if another removable media is present. >For instance the USB drive I use to provide missing firmware has an ESP >partition (and a regular partition table) thus can cause a false negative. Again, we're hitting edge cases. We can't know for sure what the user wants here, so we can't just ignore removable media (for example). -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Bug#1033913: partman-auto-lvm: Broken "Guided - use entire disk and set up LVM" in UEFI mode
Hey Pascal, and thanks for the review! Overall comment: I'm not trying to make the heuristics 100% reliable here, as I don't think that's actually possible. Instead, I'm trying to tread the fine line of: * minimising false negatives - let's try to pick up on the most common cases where people are dual-booting with other systems and might not understand the issues here. That's 99%+ going to be people with Windows installed * minimising false positives - the issue that angered Cyril in particular, with an incomplete LVM setup triggering the "bios bootable OS" warning On Mon, Apr 10, 2023 at 01:01:01PM +0200, Pascal Hambourg wrote: >partman-efi "Fix detection of BIOS-bootable systems" provides a significant >improvement over previous behaviour. However I have a few comments. > >1a) The patch assumes that a GPT disk may be BIOS-bootable only if it has a >BIOS boot partition. But a GPT disk can be BIOS-bootable even without a BIOS >boot partition: >- GRUB may be installed without a BIOS boot partition if /boot is a plain >partition (using blocklists), even though it is less reliable so a BIOS boot >partition is strongly recommended. Yeah, GRUB installed using blocklists is so much *not* a thing anybody should be doing these days. >- Other BIOS boot loaders such as syslinux/extlinux do not need or use a BIOS >boot partition. Also not a use case I'm particularly caring about, I'll be honest. They're also *really* not likely to work well without another filesystem in use, which I expect we'll detect anyway. >1b) IIUC the patch fixes #1033913 because the disk selected for installation >has received a new GPT disklabel without a BIOS boot partition, so further >checking is skipped. But IMO the root cause of #1033913 is that changes are >not committed to disk after setting the 'boot' and 'esp' flags to the newly >created ESP partition before stopping parted_server. >This can be seen in /var/log/partman: > >/bin/autopartition-lvm >NEW_LABEL sda gpt >NEW_PARTITION 1 sda ext2 538MB (future ESP) >NEW_PARTITION 2 sda ext2 512MB (future /boot) >NEW_PARTITION 3 sda ext3 159GB (future LVM) >SET_FLAGS sda3 lvm >(user prompt to write changes to the disk) >COMMIT sda >... >/lib/partman/update.d/21efi_sync_flag >SET_FLAGS sda1 boot esp >... >/bin/perform_recipe_by_lvm >QUIT <- esp and boot flags have not been committed yet so are lost >... >/lib/partman/init.d/50efi >GET_FLAGS sda1 -> none > >2) The patch considers the 'esp' and 'boot' flags to be equal. But this is >true only with GPT. With MSDOS, they have totally different meanings: >- 'esp' means that the partition has the ESP type identifier. >- 'boot' means that the partition has the active/boot indicator set. The UEFI >specification says that this indicator is ignored by EFI boot. ACK, I think you're correct here. Yay parted and its inconsistent "flags" concept. :-( >3) The patch considers LVM and RAID partitions not bootable. But both LVM and >RAID superblocks can have a boot loader reserved area. Also, GRUB may boot >them directly without a /boot partition. Hmmm, maybe. >4) It appears that partman fails to detect the specially crafted partition >table on the installation media created with a debian image. Is it intended >or fortunately unintentional ? If partman could see the EFI partition on the >installation media, the detection of BIOS-bootable systems would fail. That's not a worry for today... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1033913: marked as pending in partman-efi
Control: tag -1 pending Hello, Bug #1033913 in partman-efi reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/installer-team/partman-efi/-/commit/fcd3c59e48dcf4a962749f53f4244b2540296d4f Fix detection of BIOS-bootable systems Closes: #834373, #1033913 The previous logic was broken in multiple horrible ways, and didn't count things prperly at all. New logic: For each *disk*, check to see if it's BIOS-bootable. That means it must have either an msdos partition table type *or* a GPT partition table type with a BIOS boot partition. If we detect a BIOS-bootable disk which has non-ESP partitions on it, then we will consider that disk to be BIOS-bootable. If we detect that the system has a BIOS-bootable disk *and* has no existing ESPs on it, then we will trigger the "are you sure about UEFI?" warning. Tested in lots of combinations, all work as expected now. Also added lots more logging so we can see what's happend afterwards... (this message was generated automatically) -- Greetings https://bugs.debian.org/1033913
Bug#987008: grub2: diff for NMU version 2.06-8.1
On Tue, Mar 07, 2023 at 10:39:04AM -0500, Antoine Beaupré wrote: >On 2023-02-26 19:15:39, anar...@debian.org wrote: >> Control: tags 987008 + pending >> >> Dear maintainer, >> >> I've prepared an NMU for grub2 (versioned as 2.06-8.1) and >> uploaded it to DELAYED/2. Please feel free to tell me if I >> should delay it longer. >> >> Note that the package was uploaded to *experimental*, not unstable, as >> an extra precaution. Let me know if you will followup with an unstable >> update or I should. > >Timing out. > >I have now uploaded this package to unstable, DELAYED/2. Argh, no. I've taken your changes already, but I'm in the middle of some other grub work. Let's not waste time and effort on an NMU going through the system, complete with signing etc. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#1028301: marked as pending in grub2
Control: tag -1 pending Hello, Bug #1028301 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/7fd3d6f6574fe38c0f6f21d6e62837b353c972c0 Fix probing of LUKS2 devices (Closes: #1028301): - disk/cryptodisk: When cheatmounting, use the sector info of the cheat device - osdep/devmapper/getroot: Have devmapper recognize LUKS2 - osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM parameters (this message was generated automatically) -- Greetings https://bugs.debian.org/1028301
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
*/
>++ c = params;
>++ remaining = grub_strlen (c);
>++
>++ /* First, get the cipher name from the cipher. */
>++ seek_head = grub_memchr (c, '-', remaining);
>++ if (seek_head == NULL)
>++grub_util_error (_("can't get cipher from dm-crypt
>parameters `%s'"),
>++ params);
>++ cipher = grub_strndup (c, seek_head - c);
>++ if (cipher == NULL)
>++grub_util_error (_("could not strndup cipher of length
>`%lu'"), seek_head - c);
>++ remaining -= seek_head - c + 1;
>++ c = seek_head + 1;
>++
>++ /* Now, the cipher mode. */
>++ seek_head = grub_memchr (c, ' ', remaining);
>++ if (seek_head == NULL)
>++grub_util_error (_("can't get cipher mode from dm-crypt
>parameters `%s'"),
>++ params);
>++ cipher_mode = grub_strndup (c, seek_head - c);
>++ if (cipher_mode == NULL)
>++grub_util_error (_("could not strndup cipher_mode of length
>`%lu'"), seek_head - c);
>++
>++ remaining -= seek_head - c + 1;
>++ c = seek_head + 1;
>++
>++ err = grub_cryptodisk_setcipher (cryptodisk, cipher,
>cipher_mode);
>++ if (err)
>++ grub_util_error (_("can't set cipher of cryptodisk `%s' to
>`%s' with mode `%s'"),
>++ uuid, cipher, cipher_mode);
>++
>++ grub_free (cipher);
>++ grub_free (cipher_mode);
>++
>++ /*
>++ * This is the only hash usable by PBKDF2, and we don't
>++ * have Argon2 support yet, so set it by default,
>++ * otherwise grub-probe would miss the required
>++ * abstraction.
>++ */
>++ cryptodisk->hash = grub_crypto_lookup_md_by_name ("sha256");
>++ if (cryptodisk->hash == NULL)
>++ grub_util_error (_("can't lookup hash sha256 by name"));
>++
>++ dm_task_destroy (dmt);
>++}
>+ }
>++ dm_tree_free (tree);
>+ grub_free (grdev);
>+ }
>+ else
>+--
>+cgit v1.1
>+
>diff -Nru grub2-2.06/debian/patches/series grub2-2.06/debian/patches/series
>--- grub2-2.06/debian/patches/series 2023-02-25 21:09:36.0 +0100
>+++ grub2-2.06/debian/patches/series 2023-03-03 19:21:28.0 +0100
>@@ -115,3 +115,6 @@
> ignore_checksum_seed_incompat_feature.patch
> ignore_the_large_dir_incompat_feature.patch
> 987008-lvrename-boot-fail.patch
>+disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
>+osdep-devmapper-getroot-have-devmapper-recognize-luks2.patch
>+osdep-devmapper-getroot-set-up-cheated-luks2-cryptodisk-mount-from-dm-parameters.patch
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis
Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Tue, Feb 14, 2023 at 12:50:18PM +0100, Daniel Leidert wrote: >Am Dienstag, dem 14.02.2023 um 10:45 + schrieb Steve McIntyre: >> On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote: >> > Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o: >> >> ... >> >> > > But a generalized requirement that we be able to use debootstrap and >> > > vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't >> > > seem to be reasonable. >> > >> > You are completyl wrong. This breaks a standard way of installing any >> > system supported by deboostrap with a grub without a fix to deal with >> > this version of e2fsprogs. This isn't just about vmdb2. >> > >> > What you are saying is ignorant. >> > >> > If this isn't cared about, then this version of e2fsprogs shouldn't >> > make it into Bookworm. We are in the middle of a freeze and this breaks >> > toolchains and a standard way (see [1]) of installing Debian. >> >> Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're >> creating an image of an older release using newer tools then you'll >> need to be aware that sometimes the newer tools will create things >> that don't work there. If there's a bug here, I would strongly argue >> that it's in vmdb2. deboostrap (for example) includes some >> release-specific knowledge to cope with issues like this. > >debootstrap does nothing related to grub. So it is a bad example. That's why I said *like* this, not *exactly* like this. debootstrap has had knowledge of things like fs layouts etc. that older releases need (e.g. merged-/usr). >Again I refer to [1]: If the host system contains the problematic >e2fsprogs and the target system doesn't contain a grub with the fix >[2], then this breaks installations. This breaks older systems *and* >current systems. For example, I neither see the necessary grub patch >in both Ubuntu 20.04 and 22.04 either. So they also cannot be >installed using the deboostrap method and the toolchain in Sid (and >Bookworm if e2fsprogs makes it there). Breakages happen like this, and this has happened before in similar circumstances. If you're installing an older system using brand-new tools, you need to be aware of the potential for things to not work. In this particular case, all you need to do is tweak the flags on the ext4 filesystem when you create it. This isn't that hard... >[1] https://www.debian.org/releases/stable/amd64/apds03 >[2] Even "our" grub only contains a patch and not an upstream version >with support. So how can you even expect the target system to contain a >fix and be able to handle the created filesystem?! > >Whe whole handling is completely wrong here. First, grub should have >been fixed upstream. And the change in e2fsprogs should have been done >only after "fixed" grub versions had settled. If we do it the other way >around, we have to patch grub in affected distributions as well. And >for Debian that means at least to patch Bullseye and any other release >we want to be able to install from Bookworm. I even a lot of companies >using Buster still. And I know of folks still working on Stretch and Jessie. How far back do you want to tie things?? >> If we don't allow for this kind of change, that wouldn't allow us to >> *ever* make breaking changes in some packages, and that's just not >> sustainable. > >I'm critizicing the way of handling that breaking change and the >ignorance shown reagarding the impact, not that fact that there is a >breaking change. And it breaks a lot! This doesn't affect just a few >minor use cases. It affects the basic way of installing a clean Ubuntu >or Debian (or derivative) on a remote server using the debootstrap >method. People using these tools need to be aware of the potential issue. What would happen if you ran debootstrap with a filesystem that the target distro doesn't know how to mount at all, for example? >And again: We are in the middle of a freeze here. And e2fsprogs pushes >a breaking change that is not even handled by any existing grub >upstream release, and is also not properly handled within Debian?! Grub upstream is already known to be problematic in terms of release cycles. We now know about this particular issue (thanks Ted!) and we've fixed it in unstable (and soon testing). -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote: >Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o: ... >> But a generalized requirement that we be able to use debootstrap and >> vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't >> seem to be reasonable. > >You are completyl wrong. This breaks a standard way of installing any >system supported by deboostrap with a grub without a fix to deal with >this version of e2fsprogs. This isn't just about vmdb2. > >What you are saying is ignorant. > >If this isn't cared about, then this version of e2fsprogs shouldn't >make it into Bookworm. We are in the middle of a freeze and this breaks >toolchains and a standard way (see [1]) of installing Debian. Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're creating an image of an older release using newer tools then you'll need to be aware that sometimes the newer tools will create things that don't work there. If there's a bug here, I would strongly argue that it's in vmdb2. deboostrap (for example) includes some release-specific knowledge to cope with issues like this. If we don't allow for this kind of change, that wouldn't allow us to *ever* make breaking changes in some packages, and that's just not sustainable. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize
Control: reassign -1 grub2 On Wed, Feb 08, 2023 at 02:02:44PM -0500, Theodore Ts'o wrote: > >The fix for this issue landed in the grub2 repository on June 11, >2021: > >commit 7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 >Author: Javier Martinez Canillas >Date: Fri Jun 11 21:36:16 2021 +0200 ... >If we *are* going to backport some grub2 patches, may also make a plug >for this one, which is also in the upstream grub2 git repo: > >commit 2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b >Author: Theodore Ts'o >Date: Tue Aug 30 22:41:59 2022 -0400 I've just queued these up in our repo for the next grub upload, due in a few days. -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Bug#997274: NMU strace 6.1 for unstable?
Hi Andreas! On Sat, Jan 28, 2023 at 01:06:31PM +0100, Andreas Henriksson wrote: > >As you might have noticed I've taken the liberty to NMU strace into >*experimental*. > >I've done so based on my past experience that strace can have many >architecture specific problems, to give me a picture of what the >situation is for the latest upstream 6.1 release. >(And since it's experimental we have the posisibily to just RM it and >act like it never happened.) That's cool. :-) >It seems like mips* has test failures (as usual?!). >I've filed https://github.com/strace/strace/issues/235 >with my limited conclusions about the issues. > >Given that strace has not been updated for the entire release cycle and >that it's currently RC-buggy, I think it would be useful to try to >update it before the 12 Feb freeze. The time window is however very >small. >Additionally ppc64el seems to have a huge build backlog, so if we want >to make it during the limited time window before the freeze we can't >wait for the results. (I could possibly build on a ppc64el porterbox >to see if I can spot any problems there.) > >I would like to know what you think about a potential NMU of strace 6.1 >to unstable at this point. Probably with mips* tests set to not fail the >build (`|| true`). Possibly the same for ppc64el just to make sure it >doesn't give any surprises once it finally builds (and the upload is old >enough to migrate to testing). > >If I'm going to do the NMU I'll need to proceed very soon so your input >on this would be very appreciated if you could give it ASAP! >What do you think? Please feel free to NMU, I was hoping to get back to strace a while back but my time has vanished with shim and grub lately :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#1022180: shim: non-standard gcc used for build (gcc-10)
On Sun, Jan 29, 2023 at 11:58:02AM +0100, Christoph Biedl wrote:
>user debian-rele...@lists.debian.org
>usertags 1022180 + bsp-2023-01-ch-stcergue
>thank you
>
>@maintainer:
>
>Excuse my bluntness, but is there a reason to *not* just replace "10"
>with "12" as shown below, and previously done in commit 334e9afa
>("Switch to using gcc-10 rather than gcc-9. Closes: #978521")?
>The resulting shimx64.efi boots fine here.
I've already done this, but shim is not a package that can just be
tweaked and uploaded. I'm in the middle of testing this and a bunch of
other changes right now.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"
Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot
On Mon, Jan 02, 2023 at 11:57:42AM +0100, Laurent Bigonville wrote: > >Sorry to insist (again), but do you have any news about this? > >We are slowly approaching the freeze for bookworm and having a fix for this >looks quite important to me. Yes, I *know*. I've been chasing on this regularly for months now. It seems that we now finally have movement on the certificate front and I'm hoping we'll be able to get stuff unblocked in the next couple of weeks. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.” -- Mikko Hypponen (https://twitter.com/mikko/)
Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]
On Sat, Dec 10, 2022 at 07:40:47AM +0300, программист некто wrote: >Hello. Sorry for long wait. > >>программист некто: could you please try these changes and report back? > >I tried the first patch with grub 2.06-7. Result: grub-install works without >error. Cool, thanks for confirming! -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Bug#1022184: marked as pending in grub2
Control: tag -1 pending Hello, Bug #1022184 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/16895d90dd915342bbb8593c403849b6ba93feb7 Switch build-deps from gcc-10 to gcc-12. Closes: #1022184 Also needs backports from upstream commits to fix warnings/errors from using gcc 12: be8eb0eed util/mkimage: Fix dangling pointer may be used error acffb8148 build: Fix -Werror=array-bounds array subscript 0 is outside array bounds 3ce13d974 lib/reed_solomon: Fix array subscript 0 is outside array bounds (this message was generated automatically) -- Greetings https://bugs.debian.org/1022184
Bug#1021846: marked as pending in grub2
Control: tag -1 pending Hello, Bug #1021846 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/552fb3133016abd9b4f49bbafcab5d9b3cd1f09a Fix an issue in an f2fs security fix which caused mount failures Closes: #1021846. Thanks to программист некто for helping to debug the problem! (this message was generated automatically) -- Greetings https://bugs.debian.org/1021846
Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]
Hi Daniel! On Sat, Dec 03, 2022 at 01:41:51AM +1100, Daniel Axtens wrote: >Steve McIntyre writes: >> >> программист некто (in CC) reported this bug a few weeks back in >> Debian. Since I applied the bundle of filesystem bounds-checking fixes >> a few months back, he can't run grub-install. He's done the work to >> determine that the patch that breaks things for him is >> >> 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end >> of nat journal entries >> >> The full thread of our discussion is at https://bugs.debian.org/1021846 >> >> I don't have any knowledge of f2fs to go any further here. Help please! :-) > >Ergh, apologies for the regression. > >[somewhat off-topic: The fix came from a crash derived from fuzzing. I >am not really knowledgeable about f2fs either - I was just trying to do >my best based on what we could derive from the existing driver. In >general, filesystems are a nightmare for fuzzing fixes because testing >beyond the (quite decent!) tests that the grub test-suite runs is very >challenging. There is usually no-one who is both involved in grub >security and an expert on any given file system either. We do the best >we can. Sadly our regression rate has been climbing, so we may need to >come up with some other way to secure file systems or get access to >sufficient expertise in the future.] ACK. I used to develop amd maintain filesystems as a day job, I understand the issue! Writing good and comprehensive tests is hard, and therefore quite rare! >I had a massive, massive work-in-progress spiel where I looked at this >code and compared the linux code and counted sizes and so on and so >forth. I was getting nowhere. But eventually I realised I had just made >an off-by-one error in the test. You're allowed to have up to n = >NAT_JOURNAL_ENTRIES entries _inclusive_, because the loop below uses i < >n, not i <= n. D'oh. Doh indeed! :-) >Please try the following: > >diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c >index df6beb544cbd..855e24618c2b 100644 >--- a/grub-core/fs/f2fs.c >+++ b/grub-core/fs/f2fs.c >@@ -650,7 +650,7 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, >grub_uint32_t nid, > grub_uint16_t n = grub_le_to_cpu16 (data->nat_j.n_nats); > grub_uint16_t i; > >- if (n >= NAT_JOURNAL_ENTRIES) >+ if (n > NAT_JOURNAL_ENTRIES) > return grub_error (GRUB_ERR_BAD_FS, >"invalid number of nat journal entries"); > > >If for some reason that doesn't work, please add the following debug >code and report the results: > >diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c >index 855e24618c2b..6e49a6d17b7a 100644 >--- a/grub-core/fs/f2fs.c >+++ b/grub-core/fs/f2fs.c >@@ -643,6 +643,10 @@ get_nat_journal (struct grub_f2fs_data *data) > return err; > } > >+#ifdef GRUB_UTIL >+#include >+#endif >+ > static grub_err_t > get_blkaddr_from_nat_journal (struct grub_f2fs_data *data, grub_uint32_t nid, > grub_uint32_t *blkaddr) >@@ -650,6 +654,10 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_data >*data, grub_uint32_t nid, > grub_uint16_t n = grub_le_to_cpu16 (data->nat_j.n_nats); > grub_uint16_t i; > >+#ifdef GRUB_UTIL >+ fprintf(stderr, "%s: n = %hu\n", __func__, n); >+#endif >+ > if (n > NAT_JOURNAL_ENTRIES) > return grub_error (GRUB_ERR_BAD_FS, >"invalid number of nat journal entries"); > программист некто: could you please try these changes and report back? >Amusingly the debug code shows that the grub-fs-tester tests always have >n = 0, which makes sense for a test that doesn't really stress the >file-system, and also explains why we didn't catch the bug when it was >introduced. Right. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Bug#1024395: grub-efi-amd64-signed: after upgrade to 1+2.06+5 I get errors when booting (although I manage to boot)
Control: severity -1 important Hi Eric, On Fri, Nov 18, 2022 at 07:24:32PM +0100, Eric Valette wrote: >Package: grub-efi-amd64-bin >Version: 1+2.06+5 >Severity: grave >Tags: security >Justification: user security hole >X-Debbugs-Cc: Debian Security Team > >After upgrade to 2.06-5, I get an error message "prohibited by secure boot >policy" and it boot >with a strange look with \xe7caracaters instead of lines. Right. Those are both part of the security fixes that went into the latest grub upload. It's trying to load fonts from /usr, but that's now blocked when doing Secure Boot. It's basically cosmetic, but obviously we don't want to leave it like this. We're talking upstream about the best way to fix this up now. >I build my own kernel and enrolled my owns keys, sign the linux >kernel binarry and the mdoules with the keys. Everythong was working >fine with 2.06-3. > >I also noticed that my enrolled keys is no more listed via "mokutil >--list-enrolled". Although no key were cleared. OK. I believe that is more likely an unrelated issue. -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]
Hi Sudhakar! On Fri, Nov 25, 2022 at 10:52:39AM +0530, sudhakar wrote: >Hi Steve, > >It seems invalid Commit id which you reported. It should be >4bd9877f62166b7e369773ab92fe24a39f6515f8 >did you applied below patch and tested? Could you please confirm that. > >fs/f2fs: Do not read past the end of nat journal entries > >https://git.savannah.gnu.org/cgit/grub.git/patch/?id=4bd9877f62166b7e369773ab92fe24a39f6515f8 It's exactly the same patch, just the commit hash is different when pulled into our 2.06 tree. Cheers, Steve -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Bug#1024493: Proposed-RM: bs1770gain -- RoQA; inappropriate content
On Sun, Nov 20, 2022 at 10:12:32PM +0100, Petter Reinholdtsen wrote: >[Christoph Berg] > >> It's not just "views" of the author. The crap is deeply embedded into >> the source code. This thing needs to go. > >Where and what is this 'crap' that is 'deeply embedded into the source >code'? Are we talking about the stuff disabled by >debian/patches/2000-non-controversial-usage.patch or something else? There's still a link to his moronic racist views in the Debian packaging itself (the Homepage field), and the stuff you've patched out is still in the source we distribute. At the very least they should be removed IMHO. >A friend of mine from USA visites this summer, and said he was impressed >that in my country people with opposing views were able to talk together >and treat each other with respect. I believe it is a property that is >worth protecting, as the way to change peoples mind is by treating them >with respend and communicating with them as fellow humans. There's a difference in degree here that I hope you might recognise? We like to discuss different opinions, sure. But hatred of others is not a worthy *opinion*. Distributing and linking to racist propaganda is really *not* something Debian should be doing. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]
Hi all! программист некто (in CC) reported this bug a few weeks back in Debian. Since I applied the bundle of filesystem bounds-checking fixes a few months back, he can't run grub-install. He's done the work to determine that the patch that breaks things for him is 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end of nat journal entries The full thread of our discussion is at https://bugs.debian.org/1021846 I don't have any knowledge of f2fs to go any further here. Help please! :-) - Forwarded message from программист некто - From: программист некто To: sub...@bugs.debian.org Date: Sat, 15 Oct 2022 23:54:36 +0300 Subject: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem Message-Id: <3168731665867...@wf4nrjvtssjecb53.iva.yp-c.yandex.net> Package: grub-pc Version: 2.06-3~deb11u1 Severity: critical Hello. Since version 2.06-3, grub-install is broken: it fails with "error: unknown filesystem". I test command /usr/sbin/grub-install -v /dev/sda in some versions. Results in mail attachments. Versions older than 2.06-3 works without error (2.06-2 and lower). Tested versions: 2.04-20, 2.06-1, 2.06-2, 2.06-3~deb10u1, 2.06-3~deb11u1, 2.06-4. Disk partitions: # fdisk --list-details Disk /dev/sda: 29,82 GiB, 32017047552 bytes, 62533296 sectors Disk model: TS32GSSD370S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xc7177f7e Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs /dev/sda1 2048 22763519 22761472 83 Linux 4/4/1 1023/254/2 /dev/sda2 * 25866240 62531583 36665344 7 HPFS/ 1023/254/2 1023/254/2 80 $ disktype /dev/sda1 --- /dev/sda1 Block device, size 10.85 GiB (11653873664 bytes) F2FS file system (version 1.14) $ disktype /dev/sda2 --- /dev/sda2 Block device, size 17.48 GiB (18772656128 bytes) NTFS file system Volume size 17.48 GiB (18772652032 bytes, 36665336 sectors) - End forwarded message - -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
On Sat, Nov 12, 2022 at 03:11:49PM +0300, программист некто wrote: >Hello. I rebuilt and tested grub only with patch >0087-fs-f2fs-Do-not-read-past-the-end-of-nat-journal-entr.patch >Result: error: unknown filesystem. Yay! Thanks very much for following up on this. I'll raise this with upstream. Are you happy for me to CC you on that discussion too? -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
Hi! On Thu, Oct 20, 2022 at 06:20:26PM +0100, Steve McIntyre wrote: >On Thu, Oct 20, 2022 at 08:09:15PM +0300, программист некто wrote: >># fsck.f2fs -f /dev/sda1 >>didn't report any errors. > >OK, that's good to know. > >>I can continue testing - rebuild without patches in turn, to reveal patch >>which break f2fs support. > >If you're happy to do that, then that would be excellent! Did you get anywhere with this please? I'd like to try and fix this for the next grub upload if we can! :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Bug#995792: #995792 - please unbreak printing text files
On Sun, Oct 30, 2022 at 03:38:06PM +0100, Samuel Thibault wrote: >Steve McIntyre, le lun. 24 oct. 2022 10:16:39 +0100, a ecrit: >> This bug just bit me, and I'm disappointed nothing appears to have >> been done here to remedy this. > >I had actually not seen the bug report, the title of the bug report >didn't catch my eyes. Thus why it hadn't been fixed so far. Then I'm glad I raised this! :-) Thanks Samuel! -- Steve McIntyre, Cambridge, UK.st...@einval.com “Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.” -- Mikko Hypponen (https://twitter.com/mikko/)
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
On Thu, Oct 20, 2022 at 08:09:15PM +0300, программист некто wrote: ># fsck.f2fs -f /dev/sda1 >didn't report any errors. OK, that's good to know. >I can continue testing - rebuild without patches in turn, to reveal patch >which break f2fs support. If you're happy to do that, then that would be excellent! -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
On Wed, Oct 19, 2022 at 11:07:36AM +0300, программист некто wrote: >I rebuilt grub2 v.2.06-4 without 3 f2fs patches. >Results of # /usr/sbin/grub-install -v /dev/sda >in file attachment. No error! Excellent, and thanks for testing! OK, so the patches from upstream have broken f2fs support for you. Looking at the patches, I'm not seeing anything *obvious* there that might be an issue. They're all trying to add checks to avoid crashes with an invalid/corrupt f2fs filesystem. Silly question: does your filesystem have errors? Does fsck.f2fs report anything? -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
On Sun, Oct 16, 2022 at 09:57:35PM +0100, Steve McIntyre wrote: >On Sun, Oct 16, 2022 at 07:37:53AM +0300, программист некто wrote: >>Output already captured. See >>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021846 the first message >>- it have an attached files with grub-install output. > >Ah, sorry; I missed them. Looking now. So I can see from the logs is that from 2.06-3 is just failing to detect a f2fs filesyste. There *was* a significant set of changes before we shipped that version: upstream security updates that fixed a big set of bugs, including in the f2fs code. I'm thinking that one of those changes might have caused this issue. Are you happy to try rebuilding grub from source yourself? If so, I'd suggest to rebuild without those f2fs changes included. If you're not sure, let me know and I'll do a rebuild for you. -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
On Sun, Oct 16, 2022 at 07:37:53AM +0300, программист некто wrote: >Output already captured. See >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021846 the first message - >it have an attached files with grub-install output. Ah, sorry; I missed them. Looking now. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem
Hi! On Sat, Oct 15, 2022 at 11:54:36PM +0300, программист некто wrote: >Package: grub-pc >Version: 2.06-3~deb11u1 >Severity: critical > >Hello. Since version 2.06-3, grub-install is broken: it fails with "error: >unknown filesystem". >I test command /usr/sbin/grub-install -v /dev/sda >in some versions. Results in mail attachments. >Versions older than 2.06-3 works without error (2.06-2 and lower). >Tested versions: 2.04-20, 2.06-1, 2.06-2, 2.06-3~deb10u1, 2.06-3~deb11u1, >2.06-4. Thanks for testing all these, that's very helpful. Could you please run grub-install with "-v" and capture the output? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot
On Mon, Oct 03, 2022 at 09:22:02PM +0200, Vincent Bernat wrote: >On Fri, 10 Sep 2021 10:35:31 +0200 Julian Andres Klode >wrote: >> Control: reassign -1 shim >> Control: affects -1 fwupd >> >> On Fri, Sep 10, 2021 at 09:27:11AM +0200, Norbert Schulz wrote: >> > Package: fwupd >> > Version: 1.2.14-1~deb10u1 >> > Followup-For: Bug #968997 >> > > Dear Maintainer, >> > > this bug still exist for a long time. I removed all packages relating >> fwupd and install it from scratch but > no install of the firmware on >> reboot. >> >> Sure, that's expected, shim 15.4 is not able to load fwupd without >> additional patches, which have not been applied yet, so it's >> not going to get better by reinstalling fwupd. > >shim-unsigned has been updated to 15.6 which has the right patches in. But >for some reason, shim-signed is still at 15.4. We've had problems in submitting shim 15.6 to Microsoft for signing. We're working on a solution, but it's going to take a little longer yet. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#1017944: Availability in Debian Stable?
Hi Sebastien, On Sat, Oct 01, 2022 at 11:18:31AM +0200, Sebastien KOECHLIN wrote: > >Thanks a lot for the correction. > >The 2.06-3~deb11u2 is now out for two weeks, but not available in Debian >Stable. Any new XEN installation will not be functionnal since Sept-10 >(publication of Debian 11.5). Rollback is paintfull. > >https://packages.debian.org/source/bullseye/grub2 -> 2.06-3~deb11u1 > >Will it be push into Bullseye? Or do we have to wait for 11.6? It will go into bullseye in 11.6 as part of that point release. But before then I'd strongly recommend adding the bullseye-updates suite to your sources list. That suite is there specifically for this kind of change, and *should* be automatically included when a system is installed (using d-i at least). -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Bug#1017944: marked as pending in grub2
Control: tag -1 pending Hello, Bug #1017944 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/aeac09767fd915304102f72d2deb21848fdd8bea Don't strip Xen binaries so they work again. Closes: #1017944. Thanks to Valentin Kleibel for the patch. (this message was generated automatically) -- Greetings https://bugs.debian.org/1017944
Bug#1017944: grub-xen-host: 2.06-3 crashes PV guests in early boot
Control: seveerity -1 grave On Tue, Sep 06, 2022 at 03:55:39PM +0200, Valentin Kleibel wrote: >found 1017944 grub2/2.06-3~deb11u1 >severity 1017944 serious >tags 1017944 patch > >Dear Maintainers, > >We can confirm that this bug affects all pv and pvh domUs that use pvgrub. >The commit responsible is 20239c28 "Bump debhelper from old 10 to 13." [1] >The relevant change in debhelper came with version v11: "The dh_strip and >dh_shlibdeps tools no longer uses filename patterns to determine which files >to process. Instead, they open the file and look for an ELF header to >determine if a given file is an shared object or an ELF executable." >By choosing debhelper 13, this led to pv grub getting stripped. >A simple override to dh_strip mitigates the issue. > >We assume that testing and unstable are affected as well but we do not have >systems to test this. Thanks Valentin, I'm looking at this now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Bug#1013341: /usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
On Wed, Jun 22, 2022 at 12:47:34PM +0200, Michael Biebl wrote: > >Am 22.06.22 um 11:49 schrieb Julien Cristau: >> On Wed, Jun 22, 2022 at 10:50:48AM +0200, Michael Biebl wrote: > >> > Marking as RC, as it causes a FTBFS >> > >> Not using -Wl,--fatal-warnings might be a workaround for systemd until >> gnu-efi fixes this? > >Yeah, I'll probably add a workaround like > > >diff --git a/src/boot/efi/meson.build b/src/boot/efi/meson.build >index 52e2a71a7c..18311ede25 100644 >--- a/src/boot/efi/meson.build >+++ b/src/boot/efi/meson.build >@@ -251,6 +251,8 @@ efi_ldflags = [ > '-L', efi_libdir, > '-nostdlib', > '-T', efi_lds, >+'-Wl,--no-warn-execstack', >+'-Wl,--no-warn-rwx-segments', > '-Wl,--build-id=sha1', > '-Wl,--fatal-warnings', > '-Wl,--no-undefined', > >to systemd for the time being. ACK, that's probably your best bet for now. The EFI toolchain has quite special needs here yet... -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Bug#1006575: NMU: sbsigntool: FTBFS with OpenSSL 3.0
Thanks Bastian! On Sat, Jun 04, 2022 at 01:46:49PM +0200, Bastian Germann wrote: >Ubuntu has the patches to fix this and another OpenSSL 3.0 error. >I have attached the debdiff that I have just uploaded to DELAYED/10. >diff -Nru sbsigntool-0.9.4/debian/changelog sbsigntool-0.9.4/debian/changelog >--- sbsigntool-0.9.4/debian/changelog 2021-09-14 06:39:01.0 + >+++ sbsigntool-0.9.4/debian/changelog 2022-06-04 11:37:27.0 + >@@ -1,3 +1,14 @@ >+sbsigntool (0.9.4-3.1) unstable; urgency=medium >+ >+ * Non-maintainer upload >+ >+ [ Simon Chopin ] >+ * Disable -Werror on deprecation warnings for the OpenSSL transition >+(Closes: #1006575) >+ * Apply patch to fix the OpenSSL3 build (LP: #1946193) >+ >+ -- Bastian Germann Sat, 04 Jun 2022 11:37:27 + >+ > sbsigntool (0.9.4-3) unstable; urgency=medium > > * Team upload >diff -Nru sbsigntool-0.9.4/debian/patches/OpenSSL3.patch >sbsigntool-0.9.4/debian/patches/OpenSSL3.patch >--- sbsigntool-0.9.4/debian/patches/OpenSSL3.patch 1970-01-01 >00:00:00.0 + >+++ sbsigntool-0.9.4/debian/patches/OpenSSL3.patch 2022-06-04 >11:36:45.0 + >@@ -0,0 +1,32 @@ >+Subject: Fix openssl-3.0 issue involving ASN1 xxx_it >+From: Jeremi Piotrowski >+Origin: https://groups.io/g/sbsigntools/message/54 >+ >+Use ASN1_ITEM_rptr() instead of taking the address of IDC_PEID_it. >+ >+openssl-3.0 changed the type of TYPE_it from `const ASN1_ITEM TYPE_it` to >+`const ASN1_ITEM *TYPE_it(void)`. This was previously hidden behind >+OPENSSL_EXPORT_VAR_AS_FUNCTION but in 3.0 only the function version is >+available. This change should have been transparent to the application, but >+only if the `ASN1_ITEM_rptr()` macro is used. >+ >+This change passes `make check` with both openssl 1.1 and 3.0. >+ >+Signed-off-by: Jeremi Piotrowski >+--- >+ src/idc.c | 2 +- >+ 1 file changed, 1 insertion(+), 1 deletion(-) >+ >+diff --git a/src/idc.c b/src/idc.c >+index 6d87bd4..0a82218 100644 >+--- a/src/idc.c > b/src/idc.c >+@@ -189,7 +189,7 @@ int IDC_set(PKCS7 *p7, PKCS7_SIGNER_INFO *si, struct >image *image) >+ >+ idc->data->type = OBJ_nid2obj(peid_nid); >+ idc->data->value = ASN1_TYPE_new(); >+- type_set_sequence(image, idc->data->value, peid, _PEID_it); >++ type_set_sequence(image, idc->data->value, peid, >ASN1_ITEM_rptr(IDC_PEID)); >+ >+ idc->digest->alg->parameter = ASN1_TYPE_new(); >+ idc->digest->alg->algorithm = OBJ_nid2obj(NID_sha256); >diff -Nru sbsigntool-0.9.4/debian/patches/series >sbsigntool-0.9.4/debian/patches/series >--- sbsigntool-0.9.4/debian/patches/series 2021-09-14 06:39:01.0 >+ >+++ sbsigntool-0.9.4/debian/patches/series 2022-06-04 11:36:09.0 >+ >@@ -1,3 +1,4 @@ > sbsign_check_write_return.patch > fix-efi-arch-detection.patch > 0001-sbsigntool-add-support-for-RISC-V-images.patch >+OpenSSL3.patch >diff -Nru sbsigntool-0.9.4/debian/rules sbsigntool-0.9.4/debian/rules >--- sbsigntool-0.9.4/debian/rules 2021-09-14 06:39:01.0 + >+++ sbsigntool-0.9.4/debian/rules 2022-06-04 11:37:18.0 + >@@ -4,6 +4,7 @@ > include /usr/share/dpkg/architecture.mk > include /usr/share/dpkg/pkg-info.mk > >+export DEB_CFLAGS_MAINT_APPEND=-Wno-error=deprecated-declarations > > # Uncomment this to turn on verbose mode. > export DH_VERBOSE=1 -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Bug#997638: nas: FTBFS: ar: libdeps specified more than once
^
>> gram.y:111:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 111 | ddaSetConfig(AUTOOPEN, (void
>> *)parsebool($2));
>> | ^
>> gram.y:115:51: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 115 | ddaSetConfig(FORCERATE, (void
>> *)parsebool($2));
>> | ^
>> gram.y:119:51: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 119 | ddaSetConfig(READWRITE, (void
>> *)parsebool($2));
>> | ^
>> gram.y:131:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 131 | ddaSetConfig(WORDSIZE, (void *)$2);
>> | ^
>> gram.y:135:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 135 | ddaSetConfig(FRAGSIZE, (void *)$2);
>> | ^
>> gram.y:139:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 139 | ddaSetConfig(MINFRAGS, (void *)$2);
>> | ^
>> gram.y:143:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 143 | ddaSetConfig(MAXFRAGS, (void *)$2);
>> | ^
>> gram.y:147:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 147 | ddaSetConfig(NUMCHANS, (void *)$2);
>> | ^
>> gram.y:150:49: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 150 | { ddaSetConfig(MAXRATE, (void *)$2); }
>> | ^
>> gram.y:152:49: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 152 | { ddaSetConfig(MINRATE, (void *)$2); }
>> | ^
>> gram.y:154:46: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 154 | { ddaSetConfig(GAIN, (void *)$2); }
>> | ^
>> gram.y:156:51: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 156 | { ddaSetConfig(GAINSCALE, (void *)$2); }
>> | ^
>> gram.y:161:43: warning: implicit declaration of function ‘RemoveDQuote’
>> [-Wimplicit-function-declaration]
>> 161 | RemoveDQuote(ptr);
>> | ^~~~
>> y.tab.c:1497:7: warning: implicit declaration of function ‘yyerror’; did you
>> mean ‘yyerrok’? [-Wimplicit-function-declaration]
>> gram.y: At top level:
>> gram.y:170:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>> 170 | RemoveDQuote(str)
>> | ^~~~
>> rm -f libdia.a
>> ar clq libdia.a dispatch.o dixutils.o events.o globals.o main.o resource.o
>> swapreq.otables.o swaprep.oaudispatch.o auswap.o autables.o
>> auevents.o auutil.o auconfig.oauprocess.o nasconf.o lex.o gram.o
>> ar: libdeps specified more than once
>> make[4]: *** [Makefile:1083: libdia.a] Error 1
>
>
>The full build log is available from:
>http://qa-logs.debian.net/2021/10/23/nas_1.9.4-7_unstable.log
>
>A list of current common problems and possible solutions is available at
>http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
>If you reassign this bug to another package, please marking it as 'affects'-ing
>this package. See https://www.debian.org/Bugs/server-control#affects
>
>If you fail to reproduce this, please provide a build log and diff it with mine
>so that we can identify if something relevant changed in the meantime.
>
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.
Bug#992449: cdimage.debian.org: sr kernel module is missing on install media for arm64 which prevents installation in KVM guest
Hi Lance, Sorry to hear that you're having problems here :-( On Wed, Aug 18, 2021 at 12:49:05PM -0700, Lance Albertson wrote: >I forgot to mention that the mini.iso image located here [1] does appear to >work as expected FWIW. But the image found here [2] does not. > >[1] https://debian.osuosl.org/debian/dists/bullseye/main/installer-arm64/ >20210731/images/netboot/ >[2] https://debian.osuosl.org/debian-cdimage/11.0.0/arm64/iso-cd/ So, I'm surprised to read this. On release day I tested our arm64 media locally using qemu/KVM VMs on an arm64 host here. I've just booted the netinst media again now (debian-11.0.0-arm64-netinst.iso) and I can see the following modules loaded, clearly including sr_mod: # lsmod Module Size Used by virtio_net 53248 0 net_failover 24576 1 virtio_net failover 20480 1 net_failover nls_utf8 16384 1 isofs 49152 1 sr_mod 32768 1 cdrom 61440 2 isofs,sr_mod virtio_scsi24576 1 scsi_mod 221184 2 virtio_scsi,sr_mod virtio_blk 28672 0 virtio_pci 28672 0 virtio_mmio24576 0 virtio_ring28672 5 virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net virtio 20480 5 virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net I'm curious why you might be seeing different. Could you share more details of your setup please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#992238: debian-installer: Installation fails on HP ProLiant m400 Server: additional cores crash, kernel hangs in acpi_init
Control: severity -1 important Control: reassign -1 src:linux Hi Justus! Reassigning to the right package. While you're seeing this during d-i, the problem is clearly coming from the Linux kernel. On Mon, Aug 16, 2021 at 10:09:49AM +0200, Justus Winter wrote: >Package: debian-installer >Version: 20210731 >Severity: critical >Tags: d-i >Justification: breaks the whole system > >Dear Maintainer, > >I'm trying to install Debian Bullseye on a ProLiant m400 Server >Cartridge. The cartridge is in EFI mode, we boot the EFI shim, GRUB, >the kernel, and the netboot initrd via PXE and tftp. We added the >necessary kernel command line flags to redirect the kernel log to the >serial console early on, and various debugging flags. > >Reading the log we believe that there are two problems. First, while >bringing up additional CPU cores, we see them crash immediately. >Adding nosmp to the kernel command line avoids this, but doesn't make >the second problem go away. Second, the kernel calls acpi_init, which >does not seem to return. Hmmm. The m400 sleds are getting quite old, and AIUI they're basically EOL in terms of firmware support etc. I've got some Mustang (X-Gene 1) machines here, which are the same core APM hardware but packaged on standard motherboard (mini-itx I think?). I'm just trying a bullseye update on one now. Out of curiosity: how does an equivalent boot work with buster d-i on your system? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#992164: calamares: Creating a new blank partition table GPT/UEFI results in failure
On Sat, Aug 14, 2021 at 05:50:47PM +0100, Steve McIntyre wrote: > >Starting in BIOS mode on a kde i386 live image. The existing disk on >my test system has an LVM setup on it. I've told calamares to wipe the >whole disk and do a fresh installation, but it looks like the code to >work out the existing disks has got confused and it thinks that the >whole disk is /dev/debian-vg rather than /dev/sda. Three attachments >here: > > * partitions.txt is the output of "fdisk -l" at the start > * Screenshot_20210814_174257.png shows calamares just before I hit > "Install" > * Screenshot_20210814_174916.png shows the error message FTAOD: I've just cleared the partition on the disk and restarted calamares and now it's working fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution
On Sun, Jul 25, 2021 at 08:19:55PM +0500, Roman Mamedov wrote: >On Sun, 25 Jul 2021 12:43:48 +0100 >Steve McIntyre wrote: > >> Which provider is using secure boot on arm64 at this point? I've not >> heard of any. Can you share details of package versions etc. for that >> please? > >It is the Oracle Cloud. > >Actually I am not certain they use secure boot, or that the lack of signature >is the issue. According to serial console, the issue was a fatal crash in the >UEFI boot loader (TianoCore). So I assumed it could be because it did not find >the signature it was expecting to validate. OK. I think I know what the problem is here. See below... >Unfortunately I did not save the crash messages and cannot reproduce it for >now, as I am not longer able to start my instances due to "Out of host >capacity" at the provider. > >As for the package versions, I was using the vanilla Debian Buster. OK, thanks for that information. In your next mail, I can see your log shows shim-signed version 1.36~1+deb10u1+15.4-5~deb10u1. Despite testing that version on various arm64 platforms before release, *after* the 10.10 point release we found that version can also crash and fail to boot in some circumstances. I think that's your problem here. :-( When we found that problem, as an immediate workaround I released a newer shim-signed package into the buster-updates repo which solves it: version 1.36~1+deb10u2+15.4-5~deb10u1 (note the deb10u1->deb10u2). I can see that your system is showing buster-updates in its list of package sources, so I'm very confused as to what's happened there and why your system did not pick up the later version. Argh! -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Bug#991478: [shim-signed] RFE: do not brick users' systems in the stable distribution
Hi Roman, On Sun, Jul 25, 2021 at 04:01:23PM +0500, Roman Mamedov wrote: >Package: shim-signed >Severity: grave > >Starting from 1.34~1+deb10u1 and its corresponding "***WARNING***", now the >arm64 shim "is no longer signed". > >As a result, after a mundane package upgrade and a reboot, all of my remote >arm64 machines do not boot anymore. I was not aware that the cloud provider >actually uses this "secure boot", else I'd pay more attention to that >"WARNING". Which provider is using secure boot on arm64 at this point? I've not heard of any. Can you share details of package versions etc. for that please? >In any case, relying on the user reading upgrade notes, and then to scramble >rolling back the upgrade and holding the affected package ASAP, else the >system is bricked, is not a responsible package policy. > >I would humbly suggest that you kept the latest signed version frozen at least >in "buster" with no further updates, until the signing issue is resolved. Or >as of now, release another update with the signed version in place. Sorry, but that's not an option - the older version of shim left multiple high-security issues open, allowing people to easily break into a Secure Boot setup. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Hi Ryan, On Sat, Jul 17, 2021 at 09:19:22AM -0500, Ryan Thoryk wrote: >On 7/17/21 8:18 AM, Steve McIntyre wrote: >> On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: >> EFI/debian is *NOT* wrong, it's the correct location for a system that >> has working firmware which supports setting UEFI boot variables. If >> you *also* need to write a copy of grub (etc.) to the removable media >> location (EFI/boot) then that's supported as well by the Debian >> packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the >> system asks about that. > >Thanks for that suggestion, that explains the correct procedure in resolving >the issue. What I'm trying to point out though (I tried this), is that if >you spin up a new Debian ARM VM on AWS, and run "grub-install" *without* >doing a dpkg-reconfigure, it results in an unbootable system. To recover the >system, you have to attach the disk on a different VM and replace the old >boot loader image with the new one, then it boots again. After running the >dpkg-reconfigure command though like you suggested, it copied over the EFI >boot image to the "BOOT" folder, and also set the nvram variables to >apparently boot from the "debian" folder, so that solved the problem for me. >After doing that, the system comes up after a reboot with the newer grub >modules. > >With others on here, the issue might have to do with the system executing an >older EFI boot image resulting in a module mismatch, like what happened to >me. Your dpkg-reconfigure suggestion might fix their issues too. So when you say "spin up a new Debian ARM VM on AWS", what exact image are you using here? It sounds like the build process for that image needs to be fixed to DTRT for the platform. Then you and other users won't be bitten by this problem... -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: >On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson wrote: >> In general, this means that grub-install is not installing to the place >> that your firmware is actually booting from, which causes the core image >> (installed to a file under /boot/efi/ on UEFI systems) to be out of sync >> with the modules (installed to a subdirectory of /boot/grub/). This is >> much rarer on UEFI systems than on BIOS systems, but it's still possible >> in some misconfigured cases. >> >> Could you please attach the output of "sudo grub-install --debug", "sudo >> efibootmgr -v", and "sudo find /boot/efi -ls"? > >Thanks for looking into this issue. > >I did some investigating this morning for my situation, and found the >problem. Your suggestion is what helped me. > >The test case I had was that if you start a new Debian ARM VM on AWS, and run >grub-install on it, future boots fail, where they stop at the rescue prompt >and an "insmod normal" shows the error message. In other words, >"grub-install" was breaking grub, which is pretty bad. > >After some investigating I found that grub-install was writing the EFI boot >loader image (grubaa64.efi) to the wrong location on the system. It should be >installing into /boot/efi/EFI/BOOT but is putting it into >/boot/efi/EFI/debian. Future boots fail because the loader image that >executes (the one in BOOT) is the older version and is out of sync with the >modules. > >I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, >wondering if it would try to use the "EFI/debian" one, and after rebooting >the system was stuck in an EFI shell (couldn't find a boot loader), so the >"EFI/debian" folder is clearly wrong. This could be similar to what's >happening with others on here. EFI/debian is *NOT* wrong, it's the correct location for a system that has working firmware which supports setting UEFI boot variables. If you *also* need to write a copy of grub (etc.) to the removable media location (EFI/boot) then that's supported as well by the Debian packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the system asks about that. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Bug#990966: grub-efi-arm64: breaks upgrades when the efivarfs is mounted read-only
Control: severity -1 important Hey Andres, On Sun, Jul 11, 2021 at 04:19:19PM -0400, Andres Salomon wrote: >Package: grub-efi-arm64 >Version: 2.04-19 >Severity: serious > >I experienced the follow on multiple ARM64 systems (both a Rock64 >board and a Raspberry Pi 4b board) during an unattended-upgrades run: > >Unattended upgrade result: All upgrades installed > >Packages that attempted to upgrade: > shim-helpers-arm64-signed shim-signed shim-signed-common > shim-unsigned ... >Here's the relevant field in /proc/mounts: >efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime 0 0 > >I expect that the reason /sys/firmware/efi/efivars is mounted read-only is >due to bug reports such as the following: >https://github.com/systemd/systemd/issues/2402 But that was never agreed. I'm genuinely curious why you have efivarfs mounted read-only, and I don't think it's a supported/supportable option here. >It would be preferable for grub to either >a) continue the package postinstall despite efivars being read-only, or >b) remount efivars read-write, update efivars, and then remount ro. > >grub-install is being called from shim-helpers-arm64-signed's >postinst. You could argue that shim-helpers-arm64-signed could >remount efivars read-write, but since I can actually trigger the >same error in grub-efi-arm64's postinst, it seems like this should be >fixed in grub: The "issue" is definitely coming from grub-efi-$ARCH, but it's behaving as designed here. Continuing despite failing to update the EFI boot vars here will potentially leave you with an unbootable system. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."
On Wed, Jun 30, 2021 at 08:56:51PM +0200, Adam Borowski wrote: >Control: severity -1 serious > >On Mon, May 31, 2021 at 05:01:35PM +0200, Adam Borowski wrote: >> On Mon, May 31, 2021 at 07:08:22AM -0700, Kevin Wu wrote: >> > On Mon, May 31, 2021 at 4:26 AM Adam Borowski wrote: >> > > But, is there _any_ case when crossgrader might possibly work? As it >> > > needs >> > > python-apt-common, it will always fail. That makes the package useless. >> > > Should we bump #968458 to a RC severity? >> > >> > crossgrader won't be able to work if python3-apt cannot be >> > crossgraded, so there's no case where it would work. Would #968458 >> > merit critical for breaking unrelated software? > >As the other bug hasn't been fixed, crossgrader as it stands in Bullseye is >useless. So either we convince David to reconsider or a workaround has to >be found. Julian has just uploaded with the fix we need, so that should make things better. Dropping severity. (We'll probably need a fix for #990669, even so...) -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Bug#990158: Bug#989962: shim-signed 1.36~1+deb10u1 fails to boot some systems
On Wed, Jun 23, 2021 at 04:10:46PM +0200, Ayke Halder wrote: >The new build also works on a T5600, thanks a lot! > > >What I did: > >1. Upgrade: shim-signed:amd64 (1.33+15+1533136590.3beb971-7, >1.36~1+deb10u2+15.4-5~deb10u1), shim-signed-common:amd64 >(1.33+15+1533136590.3beb971-7, 1.36~1+deb10u2+15.4-5~deb10u1) > >--> System does not boot - as expected. > >2. Replace /boot/efi/EFI/debian/shimx64.efi with provided build > >--> System boots. Perfect, thanks very much for helping with testing! -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#990158: Bug#989962: shim-signed 1.36~1+deb10u1 fails to boot some systems
On Wed, Jun 23, 2021 at 01:00:51PM +0200, Grzegorz Szymaszek wrote: >On Tue, Jun 22, 2021 at 10:36:48PM +0100, Steve McIntyre wrote: >> Could you please verify if this new build fixes the problem you're >> seeing on your hardware? […] It may still complain about resource >> failures and "import_mok_state() failed", but should then boot anyway in >> non-secure mode. > >It works as you’ve described on an E6410. Awesome, thanks for testing! That's very helpful. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#990158: shim-signed-common: No UEFI boot with error "Could not create MokListXRT"
On Tue, Jun 22, 2021 at 11:47:22AM +0200, Ayke Halder wrote: >> On Mon, Jun 21, 2021 at 09:00:15PM +0200, Ayke Halder wrote: >> > Package: shim-signed-common >> > Version: 1.33+15+1533136590.3beb971-7 >> > Severity: critical >> > Justification: breaks the whole system >> > >> > Dear Maintainer, >> > >> > ## What led up to the situation? >> > >> > Upgrade: >> > >> > * shim-signed:amd64 (1.33+15+1533136590.3beb971-7, >> > 1.36~1+deb10u1+15.4-5~deb10u1) >> > * shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, >> > 1.36~1+deb10u1+15.4-5~deb10u1) >> > >> > System: Dell T5600 with BIOS Revision A19 >> > >> > >> > ## What was the outcome of this action? >> > >> > System is unbootable on booting via UEFI. System shows error message and >> > then >> > powers off immediately: >> > >> > "Could not create MokListXRT: Out of Resources >> > Something has gone seriously wrong: import_mok_state() failed: Out of >> > Resources" >> > >> > >> > ## What outcome did you expect instead? >> > >> > A normal booting system loading GRUB. >> > >> > >> > ## Also reproducible with Debian Live-Installations-Image >> > >> > On affected hardware like "Dell T5600" doing a UEFI boot from USB with … >> > >> > * debian-live-10.10.0-amd64-standard.iso does *not* work. >> > * debian-live-10.9.0-amd64-standard.iso works. >> > >> > >> > ## Related resources >> > >> > Might be related to: >> > >> > * https://bugzilla.suse.com/show_bug.cgi?id=1185261 >> Yes, it looks like exactly the same problem. :-( >> >> Several of the shim maintainers in various distributions are now >> seeing reports like this. It seems that lots of machines are short of >> space to store the new MokListXRT variable. Since the buster update >> this weekend, yours is the second problem report I've seen. >> >> Ubuntu have a patch to disable the variable mirroring here. I was not >> expecting we'd need it, but it looks like I was wrong. >> >> In terms of making your system boot, I'd suggest temporarily one of: >> >> * switch back to an older shim-signed package >> * disable Secure Boot and remove shim-signed >> > >I switched back to an older package of shim-signed and shim-signed-common. ACK, that's the best thing for now. >One caveat: >I could not get the older package version via the official package repository >anymore. Luckily I still had a copy of the old package in a local repository >mirror. OK. There's one thing I possibly should have mentioned here, then! https://snapshot.debian.org/ carries ~all the packages that are ever uploaded to Debian, so you should almost always be able to find older packages there. I use it quite frequently as a developer, but I guess it's not so well know amongst users! -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
Bug#990158: Bug#989962: shim-signed 1.36~1+deb10u1 fails to boot some systems
On Tue, Jun 22, 2021 at 09:20:36PM +0200, Grzegorz Szymaszek wrote: >On Tue, Jun 22, 2021 at 01:35:51PM +0200, Grzegorz Szymaszek wrote: >> I have recently upgraded several buster amd64 machines; shim-signed went >> up from 1.33 to 1.36~1+deb10u1. […] > >FWIW, upgrading to 1.36~1+deb10u2 brings the problem back. > >Looks like the same as #990158. Yes, it's the same problem. I'm testing a fix now. Could you please verify if this new build fixes the problem you're seeing on your hardware? https://people.debian.org/~93sam/shim/ has a new *unsigned* amd64 shim binary, and a checksum file. If you would be so kind, please copy that shimx64.efi binary into place on your system and test it boots OK. It may still complain about resource failures and "import_mok_state() failed", but should then boot anyway in non-secure mode. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#990158: shim-signed-common: No UEFI boot with error "Could not create MokListXRT"
Hi Ayke, Thanks for your bug report, and apologies for the problem :-/ On Mon, Jun 21, 2021 at 09:00:15PM +0200, Ayke Halder wrote: >Package: shim-signed-common >Version: 1.33+15+1533136590.3beb971-7 >Severity: critical >Justification: breaks the whole system > >Dear Maintainer, > >## What led up to the situation? > >Upgrade: > >* shim-signed:amd64 (1.33+15+1533136590.3beb971-7, >1.36~1+deb10u1+15.4-5~deb10u1) >* shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, >1.36~1+deb10u1+15.4-5~deb10u1) > >System: Dell T5600 with BIOS Revision A19 > > >## What was the outcome of this action? > >System is unbootable on booting via UEFI. System shows error message and then >powers off immediately: > >"Could not create MokListXRT: Out of Resources >Something has gone seriously wrong: import_mok_state() failed: Out of >Resources" > > >## What outcome did you expect instead? > >A normal booting system loading GRUB. > > >## Also reproducible with Debian Live-Installations-Image > >On affected hardware like "Dell T5600" doing a UEFI boot from USB with … > >* debian-live-10.10.0-amd64-standard.iso does *not* work. >* debian-live-10.9.0-amd64-standard.iso works. > > >## Related resources > >Might be related to: > >* https://bugzilla.suse.com/show_bug.cgi?id=1185261 Yes, it looks like exactly the same problem. :-( Several of the shim maintainers in various distributions are now seeing reports like this. It seems that lots of machines are short of space to store the new MokListXRT variable. Since the buster update this weekend, yours is the second problem report I've seen. Ubuntu have a patch to disable the variable mirroring here. I was not expecting we'd need it, but it looks like I was wrong. In terms of making your system boot, I'd suggest temporarily one of: * switch back to an older shim-signed package * disable Secure Boot and remove shim-signed -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#990082: High chance of boot problems with buster's version of arm64 shim
Package: shim-signed Version: 1.36~1+15.4-5~deb10u1 Severity: grave Argh. In pre-release testing I found problems with shim on signed versions of shim on arm64. The shim binary crashes very early (Synchronous Exception). Because of that problem, I took the hard decision to disable Secure Boot support for arm64 in Debian Buster until a solution could be found: https://wiki.debian.org/SecureBoot#arm64_problems In testing a new build to go into Buster, I found that non-signed versions were working fine on various machines. Unfortunately, it seems that the boot issues might be affected by environment. Trying the same binary build today as part of the 10.10 point release, booting an installer image crashes repeatably in a VM. It also seems that at least one of Debian's own arm64 hosts has been similarly affected. :-( Arm64 users are **strongly** advised to be careful about upgrading to the latest Buster point release (10.10). If upgrading immediately, it is recommended to disable remove shim-signed and reinstall GRUB on those systems to ensure that they will continue to boot: # apt-get remove shim-signed # dpkg --reconfigure grub-efi-amd64 and disable Secure Boot in their system firmware if it's enabled. I'm working on a more user-friendly fix now, and I hope to push it out via the Buster security archive shortly. This will still not be *working* Secure Boot for arm64, as we're still awaiting better toolchain support to make that work. -- System Information: Debian Release: 10.9 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages shim-signed depends on: ii grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4 ii grub2-common 2.02+dfsg1-20+deb10u4 ii shim-helpers-amd64-signed 1+15.4+2~deb10u1 Versions of packages shim-signed recommends: pn secureboot-db shim-signed suggests no packages. -- debconf information excluded
Bug#990017: [REGRESSION] Bullseye CD installer images fail to install GRUB on OpenPOWER machines
Control: reassign -1 grub-ieee1275 Hi Timothy, Reassigning this to the correct package where it should get more attention... On Thu, Jun 17, 2021 at 04:20:47PM -0500, Timothy Pearson wrote: >Package: debian-cd >Severity: Grave > >Attempting to use the latest Bullseye RC2 CD installer on an OpenPOWER machine >results in a fatal error during bootloader installation: > >Jun 17 21:14:45 grub-installer: info: Installing grub on '/dev/sda1' >Jun 17 21:14:45 grub-installer: info: grub-install does not support --no-floppy >Jun 17 21:14:45 grub-installer: info: Running chroot /target grub-install >--force "/dev/sda1" >Jun 17 21:14:45 grub-installer: Installing for powerpc-ieee1275 platform. >Jun 17 21:14:57 grub-installer: grub-install: error: unknown filesystem. >Jun 17 21:14:57 grub-installer: error: Running 'grub-install --force >"/dev/sda1"' failed. > >The bootloader installs normally using the Buster CD installers on the same >hardware. Just a quick sanity check - how did you partition the disk? Does it have the normal boot partition etc. needed for OpenPOWER? I'll admit I don't know all the details here - I'm not a powerpc expert. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Bug#987991: shim-signed: Recent dbx update blacklists shimx64.efi (1.33+15+1533136590.3beb971-7)
Hi Ondřej, On Mon, May 03, 2021 at 01:26:33PM +0200, Ondřej Holas wrote: >Package: shim-signed >Version: 1.33+15+1533136590.3beb971-7 >Severity: grave >Justification: renders package unusable > >Recent dbx update (https://uefi.org/revocationlistfile) from 2021-04-29 >includes hash > >AF79B14064601BC0987D4747AF1E914A228C05D622CEDA03B7A4F67014FEE767 > >which matches "message hash" of image shimx64.efi from latest shim-signed >package. After importing recent dbx file into UEFI variable, the system >refuses to boot with Secure Boot enabled. ACK. We have just got new signed shim binaries back from Microsoft last week, and we'll be publishing updated packages soon. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)
On Mon, Feb 15, 2021 at 04:35:37PM +0100, Ivo De Decker wrote: >Hi Steve, > >Thanks for the info. > >On Mon, Feb 15, 2021 at 12:43:33AM +, Steve McIntyre wrote: >> >Could you clarify the timing for this, especially the timeline for getting >> >the >> >signature from Microsoft (as far as that can be predicted)? I'm trying to >> >assess if this could become a blocker wrt the actual release. Is it an >> >option >> >to release with the current version of shim-signed (ie the one that's also >> >in >> >buster) if we don't get the signature in time? >> >> It's not really an option to release with the old shim at this point, >> I'm afraid. > >That's good to know. I tagged this bug 'is-blocker', to make sure we keep an >eye on it. > >> But there are newer processes in place around getting new >> builds signed, so I'm not worrying too much here about delaying the >> release. So, to update here... Shim development was caught up in the work to fix more Secure Boot holes in Grub (DSA-4867), and it's not quite ready yet. We will have to wait for a few more upstream fixes yet, then get reviewed and signed. At that point, this bug will be fixed. -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary
On Thu, Feb 18, 2021 at 09:32:24AM +0100, Paul Gevers wrote: >Hi Limonciello, > >On 18-02-2021 07:15, Limonciello, Mario wrote: >> I don't have the power to manually run it. So there is nothing I can do. >> With the new 1.5.6-1 upload someone will need to manually run it again. > >I recognize what you say. However, *in my opinion* you can't just upload >the unsigned package without securing that the signing will happen ASAP, >with such tight dependencies. Users of unstable should expect that their >system breaks once in a while, but that's not by design but because bugs >happen. Being able to not update because of transitions is to be >expected and we don't have an alternative. But that's different from >what I read in this bug, where something else got updated and then the >fwupd set breaks without warning. We're in a bind here - by now I was hoping/assuming that we'd have the signing queue running automatically. I've just prodded in #debian-ftp to ask people to run the queue. -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)
Hey Ivo,
On Sun, Feb 14, 2021 at 07:56:20PM +0100, Ivo De Decker wrote:
>On Fri, Feb 12, 2021 at 01:35:52AM +0000, Steve McIntyre wrote:
>> On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote:
>> >Hi Steve,
>> >
>> >On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote:
>> >> During a rebuild of all packages in sid, your package failed to build
>> >> on amd64.
>> >
>> >[...]
>> >
>> >> > The following packages have unmet dependencies:
>> >> > sbuild-build-depends-main-dummy : Depends: shim-unsigned (=
>> >> > 15+1533136590.3beb971-7) but it is not going to be installed
>> >
>> >What is the status of shim(-signed) for bullseye?
>> >
>> >shim-unsigned has been changed, but there is no corresponding shim-signed
>> >(yet). I assume a new signature from microsoft is needed. Or are there more
>> >changes to shim-unsigned needed first?
>>
>> There are some other changes coming, not least switching compiler to
>> gcc-10 now we've stabilised.
>
>I'm tagging #978521 ("shim: non-standard gcc/g++ used for build (gcc-9)") as
>pending to indicate that you're planning to switch to gcc-10.
Thanks. Sorry, I forgot to do that myself.
>> I'm working on new shim uploads at the
>> moment, but there's a couple of upstream patches we'll need to take as
>> well yet I think. It'll be coming soon, I promise.
>
>Could you clarify the timing for this, especially the timeline for getting the
>signature from Microsoft (as far as that can be predicted)? I'm trying to
>assess if this could become a blocker wrt the actual release. Is it an option
>to release with the current version of shim-signed (ie the one that's also in
>buster) if we don't get the signature in time?
It's not really an option to release with the old shim at this point,
I'm afraid. But there are newer processes in place around getting new
builds signed, so I'm not worrying too much here about delaying the
release. I expect to have things sorted soon.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess
Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)
Hey Ivo, On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote: >Hi Steve, > >On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote: >> During a rebuild of all packages in sid, your package failed to build >> on amd64. > >[...] > >> > The following packages have unmet dependencies: >> > sbuild-build-depends-main-dummy : Depends: shim-unsigned (= >> > 15+1533136590.3beb971-7) but it is not going to be installed > >What is the status of shim(-signed) for bullseye? > >shim-unsigned has been changed, but there is no corresponding shim-signed >(yet). I assume a new signature from microsoft is needed. Or are there more >changes to shim-unsigned needed first? There are some other changes coming, not least switching compiler to gcc-10 now we've stabilised. I'm working on new shim uploads at the moment, but there's a couple of upstream patches we'll need to take as well yet I think. It'll be coming soon, I promise. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#981662: xfsprogs-udeb depends on libinih1, not libinih1-udeb
Source: xfsprogs Version: 5.10.0-2 Severity: serious Tags: d-i Hi folks, It appears that the latest version of xfsprogs (5.10.0) has just grown a dependency on libinih1, and there isn't a udeb version of libinih to meet that dependency. This means that xfs support in d-i just broke. When trying to create an XFS filesystem we now get: Error msg: "The xfs file system creation in partition #4 of /dev/nvme0n1 failed". When trying from 2nd console, there seems to be a lib missing: mkfs.xfs /dev/nvme0n1p4 mkfs.xfs: error while loading shared libraries: libinih.so.1: cannot open shared object file: No such file or directory There currently is not a libinih1-udeb package; maybe that's the right fix. I don't know xfsprogs well enough to know if there are other options (e.g. maybe disabling the libinih1 dependency from the udeb build). -- System Information: Debian Release: 10.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Kernel taint flags: 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 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#971946: marked as pending in libdebian-installer
Control: tag -1 pending Hello, Bug #971946 in libdebian-installer reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/installer-team/libdebian-installer/-/commit/05bea831d433548d7517e24651dd8183dbeb74ca Remove the arbitrary limitation on maximum line length in Packages and Sources files - it's pointless and breaks things periodically. Closes: #971946 (this message was generated automatically) -- Greetings https://bugs.debian.org/971946
Bug#976572: bio-eagle: FTBFS: MemoryUtils.hpp:34:10: fatal error: xmmintrin.h: No such file or directory
Hey Andreas, On Sat, Dec 05, 2020 at 05:07:41PM +0100, Andreas Tille wrote: >Control: tags -1 help > >Hi Lucas, > >On Sat, Dec 05, 2020 at 01:15:52PM +0100, Lucas Nussbaum wrote: >> During a rebuild of all packages in sid, your package failed to build >> on arm64 (I don't know if it also fails on amd64). > >I admit I have currently no chance to test on arm64 but the package >builds fine on amd64 since the include file is part of libgcc-dev > >Any help from the arm team is welcome xmmintrin.h is fundamentally tied to x86-only SIMD intrinsics. Either the package doesn't support non-x86, or there's a bug and it's mis-detecting which platform you're on. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Bug#957074: cdrkit: ftbfs with GCC-10
Hey Adrian, On Sat, Nov 14, 2020 at 12:13:02PM +0100, John Paul Adrian Glaubitz wrote: > >> Fedora has a patch for gcc-10 >> >> https://src.fedoraproject.org/rpms/cdrkit/blob/master/f/cdrkit-1.1.11-gcc10.patch > >Is anyone taking care of this package at the moment? > >I'm happy to adopt cdrkit for the time being until libisofs from libburnia >has gained support for creating legacy HFS filesystems which is required >for older Macintosh systems. > >For this reason, I'm currently using genisoimage when creating Debian CD >images for m68k. ACK. If you're happy to take ove cdrkit for now, I'd be very happy. I don't have the time to care for it any more. Thomas has been doing a great job with xorriso and friends, so it would be lovely to see us no longer need to keep the old code around any more... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly
On Wed, Nov 04, 2020 at 06:30:54PM +, Limonciello, Mario wrote: >> 在 2020-11-03星期二的 22:21 +，Limonciello, Mario写道： >> > > -Original Message- >> > > From: Boyuan Yang >> > > Sent: Tuesday, November 3, 2020 13:09 >> > > To: sub...@bugs.debian.org >> > > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU- >> > > friendly >> > > >> > > Package: fwupd-amd64-signed >> > > Severity: grave >> > > Version: 1.4.6+2 >> > > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com >> > > >> > > Dear EFI Team, >> > > >> > > Package fwupd-amd64-signed currently cannot be installed on Debian >> > > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has >> > > fwupd >> > > (= 1.4.6-2+b1). >> > >> > I'm sorry can you show me where this +b1 build is? >> > >> > I don't see it mentioned in https://tracker.debian.org/pkg/fwupd >> >> It is shown at https://buildd.debian.org/status/package.php?p=fwupd . >> If you actually install a Debian Sid system, you can also find the >> package with this version string. >> >> >> > > It seems obvious that such dependency relationship made >> > > fwupd/fwupd- >> > > amd64-signed not binNMU-friendly. Please consider setting a version >> > > range to allow binNMU-ed package to satisfy the dependency >> > > relationship. >> >> Please consider reading https://wiki.debian.org/binNMU and see how can >> things be improved. >> >> Thanks, >> Boyuan Yang > >I think the problem here is that the EFI binary sign process just didn't >run. @Steve McIntyre is that supposed to be automatic now? Or still manual? I saw earlier that it's just happened. It's still run manually. What we've done for the other -signed packages to deal with the delay and potentially inconsistent versioning is change the dependencies. Instead of depending on *exactly* the same version as the signed package (==), we switch to >= so that a delay in the new -signed package being processed won't break installations. -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
>From conversation in IRC: 1. If the device(s) mentioned in grub-pc/install_devices multiselect don't exist when grub-install is run, it should stop and warn the user that there might be a problem DSA have this on a VM, for example: grub-pc grub-pc/install_devices multiselect/dev/disk/by-id/scsi-3600508b1001052395358323050350006 2. Warn if install_devices is empty? -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
[ Dropping the CC to Chad here ]
On Sat, Aug 01, 2020 at 02:36:25PM +0100, Colin Watson wrote:
>On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>> * Do we need to scan? if grub is installed and doing an upgrade and
>>there is only one disk of an appropriate type (BIOS with DOS, or
>>UEFI with GPT), then always install there?
>
>Possibly. I'd still be inclined to have a scan as a guard-rail in that
>case, since we'd need to have the code anyway, and the point is to try
>to discover the disk that the system booted from so by definition it
>must have GRUB there if it's to be valid.
Nod. Of course, it's a guess at best - we have ~no way to know *for
sure* which disk we actually booted off. It would be lovely if we did,
but there's no protocol for grub to pass on that information that I
can see.
>> * (Maybe) we could add an option for grub-pc to always grub-install
>>to *all* the BIOS-visible disks? Yes, I know there's a potential
>>for breakage there with multi-boot systems. Maybe only do this on
>>systems where os-prober has not found anything but the Debian
>>installation?
>
>One concern I have is filtering out things like optical drives, which
>are BIOS-visible but not sensible grub-install targets. I'm also
>slightly reluctant to add more invocations of os-prober while it's as
>slow as it can sometimes be. I do see the utility of this though.
Nod. Can we not rely on os-prober already having been run once and use
that data? (Sorry, not sure of the ordering here.)
>> * If we do add the code to scan boot sectors, maybe check all the
>>BIOS-visible disks and flag any that look like they have GRUB, but
>>are not our version? (Not sure how feasible this is without
>>digging!)
>
>Unfortunately I believe this to be essentially infeasible. As an
>illustration, this is the scan code which exists in the current postinst
>to support migration from GRUB Legacy, and believe me I didn't resort to
>this horror before trying to find more sensible alternatives:
>
> # In order to determine whether we accidentally ran grub-install without
> # upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
> # to be able to scan a disk to determine whether GRUB 2 was installed in its
> # boot sector. This is specific to i386-pc (but that's the only platform
> # where we need it).
> scan_grub2()
> {
>if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
> # No version of GRUB is installed.
> return 1
>fi
>
># The GRUB boot sector always starts with a JMP instruction.
>initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
> head -n1 | cut -d' ' -f2,3)"
>[ "$initial_jmp" ] || return 1
>initial_jmp_opcode="${initial_jmp%% *}"
>[ "$initial_jmp_opcode" = eb ] || return 1
>initial_jmp_operand="${initial_jmp#* }"
>case $initial_jmp_operand in
> 47|4b|4c|63)
># I believe this covers all versions of GRUB 2 up to the package
># version where we gained a more explicit mechanism. GRUB Legacy
># always had 48 here.
>return 0
> ;;
>esac
>
>return 1
> }
>
>The actual package version does get embedded in the boot loader, but
>only in the "normal" module, not anywhere that could be usefully
>discovered by a scan. Otherwise the best we could do would basically be
>a big list of signatures, which I'm not enthusiastic about.
Argh, yes. Basically what I expected, I'll be honest. Oh, hmmm -
that's the boot sector. Could we pick up on more from the embedded
binary "stage 1.5" lump? This is getting hairy, maybe, but
could/should be a wider thing to go upstream?
>> * For UEFI, I'd love to switch to using the monolithic GRUB image
>>even for non-signed use. It makes a lot of the issues go away if
>>~all the modules necessary for boot are always built-in.
>
>I think I agree, though we should take that to a separate bug; I'd like
>to keep this one for the BIOS situation.
Agreed. Just something I thought to mention while it was in my
head. :-)
>> * Finally, we should also stop using debconf as a registry like we
>>are. It's annoying the DSA folks (at least). By all means use
>>debconf to help manage things, but we should be storing the lasting
>>config in a config file that people can edit. We already store some
>>of our stuff in /etc/default/grub, let's push more of our config
>>there?
>
>Agreed in general terms; this has been on my to-do list for a long time.
>Of course we need to consider the migration pat
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
On Fri, Jul 31, 2020 at 11:49:06PM +0100, Colin Watson wrote: ... >It looks like the base VM image provided by bento/debian-10 hardcodes >some details of how it was built that don't carry over to other systems >booting the same image, and this causes problems. > >debian/buster64 has a similar problem, but with different details. It >has: > > vagrant@buster:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices: > * grub-pc/install_devices: /dev/vda Ah! >> I'm using the (admittedly insecure) solution of "sudo apt-mark hold grub*" >> shown here: https://askubuntu.com/a/1263204 > >As several comments there note, a better fix is "sudo dpkg-reconfigure >grub-pc". Definitely! >This is in some ways the most interesting subtype of this bug, because >it's one we can easily reproduce! It falls into the category of "error >in a cloning process"; but it also makes it relatively straightforward >to experiment with ways to mitigate the problem further. > >We could at minimum make this be an upgrade error in the noninteractive >case, ensuring that it doesn't touch modules if the target device is >just plain missing: the upgrade error might be a bit rough for some >people, but it would be better than a boot failure. > >A refinement of this might be that if the system only has one disk, and >that disk appears to have GRUB installed on it (by relatively crude boot >sector scanning), then we could assume that this is the common case of a >disk having been swapped out and automatically change >grub-pc/install_devices to point to that instead. With appropriate >guard rails, I think that could help quite a lot of the people affected >by this sort of problem. Yes, definitely. Let's have a chat about how to do stuff. I was thinking about some topics here: * Do we need to scan? if grub is installed and doing an upgrade and there is only one disk of an appropriate type (BIOS with DOS, or UEFI with GPT), then always install there? * (Maybe) we could add an option for grub-pc to always grub-install to *all* the BIOS-visible disks? Yes, I know there's a potential for breakage there with multi-boot systems. Maybe only do this on systems where os-prober has not found anything but the Debian installation? * If we do add the code to scan boot sectors, maybe check all the BIOS-visible disks and flag any that look like they have GRUB, but are not our version? (Not sure how feasible this is without digging!) * For UEFI, I'd love to switch to using the monolithic GRUB image even for non-signed use. It makes a lot of the issues go away if ~all the modules necessary for boot are always built-in. * Finally, we should also stop using debconf as a registry like we are. It's annoying the DSA folks (at least). By all means use debconf to help manage things, but we should be storing the lasting config in a config file that people can edit. We already store some of our stuff in /etc/default/grub, let's push more of our config there? -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Bug#966575: Security update can break grub - grub_calloc not found
On Fri, Jul 31, 2020 at 03:07:58PM +0100, Geoff Gibbs wrote: >On Fri, 31 Jul 2020 14:30:14 +0100 >Steve McIntyre wrote: > >> I'm guessing - do you have multiple disks on your system? If so, try >> "grub-install " on each of the bootable disks and that should >> fix your problem. > >As I mentioned, > >mount /dev/sda5 /mnt >grub-install --boot-directory=/mnt /dev/sda > >has fixed the problem for me. Yup. Sorry - I saw that. Trying to respond to lots of people atm... >fdisk -l reports :- > >Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors >Disk model: Corsair Force GS >Units: sectors of 1 * 512 = 512 bytes >Sector size (logical/physical): 512 bytes / 512 bytes >I/O size (minimum/optimal): 512 bytes / 512 bytes >Disklabel type: dos >Disk identifier: 0xc1920bad > >Device Boot Start End Sectors Size Id Type >/dev/sda1 * 2048206847204800 100M 7 HPFS/NTFS/exFAT >/dev/sda2 210942 468860927 468649986 223.5G 5 Extended >/dev/sda5 210944722943512000 250M 83 Linux >/dev/sda6 724992 468860927 468135936 223.2G 8e Linux LVM > > >Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors >Disk model: WDC WD10EZRX-00A >Units: sectors of 1 * 512 = 512 bytes >Sector size (logical/physical): 512 bytes / 4096 bytes >I/O size (minimum/optimal): 4096 bytes / 4096 bytes >Disklabel type: dos >Disk identifier: 0xc1920ba9 > >Device Boot StartEndSectors Size Id Type >/dev/sdb1 * 2048 209717247 209715200 100G 7 HPFS/NTFS/exFAT >/dev/sdb2 209721342 1953523711 1743802370 831.5G 5 Extended >/dev/sdb5 209721344 230201343 2048 9.8G 82 Linux swap / Solaris >/dev/sdb6 230203392 1953523711 1723320320 821.8G 8e Linux LVM > >Partition 2 does not start on physical sector boundary. > >And then there is a list of partitions handled by LVM (many for Xen) >but including :- > >Disk /dev/mapper/SSD0-root: 20 GiB, 21474836480 bytes, 41943040 sectors >Units: sectors of 1 * 512 = 512 bytes >Sector size (logical/physical): 512 bytes / 512 bytes >I/O size (minimum/optimal): 512 bytes / 512 bytes > >Disk /dev/mapper/HDD0-var: 9.3 GiB, 220736 bytes, 19529728 sectors >Units: sectors of 1 * 512 = 512 bytes >Sector size (logical/physical): 512 bytes / 4096 bytes >I/O size (minimum/optimal): 4096 bytes / 4096 bytes > >Disk /dev/mapper/SSD0-home: 38.6 GiB, 41473277952 bytes, 81002496 sectors >Units: sectors of 1 * 512 = 512 bytes >Sector size (logical/physical): 512 bytes / 512 bytes >I/O size (minimum/optimal): 512 bytes / 512 bytes ACK. I tend to do "fdisk -l /dev/sd?" to avoid that behaviour on my md/lvm machine here. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#966575: grub-pc: error: symbol `grub_calloc' not found
Hi John, On Fri, Jul 31, 2020 at 09:29:43AM +0100, John Lines wrote: >I have the same error, on a DNUK Workstar 700, dating back to 2014, so >upgraded from squeeze on up to buster.It is possible this legacy which >has resulted in something unusual in the grub configuration. > >I upgraded grub yesterday, and am working on recovering now. Posting >from another system. ACK. Same thing applies as I suggested to Paul - maybe an inconsistent set of updates. Do you have multiple disks? If so, try "grub-install " on all the bootable disks and that may fix your problem. If not, please get back to us ASAP and we'll try to debug the problem here. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#966575: Security update can break grub - grub_calloc not found
Hi Geoff, On Fri, Jul 31, 2020 at 11:54:20AM +0100, Geoff Gibbs wrote: >apt update >apt full-upgrade > >grub upgrades > >from 2.02+dfsg1-20 >to 2.02+dfsg1-20+deb10u1 > >no errors were spotted. > >When rebooted :- > >symbol grub_calloc not found >Entering rescue mode >grub rescue> > > >I had to boot off a memory stick and then :- > >sudo -i >mount /dev/sda5 /mnt >grub-install --boot-directory=/mnt /dev/sda >reboot > >This worked and the system now boots. > >/boot is the only ext type file system, the others are all handled by LVM I'm guessing - do you have multiple disks on your system? If so, try "grub-install " on each of the bootable disks and that should fix your problem. I think we need a proper fix for this in the longer term, but that's not going to happen overnight. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#966575: I was affected as well
Hi Norbert, On Thu, Jul 30, 2020 at 11:26:15PM -0700, Norbert Kiesel wrote: >This is a laptop running Debain Unstable with 2 SSD and one spinning disk. >After upgrade and install, system stopped with same error message during boot. > >I was able to reactivate using a live boot system. ACK. Same thing applies as I suggested to Paul - maybe an inconsistent set of updates. Have you *fixed* the problem by using the live boot? -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
Hi Paul, On Fri, Jul 31, 2020 at 06:39:20AM +0200, Paul Menzel wrote: >Am 31.07.20 um 06:30 schrieb Paul Menzel: > >> Am 30.07.20 um 23:54 schrieb Paul Menzel: >> > Package: grub-pc >> > Version: 2.04-9 >> > Severity: grave >> >> > On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the >> > package `grub-pc` causes GRUB to fail on next boot and drop into a >> > rescue shell. >> > >> > GRUB loading. >> > Welcome to GRUB! >> > >> > error: symbol 'grub_calloc' not found. >> > grub rescue> >> > >> > It only seems to effects MBR installation. >> >> I missed to report, that the system has a separate `/boot` partition and >> a LUKS encrypted root `/`. > >Sorry, please scratch that. I remembered incorrectly. It’s just one >unencrypted F2FS formatted partition. How many disks do you have on your system, please? *If* you have more than one, there's a potential for grub-install to have not been run to install grub to all the MBRs, and then the BIOS finds an old copy of the GRUB first-stage loader but tries to use newer modules. this mis-match can cause all kinds of problems. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Bug#933031: pristine-tar: unable to unpack some deltas of version 2
Control: tags -1 +patch
On Tue, Jul 28, 2020 at 04:17:08PM +0100, Steve McIntyre wrote:
>Control: severity -1 grave
...
>IMHO this has to be a grave bug - without reimporting this repo we
>can't get our older revisions back. Then I'm worried that this will
>break things if we need to go back and rebuild older versions (using
>older tooling). pristine-tar needs to be safe for data here. :-(
>
>I've done a git bisect of the pristine-tar repo to see where things
>broke, and that clearly tells me:
>
>...
>f287f10b48c3ca5a30db13dbf3ba918c47a943bb is the first bad commit
>commit f287f10b48c3ca5a30db13dbf3ba918c47a943bb
>Author: Tomasz Buchert
>Date: Fri Jan 13 23:28:04 2017 +0100
>
>fix #851286
>
>:100755 100755 1a34e953ba363ae1e284b97f83f63f6ef80ea544
>3ba76f79d376d011451b8c572b20e185b715bed1 M pristine-tar
>:04 04 84bc809be6b4dcf81cfce71f0550858957a3e92f
>f8eb72beb458cbd9770f88f0f4efc00f0c75a299 M test
>bisect run success
>...
>
>I hope that helps the maintainers - shout if you'd like more help debugging.
I've carried on and looked at the code. The attached patch makes
things work for me, at the expense of YA thing added to the @try
loop. But I'll take that over failure!
Having looked at this code a little, I'm now also a little concerned
about the way the fallbacks work, i.e. applied one at a time
independently. I'm thinking that there could well be cases where a
stored tarball might need more than one of the workaround/retry
options. Maybe I'm over-thinking it.
Also submitted this as an MR:
https://salsa.debian.org/debian/pristine-tar/-/merge_requests/7
in case you'd prefer that.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"
diff --git a/pristine-tar b/pristine-tar
index 0fe132e..081dca1 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -560,6 +560,33 @@ sub recreatetarball_broken_numeric_owner {
return recreatetarball_helper();
}
+sub recreatetarball_broken_verbatim {
+ # To fix #851286, the option --verbatim-files-from was added by
+ # default. But now some older older stored tarballs won't reproduce
+ # (#933031). Try again *without* that option to tar.
+ my %options = @_;
+ my $tempdir = $recreatetarball_tempdir;
+
+ my $ret = "$tempdir/recreatetarball";
+ my @cmd = (
+$tar_program, "cf",
+$ret, "--owner",
+0,"--group",
+0,"--numeric-owner",
+"-C", "$tempdir/workdir",
+"--no-recursion", "--mode",
+"0644",
+"--files-from", "$tempdir/manifest"
+ );
+ if (exists $options{tar_format}) {
+push @cmd, ("-H", $options{tar_format});
+ }
+
+ doit(@cmd);
+
+ return $ret;
+}
+
sub gentar {
my $deltafile = shift;
my $tarball = shift;
@@ -614,6 +641,7 @@ sub gentar {
%opts
);
};
+ push @try, \_broken_verbatim;
push @try, \_broken_numeric_owner;
my $ok;
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
On Fri, Jun 26, 2020 at 10:29:28AM -0700, John Johansen wrote:
>On 6/26/20 9:50 AM, Steve McIntyre wrote:
>>
>> OK, will try that second...
>>
>
>I have not been able to reproduce but
>
>So looking at linux-4.19.y it looks like
>1f8266ff5884 apparmor: don't try to replace stale label in ptrace access check
>
>was picked without
>ca3fde5214e1 apparmor: don't try to replace stale label in ptraceme check
>
>Both of them are marked as
>Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
>
>so I would expect them to be picked together.
>
>ptraceme is potentially updating the task's cred while the access check is
>running.
>
>Try building after picking
>ca3fde5214e1 apparmor: don't try to replace stale label in ptraceme check
Bingo! With that one change the test suite runs to completion, no lockup.
\o/
Thanks guys, I think we've found the cause here.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, and wiser people so full of doubts."
-- Bertrand Russell
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hi again, On Fri, Jun 26, 2020 at 05:50:00PM +0100, Steve McIntyre wrote: >On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote: >>On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote: >>> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: > >... > >>> > Considering I'm running strace build tests to provoke this bug, >>> > finding the failure in a commit talking about ptrace changes does look >>> > very suspicious...! >>> > >>> > Annoyingly, I can't reproduce this on my disparate other machines >>> > here, suggesting it's maybe(?) timing related. >> >>Does "hard lockup" mean that the HARDLOCKUP_DETECTOR infrastructure >>prints a warning to dmesg? If so, can you share that warning? > >I mean the machine locks hard - X stops updating, the mouse/keyboard >stop responding. No pings, etc. When I reboot, there's nothing in the >logs. > >>If you don't have any way to see console output, and you don't have a >>working serial console setup or such, you may want to try re-running >>those tests while the kernel is booted with netconsole enabled to log >>to a different machine over UDP (see >>https://www.kernel.org/doc/Documentation/networking/netconsole.txt). > >ACK, will try that now for you. > >>You may want to try setting the sysctl kernel.sysrq=1 , then when the >>system has locked up, press ALT+PRINT+L (to generate stack traces for >>all active CPUs from NMI context), and maybe also ALT+PRINT+T and >>ALT+PRINT+W (to collect more information about active tasks). > >Nod. > >>(If you share stack traces from these things with us, it would be >>helpful if you could run them through scripts/decode_stacktrace.pl >>from the kernel tree first, to add line number information.) > >ACK. Output passed through scripts/decode_stacktrace.sh attached. Just about to try John's suggestion next. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject tack.log.decoded.gz Description: application/gzip
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hi Jann, On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote: >On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote: >> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: ... >> > Considering I'm running strace build tests to provoke this bug, >> > finding the failure in a commit talking about ptrace changes does look >> > very suspicious...! >> > >> > Annoyingly, I can't reproduce this on my disparate other machines >> > here, suggesting it's maybe(?) timing related. > >Does "hard lockup" mean that the HARDLOCKUP_DETECTOR infrastructure >prints a warning to dmesg? If so, can you share that warning? I mean the machine locks hard - X stops updating, the mouse/keyboard stop responding. No pings, etc. When I reboot, there's nothing in the logs. >If you don't have any way to see console output, and you don't have a >working serial console setup or such, you may want to try re-running >those tests while the kernel is booted with netconsole enabled to log >to a different machine over UDP (see >https://www.kernel.org/doc/Documentation/networking/netconsole.txt). ACK, will try that now for you. >You may want to try setting the sysctl kernel.sysrq=1 , then when the >system has locked up, press ALT+PRINT+L (to generate stack traces for >all active CPUs from NMI context), and maybe also ALT+PRINT+T and >ALT+PRINT+W (to collect more information about active tasks). Nod. >(If you share stack traces from these things with us, it would be >helpful if you could run them through scripts/decode_stacktrace.pl >from the kernel tree first, to add line number information.) ACK. >Trying to isolate the problem: > >__end_current_label_crit_section and end_current_label_crit_section >are aliases of each other (via #define), so that line change can't >have done anything. > >That leaves two possibilities AFAICS: > - the might_sleep() call by itself is causing issues for one of the >remaining users of begin_current_label_crit_section() (because it >causes preemption to happen more often where it didn't happen on >PREEMPT_VOLUNTARY before, or because it's trying to print a warning >message with the runqueue lock held, or something like that) > - the lack of "if (aa_replace_current_label(label) == 0) >aa_put_label(label);" in __begin_current_label_crit_section() is >somehow causing issues > >You could try to see whether just adding the might_sleep(), or just >replacing the begin_current_label_crit_section() call with >__begin_current_label_crit_section(), triggers the bug. > > >If you could recompile the kernel with CONFIG_DEBUG_ATOMIC_SLEEP - if >that isn't already set in your kernel config -, that might help track >down the problem, unless it magically makes the problem stop >triggering (which I guess would be conceivable if this indeed is a >race). OK, will try that second... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
On Fri, Jun 26, 2020 at 02:45:18PM +0100, Steve McIntyre wrote: >Hey Greg, > >On Fri, Jun 26, 2020 at 03:41:32PM +0200, Greg KH wrote: >>On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: >>> >>> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit >>> commit e58f543fc7c0926f31a49619c1a3648e49e8d233 >>> Author: Jann Horn >>> Date: Thu Sep 13 18:12:09 2018 +0200 > >... > >>> Annoyingly, I can't reproduce this on my disparate other machines >>> here, suggesting it's maybe(?) timing related. >>> >>> Hope this helps - happy to give more information, test things, etc. >> >>So if you just revert this one patch, all works well? > >Correct. > >>I've added the authors of the patch to the cc: list... >> >>Also, does this problem happen on Linus's tree? > >Just building to check that now... Current head here (3e08a95294a4fb3702bb3d35ed08028433c37fe6) works fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hey Greg, On Fri, Jun 26, 2020 at 03:41:32PM +0200, Greg KH wrote: >On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote: >> >> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit >> commit e58f543fc7c0926f31a49619c1a3648e49e8d233 >> Author: Jann Horn >> Date: Thu Sep 13 18:12:09 2018 +0200 ... >> Annoyingly, I can't reproduce this on my disparate other machines >> here, suggesting it's maybe(?) timing related. >> >> Hope this helps - happy to give more information, test things, etc. > >So if you just revert this one patch, all works well? Correct. >I've added the authors of the patch to the cc: list... > >Also, does this problem happen on Linus's tree? Just building to check that now... -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards
Hi folks,
I'm the maintainer in Debian for strace. Trying to reproduce
https://bugs.debian.org/963462 on my machine (Thinkpad T470), I've
found a repeatable hard lockup running the strace testsuite. Each time
it seems to have failed in a slightly different place in the testsuite
(suggesting it's not one particular syscall test that's triggering the
failure). I initially found this using Debian's current Buster kernel
(4.19.118+2+deb10u1), then backtracking I found that 4.19.98+1+deb10u1
worked fine.
I've bisected to find the failure point along the linux-4.19.y stable
branch and what I've got to is the following commit:
e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
commit e58f543fc7c0926f31a49619c1a3648e49e8d233
Author: Jann Horn
Date: Thu Sep 13 18:12:09 2018 +0200
apparmor: don't try to replace stale label in ptrace access check
[ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
As a comment above begin_current_label_crit_section() explains,
begin_current_label_crit_section() must run in sleepable context because
when label_is_stale() is true, aa_replace_current_label() runs, which uses
prepare_creds(), which can sleep.
Until now, the ptrace access check (which runs with a task lock held)
violated this rule.
Also add a might_sleep() assertion to begin_current_label_crit_section(),
because asserts are less likely to be ignored than comments.
Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
Signed-off-by: Jann Horn
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
:04 04 ca92f885a38c1747b812116f19de6967084a647e
865a227665e460e159502f21e8a16e6fa590bf50 M security
Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
Annoyingly, I can't reproduce this on my disparate other machines
here, suggesting it's maybe(?) timing related.
Hope this helps - happy to give more information, test things, etc.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
kittens, except the kittens randomly appear and disappear because they
have day jobs." -- Matt Mackall
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
OK, so I've just bisected down the stable 4.19.y branch from 4.19.98
to 4.19.118. What I've found is:
e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
commit e58f543fc7c0926f31a49619c1a3648e49e8d233
Author: Jann Horn
Date: Thu Sep 13 18:12:09 2018 +0200
apparmor: don't try to replace stale label in ptrace access check
[ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
As a comment above begin_current_label_crit_section() explains,
begin_current_label_crit_section() must run in sleepable context because
when label_is_stale() is true, aa_replace_current_label() runs, which uses
prepare_creds(), which can sleep.
Until now, the ptrace access check (which runs with a task lock held)
violated this rule.
Also add a might_sleep() assertion to begin_current_label_crit_section(),
because asserts are less likely to be ignored than comments.
Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
Signed-off-by: Jann Horn
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
:04 04 ca92f885a38c1747b812116f19de6967084a647e
865a227665e460e159502f21e8a16e6fa590bf50 M security
Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
On Wed, Jun 24, 2020 at 05:39:38PM +0100, Steve McIntyre wrote:
>On Wed, Jun 24, 2020 at 05:57:42PM +0200, Salvatore Bonaccorso wrote:
>>Control: found -1 4.19.118-1
>>Control: tags -1 + upstream
>>
>>>
>>> As I can reproduce this quite easily, I'm happy to help with whatever
>>> debugging might be useful.
>>
>>This sounds familiar to
>>https://lore.kernel.org/stable/7231ea1a-70b2-c156-1724-2357ed10b...@intel.com/
>>
>>d3ec10aa9581 ("KEYS: Don't write out to userspace while holding key
>>semaphore") was backported to v4.19.y in 4.19.118. The issue seems to
>>be fixed with 4f0882491a14 ("KEYS: Avoid false positive ENOMEM error
>>on key read") which was backported to 4.19.119.
>>
>>Can you check if cherry-picking the above commit
>>(e4a281c7daa07814748179ee8b4b483124bb94ea in the linux-4.19.y) fixes
>>the issue?
>
>Sure, building it now to test.
Unfortunately, no joy. :-( Same lockup at a random point in the test
suite.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
Hey Salvatore! On Wed, Jun 24, 2020 at 05:57:42PM +0200, Salvatore Bonaccorso wrote: >Control: found -1 4.19.118-1 >Control: tags -1 + upstream > >Hi Steve, > >On Mon, Jun 22, 2020 at 12:58:35PM +0100, Steve McIntyre wrote: >> Source: linux >> Version: 4.19.118-2+deb10u1 >> Severity: serious >> >> Hi folks, >> >> Trying to reproduce #963462 on my Thinkpad T470, I'm repeatedly >> getting a hard lockup running the strace testsuite. I've done this 4 >> times to be sure. Each time it seems to have failed in a slightly >> different place in the testsuite (suggesting it's not one particular >> syscall test that's triggering the failure). Only one of the 4 lockups >> left eny evidence in the logs (reproduced below), so I'm not sure if >> the error here is actually the root of the problem or not. :-/ >> >> The machine is not noticeably running hot or anything while doing >> these tests. >> >> Rebooting back to 4.19.0-8-amd64 (aka 4.9.98+1+deb10u1), I've just run >> the same testsuite twice in a row and it ran to completion with no >> lockup. >> >> Here's the one bit of log that I did get, in case it's useful. >> >> Jun 22 11:36:49 tack kernel: [ 318.195906] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195910] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195971] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195974] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195977] futex_wake_op: futex tries to >> shift op by -1; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.195979] futex_wake_op: futex tries to >> shift op by -1; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199661] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199674] futex_wake_op: futex tries to >> shift op by -849; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199917] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.199982] futex_wake_op: futex tries to >> shift op by -518; fix this program >> Jun 22 11:36:49 tack kernel: [ 318.398755] L1TF CPU bug present and SMT on, >> data leak possible. See CVE-2018-3646 and >> https://www.kernel.org/doc/html/latest/admin-gui >> de/hw-vuln/l1tf.html for details. >> Jun 22 11:36:49 tack kernel: [ 318.587324] WARNING: CPU: 2 PID: 32174 at >> mm/page_alloc.c:4385 __alloc_pages_nodemask+0x241/0x2b0 >> Jun 22 11:36:49 tack kernel: [ 318.587326] Modules linked in: acpi_call(OE) >> ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter >> nft_chain_nat_ipv4 nf_ >> nat_ipv4 xt_addrtype nft_compat xt_conntrack nf_nat nf_conntrack >> nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp overlay devlink >> cpufreq_userspace cpufreq_conser >> vative cpufreq_powersave ipmi_devintf ipmi_msghandler nf_tables nfnetlink >> appletalk psnap llc ax25 pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) >> vboxdrv(OE) cmac >> bnep fuse binfmt_misc pktcdvd snd_hda_codec_hdmi btusb btrtl btbcm btintel >> bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 >> videobuf2_common snd_hd >> a_codec_realtek snd_hda_codec_generic videodev media drbg ansi_cprng >> ecdh_generic nls_ascii nls_cp437 vfat fat arc4 intel_rapl snd_soc_skl msr >> snd_soc_skl_ipc snd_soc_ >> sst_ipc >> Jun 22 11:36:49 tack kernel: [ 318.587344] snd_soc_sst_dsp >> x86_pkg_temp_thermal intel_powerclamp snd_hda_ext_core coretemp >> snd_soc_acpi_intel_match iwlmvm snd_soc_ac >> pi kvm_intel snd_soc_core mac80211 snd_compress wmi_bmof i915 snd_hda_intel >> iwlwifi kvm snd_hda_codec snd_h >> da_core irqbypass snd_hwdep evdev intel_cstate joydev snd_pcm_oss >> drm_kms_helper intel_uncore serio_raw intel_rapl_perf mei_me snd_mixer_oss >> cfg80211 sg efi_pstore drm pcspkr mei efivars snd_pcm ucsi_acpi snd_timer >> typec_ucsi i2c_algo_bit iTCO_wdt iTCO_vendor_support intel_pch_thermal typec >> thinkpad_acpi tpm_crb wmi nvram snd soundcore tpm_tis rfkill video >> tpm_tis_core battery pcc_cpufreq ac tpm rng_core acpi_pad button parport_pc >> nfsd ppdev auth_rpcgss lp nfs_acl lockd grace sunrpc parport efivarfs >> ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic >> Jun 22 11:36:49 tack kernel: [ 318.587362] fscrypto ecb btrfs
Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine
Source: linux Version: 4.19.118-2+deb10u1 Severity: serious Hi folks, Trying to reproduce #963462 on my Thinkpad T470, I'm repeatedly getting a hard lockup running the strace testsuite. I've done this 4 times to be sure. Each time it seems to have failed in a slightly different place in the testsuite (suggesting it's not one particular syscall test that's triggering the failure). Only one of the 4 lockups left eny evidence in the logs (reproduced below), so I'm not sure if the error here is actually the root of the problem or not. :-/ The machine is not noticeably running hot or anything while doing these tests. Rebooting back to 4.19.0-8-amd64 (aka 4.9.98+1+deb10u1), I've just run the same testsuite twice in a row and it ran to completion with no lockup. Here's the one bit of log that I did get, in case it's useful. Jun 22 11:36:49 tack kernel: [ 318.195906] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.195910] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.195971] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.195974] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.195977] futex_wake_op: futex tries to shift op by -1; fix this program Jun 22 11:36:49 tack kernel: [ 318.195979] futex_wake_op: futex tries to shift op by -1; fix this program Jun 22 11:36:49 tack kernel: [ 318.199661] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.199674] futex_wake_op: futex tries to shift op by -849; fix this program Jun 22 11:36:49 tack kernel: [ 318.199917] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.199982] futex_wake_op: futex tries to shift op by -518; fix this program Jun 22 11:36:49 tack kernel: [ 318.398755] L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-gui de/hw-vuln/l1tf.html for details. Jun 22 11:36:49 tack kernel: [ 318.587324] WARNING: CPU: 2 PID: 32174 at mm/page_alloc.c:4385 __alloc_pages_nodemask+0x241/0x2b0 Jun 22 11:36:49 tack kernel: [ 318.587326] Modules linked in: acpi_call(OE) ipt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter nft_chain_nat_ipv4 nf_ nat_ipv4 xt_addrtype nft_compat xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp overlay devlink cpufreq_userspace cpufreq_conser vative cpufreq_powersave ipmi_devintf ipmi_msghandler nf_tables nfnetlink appletalk psnap llc ax25 pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) cmac bnep fuse binfmt_misc pktcdvd snd_hda_codec_hdmi btusb btrtl btbcm btintel bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_hd a_codec_realtek snd_hda_codec_generic videodev media drbg ansi_cprng ecdh_generic nls_ascii nls_cp437 vfat fat arc4 intel_rapl snd_soc_skl msr snd_soc_skl_ipc snd_soc_ sst_ipc Jun 22 11:36:49 tack kernel: [ 318.587344] snd_soc_sst_dsp x86_pkg_temp_thermal intel_powerclamp snd_hda_ext_core coretemp snd_soc_acpi_intel_match iwlmvm snd_soc_ac pi kvm_intel snd_soc_core mac80211 snd_compress wmi_bmof i915 snd_hda_intel iwlwifi kvm snd_hda_codec snd_h da_core irqbypass snd_hwdep evdev intel_cstate joydev snd_pcm_oss drm_kms_helper intel_uncore serio_raw intel_rapl_perf mei_me snd_mixer_oss cfg80211 sg efi_pstore drm pcspkr mei efivars snd_pcm ucsi_acpi snd_timer typec_ucsi i2c_algo_bit iTCO_wdt iTCO_vendor_support intel_pch_thermal typec thinkpad_acpi tpm_crb wmi nvram snd soundcore tpm_tis rfkill video tpm_tis_core battery pcc_cpufreq ac tpm rng_core acpi_pad button parport_pc nfsd ppdev auth_rpcgss lp nfs_acl lockd grace sunrpc parport efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic Jun 22 11:36:49 tack kernel: [ 318.587362] fscrypto ecb btrfs zstd_decompress zstd_compress xxhash algif_skcipher af_alg sr_mod cdrom uas usb_storage dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci aesni_intel libahci aes_x86_64 crypto_simd libata cryptd xhci_pci glue_helper xhci_hcd e1000e psmouse scsi_mod usbcore i2c_i801 thermal usb_common Jun 22 11:36:49 tack kernel: [ 318.587375] CPU: 2 PID: 32174 Comm: keyctl Tainted: G OE 4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1 Jun 22 11:36:49 tack kernel: [ 318.587376] Hardware name: LENOVO 20HD000EUK/20HD000EUK, BIOS N1QET67W (1.42 ) 10/03/2017 Jun 22 11:36:49 tack kernel: [ 318.587377] RIP: 0010:__alloc_pages_nodemask+0x241/0x2b0 Jun 22 11:36:49 tack kernel: [ 318.587379] Code: 89 f7 89 ee 45 31 f6 e8 4d d5 ff ff e9 fb fe ff ff e8 73 ae 01 00 e9 cb
Bug#958722: grub-efi-amd64-signed - Uninstallable
Hey Bastian, This is already fixed in the latest 2.04-7 grub2 upload. I'll mark this closed when the signing service pulls stuff through. On Fri, Apr 24, 2020 at 07:58:26PM +0200, Bastian Blank wrote: >Package: grub-efi-amd64-signed >Version: 1+2.04+5 >Severity: grave > >grub-efi-amd64-signed got a strict = dependency on grub-common, but >those packages are from different source packages. This makes this >package uninstallable. > >| The following information may help to resolve the situation: >| >| The following packages have unmet dependencies: >| grub-efi-amd64-signed : Depends: grub-common (= 2.04-6) but it is not going >to be installed >| E: Unable to correct problems, you have held broken packages. > >Please fix this by removing those strict dependency or move both >packages into a single source package. You know we can't have it all in a single source package, right? -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
