Hi Petra,

On Sunday, 6 March 2022 11:23:57 CET Petra R.-P. wrote:
> > I saw that the 5.16.11-1 kernel transitioned to testing and it is useful
> > to know if the issue is still present with that version.
> 
> Today's "apt-get dist-upgrade" did not yield anything kernel-related.

Do you have 'linux-image-686' (kernel metapackage) installed? If so you can use 
'apt-cache policy linux-image-686' and that should also give a version table. 
The 5.16.11 version comes in the linux-image-5.16.0-3-686 package.
The linux-signed-i386 package transitioned on 2022-03-04, so it should be there.
If you don't use 'deb.debian.org' in your /etc/apt/sources.list line(s), then
changing to that may help.

> > Because on my system the very first message of a boot in that file
> > begins with: [    0.000000] Linux version 5.16.0-3-amd64 ...
> 
> Yes, I understood that, and checked the file for such lines
> over and over again.  Not a single trace of any "5.16",
> only "Linux version 5.15.0-3-686" everywhere.

Then I may have found a reason which would perfectly explain that and
that would also explain why the boot stops:

>From you 5.15 boot log:
Mar  6 09:53:25 netty kernel: [    4.493610] libata version 3.00 loaded.
Mar  6 09:53:25 netty kernel: [    4.502635] ata_piix 0000:00:1f.1: version 2.13
Mar  6 09:53:25 netty kernel: [    4.502656] ata_piix 0000:00:1f.1: enabling 
device (0005 -> 0007)
Mar  6 09:53:25 netty kernel: [    4.535303] scsi host0: ata_piix
Mar  6 09:53:25 netty kernel: [    4.548193] scsi host1: ata_piix
Mar  6 09:53:25 netty kernel: [    4.548354] ata1: PATA max UDMA/100 cmd 0x1f0 
ctl 0x3f6 bmdma 0x1860 irq 14
Mar  6 09:53:25 netty kernel: [    4.548398] ata2: PATA max UDMA/100 cmd 0x170 
ctl 0x376 bmdma 0x1868 irq 15
Mar  6 09:53:25 netty kernel: [    4.713115] ata2.00: ATAPI: HL-DT-STDVD-ROM 
GDR8083N, 0K04, max UDMA/33
Mar  6 09:53:25 netty kernel: [    4.713521] ata1.00: ATA-6: IC25N030ATMR04-0, 
MOAOAD4A, max UDMA/100
Mar  6 09:53:25 netty kernel: [    4.713566] ata1.00: 58605120 sectors, multi 
16: LBA 
Mar  6 09:53:25 netty kernel: [    4.724928] scsi 0:0:0:0: Direct-Access     
ATA      IC25N030ATMR04-0 AD4A PQ: 0 ANSI: 5
Mar  6 09:53:25 netty kernel: [    4.732350] scsi 1:0:0:0: CD-ROM            
HL-DT-ST DVD-ROM GDR8083N 0K04 PQ: 0 ANSI: 5
Mar  6 09:53:25 netty kernel: [    4.797990] e1000 0000:02:01.0 eth0: 
(PCI:33MHz:32-bit) 00:0d:60:cf:80:2e
Mar  6 09:53:25 netty kernel: [    4.798057] e1000 0000:02:01.0 eth0: Intel(R) 
PRO/1000 Network Connection
Mar  6 09:53:25 netty kernel: [    4.816199] sd 0:0:0:0: [sda] 58605120 
512-byte logical blocks: (30.0 GB/27.9 GiB)
Mar  6 09:53:25 netty kernel: [    4.816288] sd 0:0:0:0: [sda] Write Protect is 
off
Mar  6 09:53:25 netty kernel: [    4.816328] sd 0:0:0:0: [sda] Mode Sense: 00 
3a 00 00
Mar  6 09:53:25 netty kernel: [    4.816373] sd 0:0:0:0: [sda] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

This mostly overlaps with the screenshot you send wrt the 5.16 kernel,
with one critical difference: I don't see the "libata version 3.00 loaded."
line and the line following that (but it does show the line following that...)
and at the end I see the detection of sda which is missing in your screenshot!
No HDD detected means it can't write a (kernel) log file to it and it would 
also prevent loading the rest of the OS.
(I'm also missing the detection of the NIC (e1000 driver), but that seems less
relevant.

I found commit 0188d5195b6705691fcc35046561e7ddf59ac626 in the 5.16.y branch
which links to upstream commit fda17afc6166e975bec1197bd94cd2a3317bce3f and
the commit message mentions:

Since many older drives
    react badly to the READ LOG EXT and/or READ LOG DMA EXT commands isued
    to read device log pages, avoid problems with older drives by limiting
    the concurrent positioning ranges support detection to drives
    implementing at least the ACS-4 ATA standard (major version 11). This
    additional condition effectively turns ata_dev_config_cpr() into a nop
    for older drives, avoiding problems in the field.

This commit is part of the 5.16.9 kernel.

If updating to linux-image-5.16.0-3-686 (5.16.11) doesn't fix it, then I guess
the issue should be taken to the upstream kernel, but I don't know where
that should be done. I guess someone else who follows the list, does though :)

Good luck!

Diederik

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to