Re: kernel errors
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 ?)
Have a nice day :)
Thomas
Reply to: