Bug#1041884: sct: segfault at e0

[Alejandro Colomar]

Package: sct
Version: 1.3-1+b1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi!

I'm not sure if this is a problem with sct(1), but I got an error that
mentions sct, so I'm reporting here in case it's related to sct(1).

Here's the error message as reported by dmesg:

$ sudo dmesg | tail -n2
[  432.416640] sct[3477]: segfault at e0 ip 555a975ee0fd sp 
7ffe887af340 error 4 in sct[555a975ee000+1000] likely on CPU 1 (core 1, 
socket 0)
[  432.416669] Code: 2f 00 00 66 90 00 00 00 00 00 00 00 00 41 57 41 56 41 55 
49 89 f5 41 54 55 53 89 fb 31 ff 48 83 ec 28 e8 86 ff ff ff 48 89 c5 <48> 63 80 
e0 00 00 00 48 89 ef 48 c1 e0 07 48 03 85 e8 00 00 00 48

My computer got a black screen where the only thing I could do is
REISUB.  It had a few problems booting after that for a few times.  I'm
still unsure about the cause, but this is the most notable error report
I've seen.

I have `sct 3000` in my .bash_aliases, so that just by opening a
terminal I get a nice screen temperature.  It has worked for a long
time...

Cheers,
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sct depends on:
ii  libc6   2.37-6
ii  libx11-62:1.8.6-1
ii  libxrandr2  2:1.5.2-2+b1

sct recommends no packages.

sct suggests no packages.

-- no debconf information

Bug#1041884: Acknowledgement (sct: segfault at e0)

[Alejandro Colomar]

Never mind.  My filesystem was full.  That was my problem.  I wrote
a program with an accidental infinite loop, and while debugging it,
a printf line started writing lines to somewhere in /opt, and I
forgot to kill it before writing 1 TB of garbage. :-)

Cheers,
Alex

On 2023-07-24 22:21, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1041884: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041884.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   alx.manpa...@gmail.com
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  Jacob Adams 
> 
> If you wish to submit further information on this problem, please
> send it to 1041...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027793: closed by Debian FTP Masters (reply to James McCoy ) (Bug#1027766: fixed in vim 2:9.0.1000-3)

[Alejandro Colomar]

Hi,

On 1/3/23 17:09, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the vim-common package:

#1027793: vim: insert mode: Backspace doesn't do anything

It has been closed by Debian FTP Masters  (reply to 
James McCoy ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to James McCoy ) 
by
replying to this email.



For my own curiosity, would you mind pointing to the specific change that fixed 
this bug?


Thanks,

Alex





--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32

[Alejandro Colomar]

Package: cppcheck
Version: 2.6-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: colomar.6@gmail.com

Dear Maintainer,

I installed and run cppcheck on a system which I had not used for half a year.
For that reason, many of its packages were outdated.

glibc was on version 2.31.

When I run cppcheck, it failed with the following error:

cppcheck: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found 
(required by cppcheck)

I found the following dependencies' information:

$ apt-rdepends cppcheck | head -n2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
cppcheck
  Depends: libc6 (>= 2.29)


So it clearly is incorrect, AFAICS.
It should declare a dependency for libc6 2.32


Regards,
Alex


P.S.:
You'll find below that my installed libc6 is 2.32;
that's because I updated it to be able to use checkpatch,
prior to sending this bug report.
Please ignore that.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cppcheck depends on:
ii  libc6 2.32-4
ii  libgcc-s1 11.2.0-10
ii  libpcre3  2:8.39-13
ii  libstdc++611.2.0-10
ii  libtinyxml2-9 9.0.0+dfsg-3
ii  libz3-4   4.8.12-1+b1
iu  python3   3.9.8-1
ii  python3-pygments  2.7.1+dfsg-2.1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
ii  clang 1:11.0-51+nmu5
ii  clang-tidy1:11.0-51+nmu5
pn  cppcheck-gui  

-- no debconf information

Bug#1014003: iwyu 0.18 requires clang-14

[Alejandro Colomar]

Package: iwyu
Version: 8.18-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

iwyu 0.18 requires clang 14 to work, as specified on their documentation.
Having an older version of clang causes iwyu to fail for the most basic
stuff, such as finding compiler builtin headers (e.g., ).

Just by installing the correct clang version, the problem was fixed
(I'm not sure if installing a clang library, without installing the full
clang would have been enough, though).

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages iwyu depends on:
ii  clang   1:13.0-54
ii  clang-111:11.1.0-6+b2
ii  clang-131:13.0.1-6
ii  clang-141:14.0.6-1
ii  libc6   2.33-7
ii  libclang-cpp14  1:14.0.6-1
ii  libllvm14   1:14.0.6-1
ii  libstdc++6  12.1.0-4
ii  python3 3.10.4-1+b1

iwyu recommends no packages.

iwyu suggests no packages.

-- no debconf information

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Package: glibc-doc
Version: 2.38-6
Severity: serious
Justification: Policy 7.4
X-Debbugs-Cc: a...@kernel.org, mar...@debian.org

Dear Maintainer,

The Linux man-pages project has recently added the pthread_*(3) manual
pages that were provided by glibc-doc.  The first upstream version of
the Linux man-pages that includes these pages is man-pages-6.06.  Here's
what was added:

$ git diff --stat b06cd070f..128a3ae35
 man3/pthread_cond_init.3| 264 
 man3/pthread_condattr_init.3|  48 
 man3/pthread_key_create.3   | 178 +
 man3/pthread_mutex_init.3   | 241 ++
 man3/pthread_mutexattr_setkind_np.3 |  52 
 man3/pthread_once.3 |  44 
 6 files changed, 827 insertions(+)

Debian's manpages-dev_6.7-1_all.deb has been the first package since
that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
upgrade manpages-dev due to a conflict with glibc-doc.

$ sudo apt-get upgrade -V;
[...]
Do you want to continue? [Y/n] y
Reading changelogs... Done
(Reading database ... 404853 files and directories currently installed.)
Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
which is also in package glibc-doc 2.38-6
Errors were encountered while processing:
 /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Please, remove from glibc-doc those manual pages that conflict with
manpages-dev.

Marcos, you'll also need to specify a breaks with glibc-doc versions
up to (and including) 6.38-6 in the next revision of manpages-dev, and
drop 6.7-1.


Have a lovely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc7-alx-dirty (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

glibc-doc depends on no packages.

glibc-doc recommends no packages.

Versions of packages glibc-doc suggests:
ii  glibc-doc-reference  2.38-1

-- no debconf information

Bug#1068188: glibc-doc: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

On Mon, Apr 01, 2024 at 04:23:08PM +0200, Alejandro Colomar wrote:
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages that were provided by glibc-doc.  The first upstream version of
> the Linux man-pages that includes these pages is man-pages-6.06.  Here's
> what was added:
> 
>   $ git diff --stat b06cd070f..128a3ae35
>man3/pthread_cond_init.3| 264 
>man3/pthread_condattr_init.3|  48 
>man3/pthread_key_create.3   | 178 +
>man3/pthread_mutex_init.3   | 241 ++
>man3/pthread_mutexattr_setkind_np.3 |  52 
>man3/pthread_once.3 |  44 
>6 files changed, 827 insertions(+)

Here's the relevant excerpt of the git-log(1):

* 128a3ae35 pthread_key_create.3: Mention glibc instead of LinuxThreads
* 8a00cac75 pthread_*.3: ffix (semantic newlines)
* 74235f157 pthread_*.3: ffix (paragraphing)
* 13151ec52 pthread_*.3: Remove AUTHOR section; add copyright; adapt TH
* c1c253d0e pthread_cond_init.3, pthread_condattr_init.3, 
pthread_key_create.3, pthread_mutex_init.3, pthread_mutexattr_setkind_np.3, 
pthread_once.3: Update the glibc pages with the debian/glibc version of them
*   87183bb8e Import debian/local/manpages/pthread_*.3 git history from 
debian/glibc
|\  
| * 02d79c7d9   * Remove linuxthreads from the tarball: - 
rules.d/tarball.mk: don't fetech linuxthreads and linuxthreads_db. - 
rules.d/build.mk: don't build linuxthreads manpages. - rules: don't run 
make clean in linuxthreads directory. - patches/any/local-sysctl.diff: drop 
the linuxthreads part. - patches/all/local-pthread-manpages.diff: remove.   
  - local/manpages/pthread_*.3: import the few remaining linuxthreads   
manpages. - debhelper.in/glibc-doc.manpages: update manpage locations.
|/  
* a254db8b3 pthread_cond_init.3, pthread_condattr_init.3, 
pthread_key_create.3, pthread_mutex_init.3, pthread_mutexattr_setkind_np.3, 
pthread_once.3: Import pages from glibc
* 87d09778d Revert "linuxthreads, linuxthreads_db: Directories removed 
(preserved in ports repository)."
*   281f670a4 Import linuxthreads/man/ git history from glibc
|\  
| * a3db24d46 linuxthreads, linuxthreads_db: Directories removed 
(preserved in ports repository).
| * 2988d2724 (CFLAGS-tst-align.c): Add -mpreferred-stack-boundary=4.
| * f7f73b1ca 2.5-18.1
| * 67eceac09 Update.
| * 7ffaa96aa Update.
| * 869af9b6a Correct example.
| * 31b1e42d5 LinuxThreads library.
|/  

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi Sven,

On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote:
> Obviously the manpages-dev package should not have shipped these files
> as long as there are in glibc-doc; this is tracked in #1068166.

I CCed back in 2023-10 the debian-glibc@ list notifying that these pages
were absorbed into the Linux man-pages project.  They didn't respond.



However, the original author of the pages talked to me, agreeing to
that.  Other glibc upstream maintainers also participated in the thread.

> 
> > Please, remove from glibc-doc those manual pages that conflict with
> > manpages-dev.
> 
> Considering that the manpages in glibc-doc are not included upstream and

The history is a bit more complex than that.  They were originally
written upstream.  Then glibc removed them.  A decade later, Debian
added them back via a patch, with some modifications.  I noted down the
history in the discussion linked above.

> created via a Debian patch, that makes a lot of sense.  I was not aware
> of that fact.
> 
> > Marcos, you'll also need to specify a breaks with glibc-doc versions
> > up to (and including) 6.38-6 in the next revision of manpages-dev, and
> > drop 6.7-1.
> 
> Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
> because that version is only in experimental and will remain there for
> several weeks if not months.  I think manpages-dev should drop these

Why not add glibc-doc 2.38-7 dropping the patch that adds these pages?
We're not in a freeze, so I guess that's fair game.

> files for now and re-include either when glibc 2.38 is in unstable or
> when it is in testing.

Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
dropped?  Does 2.38 have any freeze at the moment?

> There is also the problem that some derivatives (most notably Ubuntu)
> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
> versions in manpages-dev accordingly.

Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
They have been unsupported for a long time.  The last change in
glibc-doc is from 2013.

> Thoughts?
> 
> Cheers,
>Sven

Have a lovely day!
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi Sven,

On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote:
> Makes perfect sense, but at the moment it can only be uploaded to
> experimental.
> 
> > We're not in a freeze, so I guess that's fair game.
> 
> We're not in a freeze but in the middle of the largest transition in
> Debian history[1], and during that a new major glibc version in unstable is
> out of the question.
> 
> >> files for now and re-include either when glibc 2.38 is in unstable or
> >> when it is in testing.
> >
> > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
> > dropped?  Does 2.38 have any freeze at the moment?
> 
> Yes.  Every new major glibc version requires a transition (requiring
> rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
> things), and the one for glibc 2.38[2] has been pending for three
> months[3].

Hmmm, I understand.  If you want to temporarily drop these pages from
manpages-dev, go ahead.  Please undrop them when glibc-doc can make a
new release.  BTW, I guess glibc-doc must match libc6 version?
Otherwise, you could have a more recent glibc-doc that drops these pages
without upgrading libc6.  Are documentation changes frozen in such a
transition?

> 
> >> There is also the problem that some derivatives (most notably Ubuntu)
> >> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
> >> versions in manpages-dev accordingly.
> >
> > Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
> > They have been unsupported for a long time.  The last change in
> > glibc-doc is from 2013.
> 
> I guess Ubuntu can then drop the glibc-doc package entirely, as they do
> not ship the upstream changelogs in it, and after dropping the pthread_*
> manpages the package would be empty.  TBH, I do not see much value in
> these changelogs and will probably uninstall glibc-doc from my systems.

Good.

Have a lovely day!
Alex

> 
> Cheers,
>Sven
> 
> 
> 1. https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
> 2. https://release.debian.org/transitions/html/glibc-2.38.html
> 3. https://bugs.debian.org/1059852

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi,

On Tue, Apr 02, 2024 at 08:58:32PM +0200, Aurelien Jarno wrote:
> Thanks, that sounds great that we can finally get rid out of those in
> the debian package.
> 
> > $ git diff --stat b06cd070f..128a3ae35
> >  man3/pthread_cond_init.3| 264 
> >  man3/pthread_condattr_init.3|  48 
> >  man3/pthread_key_create.3   | 178 +
> >  man3/pthread_mutex_init.3   | 241 ++
> >  man3/pthread_mutexattr_setkind_np.3 |  52 
> >  man3/pthread_once.3 |  44 
> >  6 files changed, 827 insertions(+)

I now see that `apt-file show glibc-doc` shows several more pages.  I'll
have a look at them and maybe I also import them into the Linux
man-pages project.

> > Debian's manpages-dev_6.7-1_all.deb has been the first package since
> > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
> > upgrade manpages-dev due to a conflict with glibc-doc.
> > 
> > $ sudo apt-get upgrade -V;
> > [...]
> > Do you want to continue? [Y/n] y
> > Reading changelogs... Done
> > (Reading database ... 404853 files and directories currently installed.)
> > Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
> > Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
> >  trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
> > which is also in package glibc-doc 2.38-6
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
> > needrestart is being skipped since dpkg has failed
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> I think this is actually not specific to the experimental version, those
> manpages are also in the unstable version.

Right.  I only installed the experimental one to see if the bug had
been fixed (as reportbug(1) suggested trying it).

> > Please, remove from glibc-doc those manual pages that conflict with
> > manpages-dev.
> 
> Noted. However following the time_t transition, the glibc package does
> not build anymore on 32-bit architectures (i have just opened #1059937
> to make people aware of that), so uploading a new glibc now is probably
> not the best idea.

Hmm, maybe you can drop the manual pages, but not upload yet, and wait
for that bug to be fixed to do an upload without the pages.

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Bug#1077666: Build-Depends: libllvmlibc--dev is missing

[Alejandro Colomar]

Source: iwyu
Version: 8.22-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

I've tried building iwyu from source after installing the all the build
dependencies of the package, and failed.  The build error reported that
"/usr/lib/llvm-19/lib/libLibcTableGenUtil.a" was missing.  After
installing the package that provides it, I could successfully build it.

See: 

Have a lovely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.12-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Alejandro Colomar]

Package: src:linux
Version: 6.9.12-1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

I ran `apt-get upgrade` earlier today.  I rebooted, since the update
had a new kernel, and the system wouldn't boot with the new kernel.
My old kernel was 6.9.7-amd64, which worked fine.
The new kernel is 6.9.12-amd64.  Here's what I see when booting with the
new kernel:

cryptsetup: Waiting for encrypted source device UUID=8[...]...
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.

[...] is the remaining of the UUID.
The above 3 lines repeat for several times, and then comes the
following:

Gave up waiting for root file system device.  Common problems:
  - Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
  - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=0[...] does not exist.  Dropping to a shell!

I copied these errors with pencil and paper, so it may have small typos.
One thing to notice is that the UUID that cryptsetup wait for starts
with an 8, but the ALERT message reports about one that starts with a 0.

I can't boot the system anymore.  I've also dist-upgraded to
6.10.4-amd64 to see if it solved the problem, but it was also broken.
I'm currently running the old kernel.

I installed Debian on an encrypted partition (following the Debian
Installer; nothing custom).

Have a lovely day!
Alex


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Micro-Star International Co., Ltd.
product_name: MS-7D86
product_version: 1.0
chassis_vendor: Micro-Star International Co., Ltd.
chassis_version: 1.0
bios_vendor: American Megatrends International, LLC.
bios_version: 1.30
board_vendor: Micro-Star International Co., Ltd.
board_name: MEG Z790 ACE (MS-7D86)
board_version: 1.0

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:a700] (rev 01)
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.1 PCI bridge [0604]: Intel Corporation Device [8086:a72d] (rev 01) 
(prog-if 00 [Normal decode])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-S GT1 
[UHD Graphics 770] [8086:a780] (rev 04) (prog-if 00 [VGA controller])
DeviceName: Onboard - Video
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring Accelerator 
module [8086:a74f] (rev 01)
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:0a.0 Signal processing controller [1180]: Intel Corporation Raptor Lake 
Crashlog and Telemetry [8086:a77d] (rev 01)
DeviceName: Onboard - Other
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_vsec
Kernel modules: intel_vsec

00:14.0 USB controller [0c03]: Intel Corporation Raptor Lake USB 3.2 Gen 2x2 
(20 Gb/s) XHCI Host Controller [8086:7a60] (rev 11) (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: mei_me, xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Raptor Lake-S PCH 

Bug#1079150: Acknowledgement (cryptsetop: Waiting for encrypted source device)

[Alejandro Colomar]

> 1079150: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079150

Should I report this bug also against linux-image-amd64, or against the
newer version, or is that automatically migrated?

Cheers,
Alex


-- 



signature.asc
Description: PGP signature

Bug#1079150: Info received (Bug#1079150: Acknowledgement (cryptsetop: Waiting for encrypted source device))

[Alejandro Colomar]

I've seen that there are some new packages that are related to this bug.

$ sudo apt-get dist-upgrade -V
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
   klibc-utils (2.0.13-4)
   libklibc (2.0.13-4)
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
   initramfs-tools (0.143.1)
   initramfs-tools-core (0.143.1)
The following NEW packages will be installed:
   dracut (103-1)
   dracut-core (103-1)
   kpartx (0.9.9-1)
   pigz (2.8-1)
   python3-autocommand (2.2.2-3)
   python3-inflect (7.3.1-1)
   python3-jaraco.context (6.0.0-1)
   python3-jaraco.functools (4.0.2-1)
   python3-more-itertools (10.3.0-1)
   python3-typeguard (4.3.0-1)
   python3-typing-extensions (4.12.2-2)
   python3-zipp (3.20.0-1)
The following packages have been kept back:
   kmod (33+20240816-1 => 33+20240816-2)
   libkmod2 (33+20240816-1 => 33+20240816-2)
The following packages will be upgraded:
   python3-pkg-resources (70.3.0-2 => 72.2.0-1)
   python3-setuptools (70.3.0-2 => 72.2.0-1)
2 upgraded, 12 newly installed, 2 to remove and 2 not upgraded.
Need to get 1605 kB of archives.
After this operation, 4076 kB of additional disk space will be used.
Do you want to continue? [Y/n] 


Is it okay that it's trying to remove initramfs-tools*?  Should I
accept?


Thanks,
Alex

-- 



signature.asc
Description: PGP signature

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Alejandro Colomar]

Hi Ben,

On Thu, Aug 22, 2024 at 12:46:00AM GMT, Ben Hutchings wrote:
> Please send the output of this command:
> 
> lsinitramfs /boot/initrd.img-6.9.12-amd64 | grep /lib/modules | head

I've purged 6.9.12, but I keep 6.10.4 --which is also broken--, so I've
run it with that:

$ lsinitramfs /boot/initrd.img-6.10.4-amd64 \
| grep /lib/modules | head;
usr/lib/modules
usr/lib/modules/6.10.4-amd64
usr/lib/modules/6.10.4-amd64/kernel
usr/lib/modules/6.10.4-amd64/kernel/crypto
usr/lib/modules/6.10.4-amd64/kernel/crypto/adiantum.ko
usr/lib/modules/6.10.4-amd64/kernel/drivers
usr/lib/modules/6.10.4-amd64/kernel/drivers/input
usr/lib/modules/6.10.4-amd64/kernel/drivers/input/mouse
usr/lib/modules/6.10.4-amd64/kernel/drivers/input/mouse/psmouse.ko
usr/lib/modules/6.10.4-amd64/kernel/drivers/net

and just for comparison, here's with a kernel that works:

$ lsinitramfs /boot/initrd.img-6.9.7-amd64 \
| grep /lib/modules | head;
usr/lib/modules
usr/lib/modules/6.9.7-amd64
usr/lib/modules/6.9.7-amd64/kernel
usr/lib/modules/6.9.7-amd64/kernel/arch
usr/lib/modules/6.9.7-amd64/kernel/arch/x86
usr/lib/modules/6.9.7-amd64/kernel/arch/x86/crypto
usr/lib/modules/6.9.7-amd64/kernel/arch/x86/crypto/aegis128-aesni.ko
usr/lib/modules/6.9.7-amd64/kernel/arch/x86/crypto/aesni-intel.ko
usr/lib/modules/6.9.7-amd64/kernel/arch/x86/crypto/blowfish-x86_64.ko

usr/lib/modules/6.9.7-amd64/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko

Have a lovely night!
Alex

-- 



signature.asc
Description: PGP signature

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Alejandro Colomar]

Hi Ben,

On Thu, Aug 22, 2024 at 02:35:08AM GMT, Ben Hutchings wrote:
> On Thu, 2024-08-22 at 01:11 +0200, Alejandro Colomar wrote:
> > On Thu, Aug 22, 2024 at 12:46:00AM GMT, Ben Hutchings wrote:
> > > Please send the output of this command:
> > > 
> > > lsinitramfs /boot/initrd.img-6.9.12-amd64 | grep /lib/modules | head
> > 
> > I've purged 6.9.12, but I keep 6.10.4 --which is also broken--, so I've
> > run it with that:
> > 
> > $ lsinitramfs /boot/initrd.img-6.10.4-amd64 \
> > | grep /lib/modules | head;
> > usr/lib/modules
> > usr/lib/modules/6.10.4-amd64
> > usr/lib/modules/6.10.4-amd64/kernel
> > usr/lib/modules/6.10.4-amd64/kernel/crypto
> > usr/lib/modules/6.10.4-amd64/kernel/crypto/adiantum.ko
> > usr/lib/modules/6.10.4-amd64/kernel/drivers
> > usr/lib/modules/6.10.4-amd64/kernel/drivers/input
> > usr/lib/modules/6.10.4-amd64/kernel/drivers/input/mouse
> > usr/lib/modules/6.10.4-amd64/kernel/drivers/input/mouse/psmouse.ko
> > usr/lib/modules/6.10.4-amd64/kernel/drivers/net
> 
> [...]
> 
> I think this is bug #1079022 (breakage of dracut-install) together with
> bug #1079066 (missing check for failure of dracut-install).
> 
> Does "update-initramfs -u -k 6.10.4-amd64" show errors from dracut-
> install?  And if not, does it now produce a working initramfs?

It shows errors.

$ sudo update-initramfs -u -k 6.10.4-amd64
update-initramfs: Generating /boot/initrd.img-6.10.4-amd64
/usr/lib/dracut/dracut-install: symbol lookup error: 
/usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
version LIBKMOD_5
setupcon: The keyboard model is unknown, assuming 'pc105'. Keyboard may be 
configured incorrectly.
/usr/lib/dracut/dracut-install: symbol lookup error: 
/usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
version LIBKMOD_5
/usr/lib/dracut/dracut-install: symbol lookup error: 
/usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
version LIBKMOD_5
$ echo $?
0

(It's weird that the exit status is 0 but it shows errors.)


Have a lovely day!
Alex

> 
> Ben.

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Bug#1079333: initramfs-tools: upgrading causes dpkg(1) to fail

[Alejandro Colomar]

Package: initramfs-tools
Version: 0.144
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

I've tried upgrading earlier today (`apt-get upgrade`), and had some
error.  I've rebooted just in case that would fix it, and then tried to
`apt-get --fix-broken install`, but the error remains:

$ sudo apt-get --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up initramfs-tools (0.144) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.144) ...
update-initramfs: Generating /boot/initrd.img-6.10.4-amd64
cp: cannot stat '/var/tmp/mkinitramfs_LmRFUO//usr/sbin/reiserfsck': Too many 
levels of
+symbolic links
setupcon: The keyboard model is unknown, assuming 'pc105'. Keyboard may be 
configured
+incorrectly.
ln: failed to create symbolic link 
'/var/tmp/mkinitramfs_LmRFUO/sbin/reiserfsck': File
+exists
cp: cannot stat '/var/tmp/mkinitramfs_LmRFUO//usr/sbin/reiserfsck': Too many 
levels of
+symbolic links
E: /usr/share/initramfs-tools/hooks/reiserfsprogs failed with return 1.
update-initramfs: failed for /boot/initrd.img-6.10.4-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned 
error
+exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)


This was originally reported within debbug #1079150.

Cheers,
Alex


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root  29M Aug 22 12:31 /boot/initrd.img-6.10.4-amd64
-rw-r--r-- 1 root root 512M Jul 29 10:22 /boot/initrd.img-6.8.0-rc5-alx+
-rw-r--r-- 1 root root 512M Jul 29 10:21 /boot/initrd.img-6.8.0-rc7-alx-dirty
-rw-r--r-- 1 root root  70M Jul 29 10:20 /boot/initrd.img-6.9.7-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.9.7-amd64 root=UUID=0c89cc58-ef70-43ee-bdf6-2ab0d393116d 
ro quiet

-- resume
RESUME=none
-- /proc/filesystems
fuseblk
btrfs
ext3
ext2
ext4
vfat

-- lsmod
Module  Size  Used by
xt_conntrack   12288  1
xt_MASQUERADE  16384  1
nf_conntrack_netlink61440  0
xfrm_user  61440  1
xfrm_algo  16384  1 xfrm_user
xt_addrtype12288  2
nft_compat 20480  4
br_netfilter   36864  0
nft_masq   12288  2
nft_chain_nat  12288  5
nf_nat 65536  3 nft_masq,nft_chain_nat,xt_MASQUERADE
nf_conntrack  204800  5 
xt_conntrack,nf_nat,nf_conntrack_netlink,nft_masq,xt_MASQUERADE
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 12288  1 nf_conntrack
bridge389120  1 br_netfilter
stp12288  1 bridge
llc16384  2 bridge,stp
nf_tables 372736  88 nft_compat,nft_masq,nft_chain_nat
overlay   208896  0
rfkill 40960  1
qrtr   53248  2
binfmt_misc28672  1
nls_ascii  12288  1
nls_cp437  16384  1
vfat   20480  1
fat98304  1 vfat
snd_sof_pci_intel_tgl12288  0
snd_sof_intel_hda_common   225280  1 snd_sof_pci_intel_tgl
soundwire_intel73728  1 snd_sof_intel_hda_common
snd_sof_intel_hda_mlink36864  2 soundwire_intel,snd_sof_intel_hda_common
soundwire_cadence  45056  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
snd_sof_pci24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
snd_sof_xtensa_dsp 16384  1 snd_sof_intel_hda_common
snd_sof   376832  3 
snd_sof_pci,snd_sof_intel_hda_common,snd_sof_intel_hda
intel_rapl_msr 20480  0
intel_rapl_common  36864  1 intel_rapl_msr
intel_uncore_frequency12288  0
intel_uncore_frequency_common16384  1 intel_uncore_frequency
x86_pkg_temp_thermal16384  0
snd_sof_utils  16384  1 snd_sof
snd_soc_hdac_hda   28672  1 snd_sof_intel_hda_common
intel_powerclamp   16384  0
snd_soc_acpi_intel_match   102400  2 
snd_sof_intel_hda_common,snd_sof_pci_intel_tgl
coretemp   16384  0
soundwire_generic_allocation12288  1 soundwire_intel
snd_soc_acpi   16384  2 
snd_soc_acpi_intel_match,snd_sof_intel_hda_common
soundwire_bus 114688  3 
soundwire_intel,soundwire_generic_allocation,soundwire_cadence
kvm_intel 413696  0
snd_soc_avs   208896  0
snd_soc_hda_codec  24576  1 snd_soc_avs
snd_hda_ext_core   36864  6 
snd_soc_avs,snd_soc_hda_codec,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda_mlink,snd_sof_intel_hda
snd_hda_codec_hdmi 90112  1
snd_soc_core  421888  6 
snd_soc_avs,snd_soc_hda_codec,so

Bug#1079333: initramfs-tools: upgrading causes dpkg(1) to fail

[Alejandro Colomar]

Hi Ben,

On Thu, Aug 22, 2024 at 03:52:01PM GMT, Ben Hutchings wrote:
> Control: reopen -1
> Control: severity -1 serious
> 
> Sorry, I got confused by the multiple reports of this and thought you
> had
> opened two different bug reports for this.

No problem.  BTW, I chose critical, because now I have a broken dpkg
database (any apt-get install or upgrade command reports some error),
which I think fits "breaks the entire system", but serious is probably
good enough.  Thanks!

Cheers,
Alex

> 
> Ben.
> 
> -- 
> Ben Hutchings
> All the simple programs have been written, and all the good names taken
> 



-- 



signature.asc
Description: PGP signature

Bug#1050831: wrk: No manual page

[Alejandro Colomar]

Package: wrk
Version: 4.1.0-3+b2
Severity: serious
Tags: upstream
Justification: Policy 12.1
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi!

This program has no manual page.  :(

Cheers,
Alex

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wrk depends on:
ii  libc62.37-6
ii  libluajit-5.1-2  2.1.0~beta3+git20220320+dfsg-4.1
ii  libssl3  3.0.9-1

wrk recommends no packages.

wrk suggests no packages.

-- no debconf information

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Alejandro Colomar]

Package: libbsd-dev
Version: 0.12.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: a...@kernel.org

Dear Guillem,

After upgrading to libbsd 0.12 today, several build systems that I use
started reporting many failures about libbsd functions.  The functions
seem to have disappeared.  I remember having seen that the build system
of libbsd has been recently tweaked, so I suspect one of those changes
might be the cause of the problem.

Here's a small reproducer:

$ cat bsd.c 
#include 

long
strtoi_(char *s, char **endp, int b, long min, long max, int *st)
{
return strtoi(s, endp, b, min, max, st);
}

Which reports the following error:

$ gcc -Wall -Wextra -S bsd.c 
bsd.c: In function ‘strtoi_’:
bsd.c:6:16: warning: implicit declaration of function ‘strtoi’; did you 
mean ‘strtoi_’? [-Wimplicit-function-declaration]
6 | return strtoi(s, endp, b, min, max, st);
  |^~
  |strtoi_

I've also seen errc(3bsd) disappear, and possibly many more functions.
If you need some help to reproduce this issue, just let me know.

BTW, thanks for updating strtoi/u(3) from NetBSD!  =)


Have a lovely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc5-alx+ (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbsd-dev depends on:
ii  libbsd00.12.0-1
ii  libmd-dev  1.1.0-2

libbsd-dev recommends no packages.

libbsd-dev suggests no packages.

-- no debconf information

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Alejandro Colomar]

Hi Guillem!

On Tue, Feb 27, 2024 at 05:33:16PM +0100, Alejandro Colomar wrote:
> I've also seen errc(3bsd) disappear, and possibly many more functions.
> If you need some help to reproduce this issue, just let me know.

In the case of , the header has disappeared:

$ cat bsd.c 
#include 
#include 

long
strtoi_(char *s, char **endp, int b, long min, long max, int *st)
{
return strtoi(s, endp, b, min, max, st);
}
alx@debian:~/tmp$ gcc -Wall -Wextra -S bsd.c
bsd.c:1:10: fatal error: bsd/err.h: No such file or directory
1 | #include 
  |  ^~~
compilation terminated.

This seems consistent with the recent build system changes.  The bug is
probably there.

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Alejandro Colomar]

Hi!

On Tue, Feb 27, 2024 at 06:10:01PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2024-02-27 at 17:33:16 +0100, Alejandro Colomar wrote:
[...]
> The strtoi() function is declared in . I don't think that
> has changed in libbsd.

Oops!  I wrote the reproducer too fast.  Actually, the problem I saw was
about errc(), but because I tried strtoi() to see if it was the only
function, and it also failed, but I forgot about the right header.

It was also aggravated by the fact that my grepc(1) program didn't find
it.  But it's due to a bug I introduced yesterday in grepc(1).  :|

$ grepc strtoi /usr/include/bsd/

But grep(1) does find it:

$ grep -rn strtoi /usr/include/bsd/
/usr/include/bsd/inttypes.h:43:intmax_t strtoi(const char *__restrict 
nptr, char **__restrict endptr,

And after fixing the bug in grepc(1):

$ grepc strtoi /usr/include/bsd/
/usr/include/bsd/inttypes.h:__BEGIN_DECLS
intmax_t strtoi(const char *__restrict nptr, char **__restrict endptr,
int base, intmax_t lo, intmax_t hi, int *rstatus);

> 
> > BTW, thanks for updating strtoi/u(3) from NetBSD!  =)
> 
> Thanks for handling the upstream interaction in NetBSD!
> 
[...]
> 
> Ah, it indeed has disappeared. The upstream build system is missing a
> conditional for the header, I'll add this later today and prepare a
> new upstream release.
> 
> Another thing which I was aware, but then slipped my mind is that the
> cdefs.h header needs to be placed under a multi-arch qualified
> directory otherwise it will conflict with other instances of the
> library now that it contains arch-specific defines. Will amend that
> with the new Debian upload.

Thanks!

Have a lovely day!
Alex

> 
> Thanks,
> Guillem

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1087616: linux-image-6.11.7-amd64: Can't boot (boot freezes after [or maybe during] cryptsetup unlocks drive)

[Alejandro Colomar]

Hi Salvatore,

On Sun, Nov 17, 2024 at 08:25:18PM GMT, Salvatore Bonaccorso wrote:
> Control: severity -1 serious
> Control: tags -1 + moreinfo
> 
> I guess we have too litttle information here to get an idea about the
> issue.

Here's the last three lines I see before it freezes:

Please unlock disk nvme0n1p4_crypt: **...*
cryptsetup: nvme0n1p4_crypt: set up successfully
deb_root: clean, 5xx/3xxx files, 96xx/134xx blocks


After that it freezes.  When I boot tomorrow, I'll try to note down the
lines before that, since I've noticed there are some lines that only
appear with the new kernel.

> Is the system still repsonsive and accessible through SSH?

It's the computer I'm using to send this email.  I can boot it with an
old kernel.

> Might you get more information out of it with configuring netconsole
> to get kernel logs out?

I could, if you tell me how.  I'm not an expert in these things.

Cheers,
Alex

> 
> Regards,
> Salvatore

-- 



signature.asc
Description: PGP signature

Bug#1087616: linux-image-6.11.7-amd64: Can't boot (boot freezes after [or maybe during] cryptsetup unlocks drive)

[Alejandro Colomar]

Hi Salvatore,

On Sat, Nov 23, 2024 at 06:00:22PM +0100, Salvatore Bonaccorso wrote:
> Hi Alejandro,
> 
> Sorry for the late reply. 

No problem.  I'm not going to be able to provide an answer until 3 weeks
from now.

> There is documentation here:
> https://www.kernel.org/doc/html/latest/networking/netconsole.html#netconsole

Thanks!

> Since we need the messages as eaerly as possible, make sure that the
> source ip and target device is configured with the parameters.
> 
> I assume you still have the behaviour with 6.11.9-1 uploaded earlier
> the week? Note there is as well 6.11.10-1 right now to be processed
> and available soon as well.
> 
> From a working version yet, can you access the apt log around the time
> you have updates, anything suspicious in apt logs?

I rebooted a few days ago with an old kernel and could not boot, so I
suspected an intermittent hardware failure (which might be triggered
more often in a newer kernel; or might be just coincidence).  I've
ordered a pSLC hard drive to replace it (pSLC to hopefully have a better
lifetime this time), which will arrive around 3 weeks from now.  Until
it arrives, I'll keep that computer turned off, just in case that makes
it worse.  Then, I'll turn it on and do a copy of stuff.  When I turn it
on, I'll try to investigate if it really is a hardware failure, or a
software one.

Thanks for your help!

Have a lovely night!
Alex

> Regards,
> Salvatore

-- 



signature.asc
Description: PGP signature

Bug#1087616: linux-image-6.11.7-amd64: Can't boot (boot freezes after [or maybe during] cryptsetup unlocks drive)

[Alejandro Colomar]

Package: src:linux
Version: 6.11.7-1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

I upgraded the kernel

linux-image-6.11.4-amd64 => linux-image-6.11.7-amd64

and cannot boot with the new one.  It gets stuck after (or maybe during,
I'm not sure) cryptsetup unlocks the drive.  The last line I see says
how many files and blocks are ok.

I'll try to write it in a paper the next time I boot.

Have a lovely day!
Alex


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Micro-Star International Co., Ltd.
product_name: MS-7D86
product_version: 1.0
chassis_vendor: Micro-Star International Co., Ltd.
chassis_version: 1.0
bios_vendor: American Megatrends International, LLC.
bios_version: 1.30
board_vendor: Micro-Star International Co., Ltd.
board_name: MEG Z790 ACE (MS-7D86)
board_version: 1.0

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:a700] (rev 01)
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.1 PCI bridge [0604]: Intel Corporation Device [8086:a72d] (rev 01) 
(prog-if 00 [Normal decode])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-S GT1 
[UHD Graphics 770] [8086:a780] (rev 04) (prog-if 00 [VGA controller])
DeviceName: Onboard - Video
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring Accelerator 
module [8086:a74f] (rev 01)
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:0a.0 Signal processing controller [1180]: Intel Corporation Raptor Lake 
Crashlog and Telemetry [8086:a77d] (rev 01)
DeviceName: Onboard - Other
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_vsec
Kernel modules: intel_vsec

00:14.0 USB controller [0c03]: Intel Corporation Raptor Lake USB 3.2 Gen 2x2 
(20 Gb/s) XHCI Host Controller [8086:7a60] (rev 11) (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: mei_me, xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Raptor Lake-S PCH Shared SRAM 
[8086:7a27] (rev 11)
DeviceName: Onboard - Other
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:16.0 Communication controller [0780]: Intel Corporation Raptor Lake CSME 
HECI #1 [8086:7a68] (rev 11)
DeviceName: Onboard - Other
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation Raptor Lake SATA AHCI 
Controller [8086:7a62] (rev 11) (prog-if 01 [AHCI 1.0])
DeviceName: Onboard - SATA
Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7d86]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV-

Bug#1087616: linux-image-6.11.7-amd64: Can't boot (boot freezes after [or maybe during] cryptsetup unlocks drive)

[Alejandro Colomar]

Hello Uwe,

On Fri, Dec 13, 2024 at 09:06:32AM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Sat, Nov 16, 2024 at 11:41:15AM +0100, Alejandro Colomar wrote:
> > I upgraded the kernel
> > 
> > linux-image-6.11.4-amd64 => linux-image-6.11.7-amd64
> > 
> > and cannot boot with the new one.  It gets stuck after (or maybe during,
> > I'm not sure) cryptsetup unlocks the drive.  The last line I see says
> > how many files and blocks are ok.
> > 
> > I'll try to write it in a paper the next time I boot.
> 
> Can you please take a look at
> https://github.com/systemd/systemd/issues/35499 and if possible provide
> debug data there?

I can't.  systemd maintainers have banned me from their github.

Cheers,
Alex

> 
> Best regards
> Uwe



-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Bug#1099130: firefox-esr: Please package a fork that respects users privacy

[Alejandro Colomar]

Package: firefox-esr
Version: 128.7.0esr-1
Severity: serious
Tags: upstream security
Justification: Policy 2.1
X-Debbugs-Cc: a...@kernel.org, Debian Security Team 

Dear Maintainer,

As you may know from recent news ,
Mozilla has gone evil.

The new Terms of Use, from what I can see, are in violation of the
DFSG points 5 and 6:

5)  No discrimination against persons or groups

Rationale:

The terms of use grant Mozilla the right to terminate anyone's access:

Mozilla can suspend or end anyone’s access to Firefox at any
time for any reason



6)  No discrimination against fields of endeavor

Rationale:

The terms of use don't allow you to use Firefox to break the law.  While
this seems a reasonable term, it wouldn't be so reasonable for a
disident in an oppressive country.

you agree that you will not use Firefox to [...] violate any
applicable laws or regulations.



While not exactly this case, see also:
.

Apart from these violations of the DFSG, Firefox has now permission to
leak user data to Mozilla, and who knows who else they decide to sell it
later.  This is a security bug.

You give Mozilla all rights necessary to operate Firefox,
including processing data as we describe in the Firefox Privacy
Notice, as well as acting on your behalf to help you navigate
the internet.  When you upload or input information through
Firefox, you hereby grant us a nonexclusive, royalty-free,
worldwide license to use that information to [...]




   * What led up to the situation?

Mozilla's greedyness?


Please consider packaging a fork of Firefox that doesn't have these
violations of Debian's Policy and the security and privacy bugs.


Have a lovely day!
Alex

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.16-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  5.21
ii  fontconfig   2.15.0-2
ii  libasound2t641.2.13-1+b1
ii  libatk1.0-0t64   2.55.2-1
ii  libc62.40-7
ii  libcairo-gobject21.18.2-2
ii  libcairo21.18.2-2
ii  libdbus-1-3  1.16.0-1
ii  libevent-2.1-7t642.1.12-stable-10+b1
ii  libffi8  3.4.7-1
ii  libfontconfig1   2.15.0-2
ii  libfreetype6 2.13.3+dfsg-1
ii  libgcc-s114.2.0-17
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-2
ii  libglib2.0-0t64  2.83.4-1
ii  libgtk-3-0t643.24.48-4
ii  libnspr4 2:4.36-1
ii  libnss3  2:3.108-1
ii  libpango-1.0-0   1.56.1-1
ii  libstdc++6   14.2.0-17
ii  libvpx9  1.15.0-2
ii  libx11-6 2:1.8.10-2
ii  libx11-xcb1  2:1.8.10-2
ii  libxcb-shm0  1.17.0-2+b1
ii  libxcb1  1.17.0-2+b1
ii  libxcomposite1   1:0.4.6-1
ii  libxdamage1  1:1.1.6-1+b2
ii  libxext6 2:1.3.4-1+b3
ii  libxfixes3   1:6.0.0-2+b4
ii  libxrandr2   2:1.5.4-1+b3
ii  procps   2:4.0.4-7
ii  zlib1g   1:1.3.dfsg+really1.3.1-1+b1

Versions of packages firefox-esr recommends:
ii  libavcodec61  7:7.1-4

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-5
ii  libcanberra0   0.30-17+b1
ii  libgssapi-krb5-2   1.21.3-4
ii  pulseaudio 17.0+dfsg1-2

-- no debconf information