kernel errors

[Richmond]

It may be a coincidence but yesterday I installed some
libguestfs-tools. Now I see errors when booting, which also appear in
/var/log/messages:

kernel: [ 9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
kernel: [ 9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready [current]
kernel: [ 9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not present - tray closed
kernel: [ 9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00
kernel: [ 9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer
kernel: [ 9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer
kernel: [ 9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer
kernel: [ 9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
kernel: [ 9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current]
kernel: [ 9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present - tray closed
kernel: [ 9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00
kernel: [ 9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer
kernel: [ 9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer

I removed the toos, and also disabled udiskd or udisk2d:

systemctl stop udisks2.service
systemctl disable udisks2.service

But the errors are still occuring. How can I stop them?

Installing the tools did some strange things like regenerating the grub
menu.

[Thomas Schmitt]

Hi,

Richmond wrote:
> kernel: [ 9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
> kernel: [ 9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready [current]
> kernel: [ 9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not present - tray closed
> kernel: [ 9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00

Your optical drive gets asked for 2 blocks iand answers that there is no
medium recognized in the tray. The request was to read from block 0x07fffc
= 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB.
This is not a usual medium capcity. So i wonder from where the caller had
that block address.

> kernel: [ 9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer

I wonder what might have caused this. But this line brings me to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358
where pio...@gmail.com tried to get this processed as bug of udev.
No solution was found.

> kernel: [ 9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
> kernel: [ 9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current]
> kernel: [ 9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present - tray closed
> kernel: [ 9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00

This read attempt wanted to get 2 blocks from block address 0.
More plausible as a wild guess, than 1 GiB - 4 KiB.


What happens if you give the drive a readable DVD ?
Maybe the software which issues the READ commands shows up with some more
enlightening complaint.


Have a nice day :)

Thomas

[Richmond]

I put a dvd in and mounted it. Then rebooted. I saw these messages:

[ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0
[ 3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray
[ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0

Then removed the DVD and rebooted, back to these:

[ 4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
[ 9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
[ 9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current]
[ 9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray closed
[ 9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00
[ 9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer

I am starting to consider re-installing, although everything is working,
I don't like the look of it. Perhaps I should just re-install the
kernel?

[Sven Joachim]

On 2023-01-23 16:13 +0000, Richmond wrote:

> I put a dvd in and mounted it. Then rebooted. I saw these messages:
>
> [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0
> [ 3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray
> [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0
>
> Then removed the DVD and rebooted, back to these:
>
> [ 4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
> [ 9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
> [ 9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current]
> [ 9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray closed
> [ 9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00
> [ 9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer
>
> I am starting to consider re-installing, although everything is working,
> I don't like the look of it. Perhaps I should just re-install the
> kernel?

This would most likely not help. Instead you should try to figure out
what process is trying to read from your empty drive, and why.
Consulting journalctl might help with that.

Cheers,
Sven

[Thomas Schmitt]

Hi,

Richmond wrote:
> I put a dvd in and mounted it. Then rebooted. I saw these messages:
>
> [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0
> [ 3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray
> [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0

Looks normal.

> Then removed the DVD and rebooted, back to these:

I wonder what happens if you simply put in and out the medium, without
rebooting.


It looks somewhat as if the kernel perceives a wrong medium status and size
and so lures some software like blkid into trying to read the last 4 KiB
before the end of the first GiB.

What do you get from:

lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0

I get:

VENDOR MODEL SIZE
HL-DT-ST BDDVDRW GGC-H20L 4700372992

(It is a known bug of Linux to report the size of the last loaded medium
if the drive tray is empty. But exactly 1 GiB is a strange size for a
DVD medium and rebooting should clear this misperception.)

> I am starting to consider re-installing, although everything is working,
> I don't like the look of it. Perhaps I should just re-install the kernel?

If you do, then check whether the messages are not there after base system
installation and then try to find out which further package causes those
read attempts.

[Richmond]

re-installing kernel didn't work.

I looked in journalctl and saw this:

kernel: PM: Image not found (code -22)

It's looking for a resume from hibernate maybe.

So then it became apparent that the kernel parameter to resume is a disk
by id which looks different from the ones in /etc/fstab. I am not sure
how that came about.

[David Wright]

When you've removed the packages, keep a copy of your grub.cfg for
comparison and then reconfigure grub (grub-mkconfig). See if the
messages go away.

Did you have something strange in your optical drive when you
installed these tools, in anticipation of using the latter on
the former?

Cheers,
David.

[Richmond]

The messages didn't go away. And I tried to reconfigure swap and resume,
and got more errors, so I reinstalled the system, formatting the root
partition.

>
> Did you have something strange in your optical drive when you
> installed these tools, in anticipation of using the latter on
> the former?

No, but I did have a usb stick plugged in, and it had ChromeOS Flex on
it. In fact that appeared on the grub menu yesterday and I tried to boot
ChromeOS Flex from it. That was no doubt a big mistake.

[Thomas Schmitt]

Hi,

piorunz wrote:
> Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D
>
> $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0
> VENDOR MODEL SIZE
> hp hp_DVDRW_GUE1N 1073741312

Now that's a strange size: 1 GiB - 512 bytes.
The readable data capacity of an optical drive should be divisible by 2048,
but the reported size is not.

(I remember to have read of very old CD drives with a hardware switch
which changes the data block size from 2048 to 512 bytes.)

What do you get from the lsblk command when a readable DVD is inserted and
later when the medium is out of the drive again ?

[Thomas Schmitt]

Hi,

the log messages about "unaligned transfer" would be explained if indeed
the block size of the drive would be mistaken as 512 bytes rather than
2048 bytes.

So it might be interesting to let lsblk report "sector" sizes as perceived
by the kernel:

lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0

I get from the empty drive (last medium in was a CD-RW):

VENDOR MODEL SIZE PHY-SEC LOG-SEC
HL-DT-ST BDDVDRW GGC-H20L 287483904 2048 2048

and with a BD-RE loaded:

VENDOR MODEL SIZE PHY-SEC LOG-SEC
HL-DT-ST BDDVDRW GGC-H20L 24756879360 2048 2048

[piorunz]

CD inserted:
$ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0

VENDOR MODEL SIZE PHY-SEC LOG-SEC

hp hp_DVDRW_GUE1N 627656704 2048 2048

DVD inserted:
$ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0

VENDOR MODEL SIZE PHY-SEC LOG-SEC

hp hp_DVDRW_GUE1N 3353346048 2048 2048

I noticed that when there is no disc or disc is loading, this command
above is still reporting last used disc even when it's already gone.
Meaning, kernel does not know there is no disc.
I noticed it when DVD disc was loading and until it did, lsblk was
happily reporting that 627656704 bytes CD is still there for every
userspace app to use and send queries to. And queries are being sent, my
guess is from file manager, to query and display CD name etc. if there
is one, because it thinks everything is fine and its okay to ask.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀⠀⠀

[Thomas Schmitt]

Hi,

piorunz wrote:
> CD inserted:
> $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> hp hp_DVDRW_GUE1N 627656704 2048 2048
> DVD inserted:
> $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> hp hp_DVDRW_GUE1N 3353346048 2048 2048

So we know that the kernel-perceived block size is correctly 2048 when
a medium is inserted. Do the complaints continue to appear in the logs
while the medium is loaded ?

The remaining question is what the kernel perceives after the system
has booted and no medium was inserted since then. And for completeness,
what the kernel perceives when the tray is empty after the running system
already saw a medium in it

(I'll give my own answers to that question further below.)

> I noticed it when DVD disc was loading and until it did, lsblk was happily
> reporting that 627656704 bytes CD is still there for every userspace app to
> use and send queries to.

The problem is actually that the size does not get set to 0 when the medium
gets unloaded. (Further bug: Blank media get attributed size 2048.)

In preparation of a fix, Karel Zak of util-linux changed lsblk so that it
would report devices of SIZE 0. But after getting no feedback on other bug
fix patches for Linux, i did not submit my fix for the size problem to the
kernel developers.
Back in september 2020 it would have consisted of four patches:
cdrom: introduce new exported function cdrom_disc_information()
sr: introduce resetter functions for sr_cd_check() and get_sectorsize()
sr: attribute size 0 to "empty" (aka blank) media
sr: attribute size 0 to not loaded or unusable media

> And queries are being sent, my guess is from file
> manager, to query and display CD name etc. if there is one, because it
> thinks everything is fine and its okay to ask.

That's my suspicion too.

I now am baffled by the result on a Debian 11 with drives not used since
booting it:

$ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*

VENDOR MODEL SIZE PHY-SEC LOG-SEC

PIONEER PIONEER_BD-RW_BDR-S09 1073741312 512 512
TSSTcorp CDDVDW_SH-S223B 1073741312 512 512

The first one is a built-in SATA drive, the second is SATA in a USB box.
All are perceived with wrong block size and a fictional capacity of

1 GiB - 512 bytes.

I'd say that this is some clueless default setting that must be new since
kernel 4.19 of Debian 10. Back in 2020 i would quite surely have noticed
if that behavior had been shown.

$ uname -a
Linux ... 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

Are users of Debian 10 (actually of kernel 4.19) here who are willing to
run
lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
directly after booting with empty drive tray ?


Whatever, when i let a DVD+RW wander through the drives and then put it
back on the shelf, i afterwards get the usual outdated capacity and the
correct block size:

VENDOR MODEL SIZE PHY-SEC LOG-SEC

PIONEER PIONEER_BD-RW_BDR-S09 4700372992 2048 2048
TSSTcorp CDDVDW_SH-S223B 4700372992 2048 2048

>From now on the system seems to behave like i am used from older Debian
versions. Wrong but reliable.

I know of no way to bring the capacity perception to 0. But the size can
be reduced to 2048 bytes by inserting a blank CD-R, CD-RW, DVD-R, DVD+R,
or unformatted blank DVD-RW or BD-R medium. A totally unused BD-RE or
DVD+RW might do the trick too (do not allow a burn program to format them).

Here i used a blank BD-R on the Pioneer and a blank DVD-R on the Samsung:

VENDOR MODEL SIZE PHY-SEC LOG-SEC

PIONEER PIONEER_BD-RW_BDR-S09 2048 2048 2048
TSSTcorp CDDVDW_SH-S223B 2048 2048 2048

This state remains when the medium is removed until the next medium is
inserted and fully assessed by the drive.

The drive groping software on your machine seems to want to read more than
just a single block of 2048 bytes. So reducing the perceived size to 2048
by inserting a blank medium once after booting might already do the trick.


(I wonder why the "VENDOR" name gets prepended to the actual "MODEL" name
with the Pioneer drive and probably the HP one of piorunz but not to the
Samsung drive CDDVDW_SH-S223B.
I know that the Pioneer identifies its model name as "BD-RW BDR-S09",
not as "PIONEER BD-RW BDR-S09".)

[Richmond]

"Thomas Schmitt" <scdb...@gmx.net> writes:

>
> Are users of Debian 10 (actually of kernel 4.19) here who are willing to
> run
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> directly after booting with empty drive tray ?

lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODEL SIZE PHY-SEC LOG-SEC

TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512 512

4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux

This is a laptop where I rarely use the CD/DVD. Note it is not the same
computer as was getting errors before, that was debian 11.

[Thomas Schmitt]

Hi,

i wrote:
> > Back in 2020 i would quite surely have noticed
> > if that behavior had been shown.

Richmond wrote:
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512 512
>
> 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux

So this behavior is not new.

> This is a laptop where I rarely use the CD/DVD. Note it is not the same
> computer as was getting errors before, that was debian 11.

I assume that you will see the same result there.
It would explain the block address of the first read attempt and the
log messages about unaligned access.

kernel: [ 9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00
kernel: [ 9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer

If you have some blank optical medium, then try whether the emitter of
the read attempt can be discouraged if the drive is perceived as offering
just one block of 2048 bytes.

----------------------------------------------------------------------

The unresolved riddle is which software began to try reading from the
optical drive after your recent package installations or upgrades.
It might be a different one than the software which does similar read
attempts on piorunz' machine since years.

In any case these softwares inquire the device capacity from systemd or
directly from the kernel. Then they try to read end and start of the
obtained capacity.
There are many motivations to read the start of the device and fewer to
read its end. One reason to read the end is the GPT backup header, which
would sit 512 bytes before the end.
The main GPT header block is at byte 512 of the storage device.
This would explain the next failed read attempt:

kernel: [ 9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00
00 00 00 02 00

I wonder why the caller did not want only 512 or 1024 bytes. The number
of 2 requested blocks cannot come from the read-ahead mechanism of the
Linux block layer.

I would still place my bet on something like blkid, which wants to know
whether there is a partition table. Maybe there was a change about a
customer of libblkid.

[piorunz]

On 25/01/2023 10:38, Thomas Schmitt wrote:
> Are users of Debian 10 (actually of kernel 4.19) here who are willing to
> run
> lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
> directly after booting with empty drive tray ?

$ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODEL SIZE PHY-SEC LOG-SEC

hp hp_DVDRW_GUE1N 1073741312 512 512

$ sudo dmesg | grep sr0
[ 2.635585] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram
cd/rw xa/form2 cdda tray
[ 2.707836] sr 1:0:0:0: Attached scsi CD-ROM sr0

Invisible medium seen by kernel is exactly 1GiB in size minus 512 bytes.
But no errors in dmesg yet.

By the way this is after power off, power on, with freshly upgraded
stable kernel 5.10.0-21.

[Richmond]

"Thomas Schmitt" <scdb...@gmx.net> writes:

> I assume that you will see the same result there.

lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*
VENDOR MODEL SIZE PHY-SEC LOG-SEC

HL-DT-ST HL-DT-ST_DVDRAM_GH15F 1073741312 512 512

5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

>
> If you have some blank optical medium, then try whether the emitter of
> the read attempt can be discouraged if the drive is perceived as offering
> just one block of 2048 bytes.

I don't know how to do that. Do you mean make a DVD with 1 block of data?

> There are many motivations to read the start of the device and fewer to
> read its end. One reason to read the end is the GPT backup header, which
> would sit 512 bytes before the end.
> The main GPT header block is at byte 512 of the storage device.

I am not using GPT on any systems. They all have ext4 root partitions.

[Thomas Schmitt]

Hi,

i wrote:
> > If you have some blank optical medium, then try whether the emitter of
> > the read attempt can be discouraged if the drive is perceived as offering
> > just one block of 2048 bytes.

Richmond wrote:
> I don't know how to do that. Do you mean make a DVD with 1 block of data?

Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW.
The size perception will change to

VENDOR MODEL SIZE PHY-SEC LOG-SEC

HL-DT-ST HL-DT-ST_DVDRAM_GH15F 2048 2048 2048

Pull it out again, and this state will persist until you put in a medium
which is readable, or until you reboot.

> > There are many motivations to read the start of the device and fewer to
> > read its end. One reason to read the end is the GPT backup header, which
> > would sit 512 bytes before the end.
> > The main GPT header block is at byte 512 of the storage device.

> I am not using GPT on any systems. They all have ext4 root partitions.

GPT might be used to mark partitions. It is the newer partition table
format, which replaced most usages of the old MBR partition table.

Whatever, it is not about what you actually use, but what the yet unknown
software is looking for. libblkid would check for properties like
PARTTYPE, PARTLABEL, or PARTUUID. Therefore it would look for GPT header
blocks, regardless whether they are there.

[Richmond]

"Thomas Schmitt" <scdb...@gmx.net> writes:

> Hi,
>
> i wrote:
>> > If you have some blank optical medium, then try whether the emitter of
>> > the read attempt can be discouraged if the drive is perceived as offering
>> > just one block of 2048 bytes.
>
> Richmond wrote:
>> I don't know how to do that. Do you mean make a DVD with 1 block of data?
>
> Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW.
> The size perception will change to
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> HL-DT-ST HL-DT-ST_DVDRAM_GH15F 2048 2048 2048
>
> Pull it out again, and this state will persist until you put in a medium
> which is readable, or until you reboot.
>

I put in a blank DVD+RW.

lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr*

VENDOR MODEL SIZE PHY-SEC LOG-SEC
HL-DT-ST HL-DT-ST_DVDRAM_GH15F 2048 2048 2048

It has stayed like this after I removed it.

[Richmond]

I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting
the blank disk in did not change the values, it still showed 512.

[Thomas Schmitt]

Hi,

Richmond wrote:
> VENDOR MODEL SIZE PHY-SEC LOG-SEC
> HL-DT-ST HL-DT-ST_DVDRAM_GH15F 2048 2048 2048
> It has stayed like this after I removed it.

Next question would be whether the error messages stopped after this.


But re-reading your initial post:

> > I see errors when booting, which also appear in /var/log/messages:

it might be that there are no further (periodic) read attempts.

If the messages only appear once during the boot procedure, then i think
the issue is explored as far as possible without starting kernel
programming.
The Linux kernel is buggy in respect to sector size and readable
capacity of empty optical drives or drives with unreadable media.
Ignore the error messages during system startup.

You could try whether having a CD or DVD in the drive while booting
silences the error messages. But i would not consider this as a workable
long term solution.

It is still not known what change on your system caused the read attempts
to begin. The involved software could be made smarter to ignore sr
devices which bear the impossible sector size 512. This size indicates
that no medium was seen in the device since the device was started up.

> I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting
> the blank disk in did not change the values, it still showed 512.

It's a vivid bug, then.

So my proposal to have a CD or DVD in the tray while booting would need
the additional prescription that the medium must really be readable.
And the possible workaround for periodic read attempts would not work
any more.

[piorunz]

On 25/01/2023 15:26, Thomas Schmitt wrote:
> it might be that there are no further (periodic) read attempts.
>
> If the messages only appear once during the boot procedure, then i think
> the issue is explored as far as possible without starting kernel
> programming.

Just to briefly comment on this - read attempts continue, please see my
earlier messages in this thread, including original bug report 2 years
ago. dmesg is infested with these errors in red, periodically there is
another one, triggered by something, it goes on forever.
Inserting blank disc on every reboot is not a solution in my opinion.
And I didn't verified it myself, so I don't know if its going to work in
my case, or Linux at some point will realize the trick. :D

[Thomas Schmitt]

Hi,

piorunz wrote:
> read attempts continue,

Obviously your drive groper is different from Richmond's. Both get lured
into their activities by the kernel bugs.

> Inserting blank disc on every reboot is not a solution in my opinion. And I
> didn't verified it myself,

It would be interesting to know, nevertheless.

> so I don't know if its going to work in my case,
> or Linux at some point will realize the trick. :D

It might last a while until Linux gets to a better behavior.
My patches from 2020 are not totally trivial. So even if they still are
applicable and there is a sponsor who gets them reviewed, i doubt that
they would easily get accepted.

Richmond reports from OpenSUSE with kernel 5.3 that the handling of blank
media seems to have changed. But i still see it with 5.10.

If you can identify the program which gets lured into probing the drive,
then you could ask its developer to ignore optical drives of which the
kernel reports sector size 512. But as soon as a medium was in the drive,
the deception begins again.

[Thomas Amm]

First you might remove the pktcdvd module:

pktsetup -d /dev/sr0 -q

Not sure if it causes this specific problem but it is for pre-
growisofs CD-RW writing. Nobody uses that anymore and it interferes
with "straight" CD/DVD-burning. If the error messages still show up
after that it's most likely an unreadable DVD or your DVD-drive is
beginning to fail. Usually the tracking lasers in these devices get
deadjusted after a few years and readjusting them would be too much
effort.

[Thomas Schmitt]

Hi,

Thomas Amm wrote:
> First you might remove the pktcdvd module:

> Not sure if it causes this specific problem but it is for pre-
> growisofs CD-RW writing.

The packet writing device bundles smaller write requests in larger chunks
and ensures to write only at addresses and with sizes which are aligned
to the medium's Fixed Packet Size. With CD this size can be chosen.
With DVD it is 16 = 32 KiB. With BD it is 32 = 64 KiB.


> Nobody uses that anymore

Packet writing is life prolonging with random access writing to formatted
CD-RW and maybe to DVD-RAM, DVD+RW, and BD-RE.
It is needed for random access writing to formatted DVD-RW, which only
accept write operations with 32 KiB granularity.

Burn programs do not need /dev/pktcdvd, because they usually write
sequentially with a suitable alignment.
(.. and sequential writing is the most life prolonging way of writing.)

> and it interferes with "straight" CD/DVD-burning.

Not necessarily. The /dev/pktcdvd device uses the /dev/sr device when it
performs its operations. But as long as it is not used, the /dev/sr
device will not be disturbed. And even if so, then the media types which
are suitable for /dev/pktcdvd can stand WRITE commands from two
uncoordinated processes.

[Richmond]

Richmond <rich...@criptext.com> writes:

> It may be a coincidence but yesterday I installed some
> libguestfs-tools. Now I see errors when booting, which also appear in
> /var/log/messages:
>
> kernel: [ 9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s
> kernel: [ 9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready [current]
> kernel: [ 9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not present - tray closed
> kernel: [ 9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00
> kernel: [ 9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer
> kernel: [ 9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer
> kernel: [ 9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer

These errors started occurring again. This time I knew what I had done, I
commented out a line in fstab referencing a swap space, because the
system had two swap spaces defined and I wanted to use one for something
else. What I overlooked was that this swap space was also the resume
space.

During the boot there were other messages which did not appear in the
journal so I filmed them with a smart phone:

Running /scripts/local-block..

These occurred over and over, but allowed me to find this site:

https://tipstricks.itmatrix.eu/solving-the-running-scripts-local-block-loop-while-booting-in-linux/

Which explained the problem and how to fix it. I had already edited:

/etc/initramfs-tools/conf.d/resume

To use the other swap space. But this did not help because I missed this
crucial step:

sudo update-initramfs -u

After I did this, the errors went away.

I don't know why the errors reference sr0, it's a mystery.

[piorunz]

On 02/02/2023 14:05, Richmond wrote:
> After I did this, the errors went away.
>
> I don't know why the errors reference sr0, it's a mystery.

They will most likely come back, this error is related to optical drive,
nothing to do with swap space.

[Richmond]

piorunz <pio...@gmx.com> writes:

> On 02/02/2023 14:05, Richmond wrote:
>> After I did this, the errors went away.
>> I don't know why the errors reference sr0, it's a mystery.
>
> They will most likely come back, this error is related to optical
> drive, nothing to do with swap space.

Perhaps the system was looking for resume space on sr0? It seems a
strange thing to do. But also it is quite a coincidence if the errors
occur when the resume space is messed up, and they go away when it is
fixed. That has happened twice.

It might be a good way for someone to reproduce the error on some other
machine. I have no problems with the CD/DVD writer and have used it a
few times recently.

[Thomas Schmitt]

Hi,

Richmond wrote:
> Perhaps the system was looking for resume space on sr0?

That's my guess too. We already knew that the read address and block size
come from the kernel's brain damaged representation of a drive which has
not seen a medium since boot. My suspicion was that libblkid is involved.
But it was not clear what software wanted the service of libblkid.
Now we have a candidate for that.

> It seems a strange thing to do.

Indeed. But why should only the kernel be brain damaged ?

(I expect some generic UUID searcher for block devices. Probably the sr
devices are near the end of its iteration. So one would not see any
protest in the log if the UUID is found on the device which is tried
earlier.)

> But also it is quite a coincidence if the errors
> occur when the resume space is messed up, and they go away when it is
> fixed. That has happened twice.

Empirically the situation is clear.

Still missing is the code which wants to inspect sr. I tried to learn
about /scripts/local-block in initramfs-tools. Regrettably it seems to
be about a local customization of the initrd, which is not done by
initramfs-tools but by its customers.
A search for "local-block" in Debian's source collection by
https://codesearch.debian.net/search?q=local-block
did not yield good candidates.

Do you see something related to resume in the output of
ls /usr/share/initramfs-tools/scripts/local-block

(If not there, then in the /scripts/local-block directory of the initrd ?)

[Richmond]

"Thomas Schmitt" <scdb...@gmx.net> writes:

> Indeed. But why should only the kernel be brain damaged ?
>
> (I expect some generic UUID searcher for block devices. Probably the sr
> devices are near the end of its iteration. So one would not see any
> protest in the log if the UUID is found on the device which is tried
> earlier.)

It crossed my mind that someone could conceivably be using the Universal
Disk Format on a DVD RW.

> Still missing is the code which wants to inspect sr. I tried to learn
> about /scripts/local-block in initramfs-tools. Regrettably it seems to
> be about a local customization of the initrd, which is not done by
> initramfs-tools but by its customers.
> A search for "local-block" in Debian's source collection by
> https://codesearch.debian.net/search?q=local-block
> did not yield good candidates.
>
> Do you see something related to resume in the output of
> ls /usr/share/initramfs-tools/scripts/local-block

There is no such file. Earlier I ran this:

find / -print|grep "scripts/local-block"

and it found nothing, which led me to believe it is some temporary file...

>
> (If not there, then in the /scripts/local-block directory of the initrd ?)

I don't know how I would look in that. Is it in RAM at boot time?

In the log which appears on the screen it says:

Begin: Waiting for suspend/resume device ... Begin: Running
/scripts/local-block ... done.
random: crng init done
/scripts/local-block ... done.

Then this last line was repeated 17 times and much time was spent. Then
it gave up.

[Michel Verdier]

Le 2 février 2023 Richmond a écrit :

> There is no such file. Earlier I ran this:
>
> find / -print|grep "scripts/local-block"
>
> and it found nothing, which led me to believe it is some temporary file...
>>
>> (If not there, then in the /scripts/local-block directory of the initrd ?)

its part of initramfs-tools to build initrd when you use cryptsetup,
mdadm, etc

$ locate local-block
/usr/share/initramfs-tools/scripts/local-block
/usr/share/initramfs-tools/scripts/local-block/cryptroot

$ apt-file search /usr/share/initramfs-tools/scripts/local-block
cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot
lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2
mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm
osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl

[David Wright]

On Thu 02 Feb 2023 at 21:58:54 (+0000), Richmond wrote:

> "Thomas Schmitt" <scdb...@gmx.net> writes:
> >
> > (If not there, then in the /scripts/local-block directory of the initrd ?)
>
> I don't know how I would look in that. Is it in RAM at boot time?

Choose your kernel ↓↓↓↓↓↓↓↓↓↓ Pick any name ↓↓↓↓↓↓↓↓

$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
cpio: etc/console-setup/null: Cannot mknod: Operation not permitted
$ ls -GlgR /tmp/initrd21/main/scripts/
/tmp/initrd21/main/scripts/:
total 48
-rw-r--r-- 1 11152 Jan 14 2021 functions
drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom
drwxr-xr-x 2 4096 Feb 2 18:45 init-top
-rw-r--r-- 1 5303 Jan 14 2021 local
drwxr-xr-x 2 4096 Feb 2 18:45 local-block
drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom
drwxr-xr-x 2 4096 Feb 2 18:45 local-premount
drwxr-xr-x 2 4096 Feb 2 18:45 local-top
-rw-r--r-- 1 3093 Jan 14 2021 nfs

/tmp/initrd21/main/scripts/init-bottom:
total 8
-rw-r--r-- 1 77 Jan 23 21:46 ORDER
-rwxr-xr-x 1 611 Aug 7 08:25 udev

/tmp/initrd21/main/scripts/init-top:
total 20
-rw-r--r-- 1 314 Jan 23 21:46 ORDER
-rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide
-rwxr-xr-x 1 296 Jan 14 2021 blacklist
-rwxr-xr-x 1 167 Jan 14 2021 keymap
-rwxr-xr-x 1 568 Aug 7 08:25 udev

/tmp/initrd21/main/scripts/local-block:
total 8
-rw-r--r-- 1 82 Jan 23 21:46 ORDER
-rwxr-xr-x 1 246 Feb 1 2022 cryptroot

/tmp/initrd21/main/scripts/local-bottom:
total 20
-rw-r--r-- 1 336 Jan 23 21:46 ORDER
-rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc
-rwxr-xr-x 1 449 Feb 1 2022 cryptopensc
-rwxr-xr-x 1 307 Feb 1 2022 cryptroot
-rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g

/tmp/initrd21/main/scripts/local-premount:
total 12
-rw-r--r-- 1 165 Jan 23 21:46 ORDER
-rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g
-rwxr-xr-x 1 863 Jan 14 2021 resume

/tmp/initrd21/main/scripts/local-top:
total 20
-rw-r--r-- 1 162 Jan 23 21:46 ORDER
-rwxr-xr-x 1 757 Feb 1 2022 cryptopensc
-rwxr-xr-x 1 8630 Feb 1 2022 cryptroot
$

This is a desktop with random-key swap, so no resume.
There are encrypted partitions present. YMMV.

Cheers,
David.

[Richmond]

sudo locate local-block

produced no output.

sudo apt-file search /usr/share/initramfs-tools/scripts/local-block

cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot
lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2
mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm
osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl

I don't have an encrypted file system.

sudo aptitude show cryptsetup-initramfs|grep State
State: not installed
sudo aptitude show lvm2|grep State
State: not installed
sudo aptitude show mdadm|grep State
State: not installed
sudo aptitude show osk-sdl|grep State
State: not installed

[Richmond]

~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21
~$ find /tmp/initrd21/ -print|grep "local-block"
~$ find /tmp/initrd21/ -print|grep "local"

/tmp/initrd21/usr/local
/tmp/initrd21/usr/local/share
/tmp/initrd21/usr/local/share/fonts
/tmp/initrd21/usr/local/share/fonts/.uuid
/tmp/initrd21/scripts/local-bottom
/tmp/initrd21/scripts/local-bottom/ntfs_3g
/tmp/initrd21/scripts/local-bottom/ORDER
/tmp/initrd21/scripts/local
/tmp/initrd21/scripts/local-premount
/tmp/initrd21/scripts/local-premount/ntfs_3g
/tmp/initrd21/scripts/local-premount/ORDER
/tmp/initrd21/scripts/local-premount/resume

No local block. :-?

find /tmp/initrd21/ -print|grep local|grep block

No output here.

[Thomas Schmitt]

Hi,

Richmond wrote:
> No local block. :-?

Maybe you can find our from where the message comes:

grep -r 'Running.*scripts.*local-block' /tmp/initrd21

[Richmond]

"Thomas Schmitt" <scdb...@gmx.net> writes:

> Hi,
>
> Richmond wrote:
>> No local block. :-?
>
> Maybe you can find our from where the message comes:
>
> grep -r 'Running.*scripts.*local-block' /tmp/initrd21
>
>

grep -r 'Running.*scripts.*local-block' /tmp/initrd21
/tmp/initrd21/scripts/local: [ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"

This contains:

===============================================================

local_block()
{
[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
run_scripts /scripts/local-block "$@"
[ "$quiet" != "y" ] && log_end_msg
}

===============================================================


Then later this, which would explain the delays: (The video shows
"waiting for suspend/resume device")

===============================================================
# If the root device hasn't shown up yet, give it a little while
# to allow for asynchronous device discovery (e.g. USB). We
# also need to keep invoking the local-block scripts in case
# there are devices stacked on top of those.
if ! real_dev=$(resolve_device "${dev_id}") ||
! get_fstype "${real_dev}" >/dev/null; then
log_begin_msg "Waiting for ${name}"

# Timeout is max(30, rootdelay) seconds (approximately)
slumber=30
if [ "${ROOTDELAY:-0}" -gt $slumber ]; then
slumber=$ROOTDELAY
fi

while true; do
sleep 1
time_elapsed="$(time_elapsed)"

local_block "${dev_id}"

# If mdadm's local-block script counts the
# number of times it is run, make sure to
# run it the expected number of times.
while true; do
if [ -f /run/count.mdadm.initrd ]; then
count="$(cat /run/count.mdadm.initrd)"
elif [ -n "${count}" ]; then
# mdadm script deleted it; put it back
count=$((count + 1))
echo "${count}" >/run/count.mdadm.initrd
else
:

[David Wright]

Well, no, but there is a resume sitting there in local-premount,
which suggests to me¹ that you perhaps have something in
/etc/initramfs-tools/conf.d/resume. Has that been reported?

I'd also be interested to see the output from:

$ ls -lR /dev/disk | grep sr

and

$ grep -e sr -e sw /etc/fstab

The intent of that last pattern is to see the swap lines that you
have been commenting out.

Of course, we might not see anything unusual anywhere while the
machines are in their "fixed" state (whatever that means).

¹ This is a guess, based on the fact that I also have that file in
initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume,
and something somewhere has to read the word "none".

Cheers,
David.

[John Covici]

For instance I just got a post from Freedom Scientific which had the
announcement in the Email and also link to the post.

--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?

John Covici wb2una
cov...@ccs.covici.com

[John Covici]

sorry, replied to wrong list.

[Max Nikulin]

On 03/02/2023 01:47, Richmond wrote:
>
> It might be a good way for someone to reproduce the error on some other
> machine. I have no problems with the CD/DVD writer and have used it a
> few times recently.

Do you see the same errors if kernel command line is edited from grub to
pass non-existing UUID specified in the resume=UUID=... argument? It
might be a quick way to reproduce the issue.

Is it realistic that usually optical drives are skipped during UUID
searches, but specific driver exposes a wrong property, so the device is
considered as a regular disk drive?

[Thomas Schmitt]

Hi,

Richmond wrote:
> /tmp/initrd21/scripts/local: [ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"

> [...]

> local_block()
> {
> [ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
> run_scripts /scripts/local-block "$@"

> [...]

> Then later this, which would explain the delays: (The video shows
> "waiting for suspend/resume device")

> [...]

> log_begin_msg "Waiting for ${name}"

> [...]

> while true; do
> sleep 1
> time_elapsed="$(time_elapsed)"
>
> local_block "${dev_id}"

I remember to have seen this code under
https://sources.debian.org/src/initramfs-tools/unstable/
when i looked for occurences of "local-block". (This URL is currently not
working for me.)
I did not find any built-in runs of programs like blkid or lsblk. Thus i
concluded that such runs would be in files of /scripts/local-block or other
local customization of the initrd.

We are most probably at the right spot of initramfs-tools.
Maybe the script which runs blkid or alike has vanished during the recent
reconstruction of the initrd which fixed the problems ?

Does fgrep find anything about "blkid" in /tmp/initrd21 ?

[Richmond]

I didn't need to reconstruct initrd to cause the problems. As far as I
remember all I did was destroy the swap space, having commented-it-out
of fstab. So I imagin that the scripts are the same. But I could test
that as suggested by Max Nikulin by altering the resume parameter from
grub before booting.

>
> Does fgrep find anything about "blkid" in /tmp/initrd21 ?

I did it like this:

find /tmp/initrd21/ -print|xargs grep -i blkid|less


/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid --noraid"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*", IMPORT{builtin}="blkid"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{builtin}="blkid"
/tmp/initrd21/scripts/functions: # blkid has a more complete list of file systems,
/tmp/initrd21/scripts/functions: FSTYPE=$(blkid -o value -s TYPE "${FS}") || return
/tmp/initrd21/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || return 1
/tmp/initrd21/scripts/local: # device in /dev and isn't resolvable by blkid (e.g. mtd0)

[Richmond]

Max Nikulin <mani...@gmail.com> writes:

> On 03/02/2023 01:47, Richmond wrote:
>> It might be a good way for someone to reproduce the error on some
>> other
>> machine. I have no problems with the CD/DVD writer and have used it a
>> few times recently.
>
> Do you see the same errors if kernel command line is edited from grub
> to pass non-existing UUID specified in the resume=UUID=... argument?
> It might be a quick way to reproduce the issue.

I looked in grub but couldn't see any resume parameter. I think the way
things work has changed, and this is hidden away somewhere.

>
> Is it realistic that usually optical drives are skipped during UUID
> searches, but specific driver exposes a wrong property, so the device
> is considered as a regular disk drive?

I don't know.

[David Wright]

On Sat 04 Feb 2023 at 12:37:27 (+0000), Richmond wrote:
> Max Nikulin <mani...@gmail.com> writes:
> > On 03/02/2023 01:47, Richmond wrote:
> >> It might be a good way for someone to reproduce the error on some
> >> other
> >> machine. I have no problems with the CD/DVD writer and have used it a
> >> few times recently.
> >
> > Do you see the same errors if kernel command line is edited from grub
> > to pass non-existing UUID specified in the resume=UUID=... argument?
> > It might be a quick way to reproduce the issue.
>
> I looked in grub but couldn't see any resume parameter. I think the way
> things work has changed, and this is hidden away somewhere.

There are hundreds and hundreds of kernel command-line parameters,
so I'm not sure how you expect to see any evidence of each one in
Grub's configuration. Imagine how often any one particular parameter
is employed by someone, eg,

earlycon= [KNL] Output early console device and options.
When used with no options, the early console is
determined by stdout-path property in device tree's
chosen node or the ACPI SPCR table if supported by
the platform.
lpuart,<addr>
lpuart32,<addr>
Use early console provided by Freescale LP UART driver
found on Freescale Vybrid and QorIQ LS1021A processors.
A valid base address must be provided, and the serial
port must already be setup and configured.

https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html

One caveat, though, about adding resume= in Grub. If a system has no
mention of resume when the initrd is built, I don't know whether the
scripts are included for handling it. In your case, you appear to
have these scripts, so it should be ok. Mind you, have you reported
what's in /etc/initramfs-tools/conf.d/resume? I've asked this before
(see last point below).

> > Is it realistic that usually optical drives are skipped during UUID
> > searches, but specific driver exposes a wrong property, so the device
> > is considered as a regular disk drive?
>
> I don't know.

Much of what I see grepped in this thread is stuff that I could read
off my machine. For example:

$ grep -r -I blkid
main/usr/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{builtin}="blkid"
main/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
main/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid --noraid"
main/usr/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*", IMPORT{builtin}="blkid"
main/usr/lib/cryptsetup/functions: elif blk_t="$(blkid -s TYPE -o value -- "$s")" && [ "$blk_t" = "BitLocker" ]; then
main/usr/lib/cryptsetup/functions: spec="$(blkid -l -t "$spec" -o device)" || spec=
main/usr/lib/cryptsetup/functions: if uuid="$(blkid -s UUID -o value -- "$device")" && [ -n "$uuid" ]; then
main/scripts/local: # device in /dev and isn't resolvable by blkid (e.g. mtd0)
main/scripts/functions: # blkid has a more complete list of file systems,
main/scripts/functions: FSTYPE=$(blkid -o value -s TYPE "${FS}") || return
main/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || return 1
$

(I have a few extra crypto lines.)

I wouldn't mind seeing a few properties and configuration parameters
from your machine, which will obviously differ from mine. (See my
previous post.)

Cheers,
David.

[Thomas Schmitt]

Hi,

i wrote:
> > Maybe the script which runs blkid or alike has vanished during the recent
> > reconstruction of the initrd which fixed the problems ?

Richmond wrote:
> I didn't need to reconstruct initrd to cause the problems. As far as I
> remember all I did was destroy the swap space, having commented-it-out
> of fstab. So I imagin that the scripts are the same.

I rather meant the run which you meantioned in your mail of Thu,
02 Feb 2023 14:05:37 +0000:

> > > sudo update-initramfs -u

> > > After I did this, the errors went away.

It is possible that there were files in /scripts/local-block before this
run.

> find /tmp/initrd21/ -print|xargs grep -i blkid|less

> /tmp/initrd21/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || return 1

This is the kind of blkid run which i expect to cause the mislead read
attempts to the pseudo-end of /dev/sr0. If the given attribute is not
found, then it cycles over all block devices, not knowing about the
purpose of resuming and the usefulness of the device types.

It is in function resolve_device() which obviously shall find a device
matching either LABEL, UUID, PARTLABEL, or PARTUUID.

A plausible caller of resolve_device() would be in hooks/resume:

if resume_dev_node="$(resolve_device "$RESUME")" && \
blkid -p -n swap "$resume_dev_node" >/dev/null 2>&1; then

But i fail to make the connection to the loop with the messages about
/scripts/local-block.

[Richmond]

David Wright <deb...@lionunicorn.co.uk> writes:

> On Sat 04 Feb 2023 at 12:37:27 (+0000), Richmond wrote:
>> Max Nikulin <mani...@gmail.com> writes:
>> > On 03/02/2023 01:47, Richmond wrote:
>> >> It might be a good way for someone to reproduce the error on some
>> >> other
>> >> machine. I have no problems with the CD/DVD writer and have used it a
>> >> few times recently.
>> >
>> > Do you see the same errors if kernel command line is edited from grub
>> > to pass non-existing UUID specified in the resume=UUID=... argument?
>> > It might be a quick way to reproduce the issue.
>>
>> I looked in grub but couldn't see any resume parameter. I think the way
>> things work has changed, and this is hidden away somewhere.
>
> There are hundreds and hundreds of kernel command-line parameters,
> so I'm not sure how you expect to see any evidence of each one in
> Grub's configuration.

We were talking about editing from grub during boot time, not looking in
grubs configuration.

[David Wright]

You wrote: "I looked in grub".

My interpretation: "I looked in grub.cfg by typing 'E' on one or more
of the entries in Grub's blue screen when booting the computer".

If my interpretation is correct, please reread my post and, if you
think Max's suggested action would be productive, try it out.

If not, please elaborate on your use of the word "grub" in
"I looked in grub".

Cheers,
David.

[Richmond]

David Wright <deb...@lionunicorn.co.uk> writes:

> On Sat 04 Feb 2023 at 17:38:25 (+0000), Richmond wrote:
>> David Wright <deb...@lionunicorn.co.uk> writes:
>> > On Sat 04 Feb 2023 at 12:37:27 (+0000), Richmond wrote:
>> >> Max Nikulin <mani...@gmail.com> writes:
>> >> > On 03/02/2023 01:47, Richmond wrote:
>> >> >> It might be a good way for someone to reproduce the error on some
>> >> >> other
>> >> >> machine. I have no problems with the CD/DVD writer and have used it a
>> >> >> few times recently.
>> >> >
>> >> > Do you see the same errors if kernel command line is edited from grub
>> >> > to pass non-existing UUID specified in the resume=UUID=... argument?
>> >> > It might be a quick way to reproduce the issue.
>> >>
>> >> I looked in grub but couldn't see any resume parameter. I think the way
>> >> things work has changed, and this is hidden away somewhere.
>> >
>> > There are hundreds and hundreds of kernel command-line parameters,
>> > so I'm not sure how you expect to see any evidence of each one in
>> > Grub's configuration.
>>
>> We were talking about editing from grub during boot time, not looking in
>> grubs configuration.
>
> You wrote: "I looked in grub".
>
> My interpretation: "I looked in grub.cfg by typing 'E' on one or more
> of the entries in Grub's blue screen when booting the computer".
>

I see. Max (and you) mean add the resume parameter, not edit an existing one. I
was looking for an existing one. I will try this.

[Richmond]

It worked, I recreated the error, including the stuff about sr0.

The errors about sr0 come before the stuff about resume.

[Max Nikulin]

On 05/02/2023 03:12, Richmond wrote:
> The errors about sr0 come before the stuff about resume.

Does the following command generate similar errors (taken from initrd
scripts, UUID is intentionally not from the set of existing partitions)?

blkid -l -t UUID=11111111-1111-1111-1111-111111111111 -o device

I would try it at first in normally running system. Perhaps some caches
may be involved preventing query to the optical drive. I have no bright
idea how to cause drop to initrd shell to try the command there, perhaps
root=... kernel command line parameter may be removed or changed to
non-existing device from grub prompt.

I am unsure which particular command from initrd scans devices, my guess
may be wrong.

[Richmond]

It didn't produce any output.

[Max Nikulin]

On 06/02/2023 00:11, Richmond wrote:

> Max Nikulin writes:
>
>> On 05/02/2023 03:12, Richmond wrote:
>>> The errors about sr0 come before the stuff about resume.
>>
>> Does the following command generate similar errors (taken from initrd
>> scripts, UUID is intentionally not from the set of existing
>> partitions)?
>>
>> blkid -l -t UUID=11111111-1111-1111-1111-111111111111 -o device
>

> It didn't produce any output.

Sorry, I have no motivation to dig into /usr/share/initramfs-tools
deeper. Perhaps you may try debug kernel option in combination with bad
UUID for resume from grub

... debug resume=UUID=11111111-1111-1111-1111-111111111111

with hope to get more verbose output around of optical drive access.

You may try to report a bug against initramfs-tools that errors messages
are unhelpful and even confusing when resume configuration is
inconsistent due to a mistake. Perhaps resume argument may be validated
during generation of initrd, however in some cases it will give false
positive.