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
