Re: kernel errors

[David Wright <deblis@lionunicorn.co.uk>]

On Sat 04 Feb 2023 at 12:37:27 (+0000), Richmond wrote:
> Max Nikulin <manikulin@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.