Hi, Borden wrote: > If I knew how to filter journald (or anything in /var/log) to get relevant > information, I could pastebin it.
If you have a large stream of messages, try to filter it through grep -C 5 ' sr' i wrote: > > eject /dev/sr0 > For me, if the drive is hard locked, it's soft locked, too. Does "eject" tell any error message ? Can xorriso access the drive without error messages ? xorriso -outdev /dev/sr0 > > You can avoid the higher SCSI driver layers of Linux by letting xorriso > > read the DVD. [...] > > xorriso -outdev /dev/sr0 -check_media use=outdev what=disc -- > I'm confused, the xorriso documentation I read said that it's only for > writing media, not reading damaged media. The command -check_media is a side job of xorriso. It exists mainly because the main job of xorriso contains the task of loading ISO 9660 sessions from optical media. But after writing a new session and before the drive tray gets reloaded, the Linux block device layer has no knowledge about the new content of the medium. So xorriso needs to read via the generic SCSI layer which does not keep outdated media status information. Having this capability, it seemed natural to enable reading of file content (by e.g. command -extract or -check_md5_r) or checkreading of the whole medium. The hoped-for advantage of -check_media and its use of generic SCSI is that you might see original error messages as reported by the drive rather than the highly processed messages which the block device layer creates from the drive messages. (Also you get the error messages on stderr instead of getting them written into the system logs.) If the drive is unwilling to communicate, then of course there will not be much difference between block layer and generic layer. But at least you get a second opinion. > As someone else suggested, I'm using ddrescue to try to extract from the > damaged media. Are you recommending that I use xorriso to get the media's > damaged blocks? To do what with? AFAIK, ddrescue uses the block device layer for reading. ----------------------------------------------------------------------- [tangent warning] > I was recently at the doctor's and musing how we'd all be > dead if medicine ran anything like software development. Doctors can order a > blood test and, on one sheet of paper, see what my organs are up to. Medics are more like software developping AI. They can't build a decent organism but are very affirmative when talking about a poorly running one. > It's > too bad we can't do that with software. Instead, we seem to have logs that > provide too much noise or not enough signal. You need an expert to read the blood test results and you need an expert to interpret system logs or SCSI command transaction logs. That's not much different. In the end there sometimes remain unresolved questions. > But, I'll leave someone with more technical expertise to suggest how we fix > software logging. I see two big problems: - Development of a logging scheme that serves all thinkable purposes and situations. - Convincing the kernel or systemd community that it is the right thing to do. Have a nice day :) Thomas
