On Sat, 1 Feb 2020 09:24:25 +0100 Michael Biebl wrote:
> Any luck in narrowing down the problem?
>
> When exactly does the problem happen? Only during boot?
> If so, a verbose debug log would be helpful [1]
>
> Or does it happen after boot as well? Is it related to some other events?
>
>
>
On Sat, 25 Jan 2020 16:59:54 +0100 Michael Biebl wrote:
> On Mon, 13 Jan 2020 15:10:46 +0100 Michael Biebl wrote:
> > Am 13.01.20 um 14:57 schrieb pior...@gmail.com:
> >
> > > None of them returned any error in dmesg so far.
> >
> >
> > You can also check the following invocations from
> >
On Mon, 13 Jan 2020 15:10:46 +0100 Michael Biebl wrote:
> Am 13.01.20 um 14:57 schrieb pior...@gmail.com:
>
> > None of them returned any error in dmesg so far.
>
>
> You can also check the following invocations from
> 60-persistent-storage.rules:
>
> > # ATA
> > KERNEL=="sd*[!0-9]|sr*",
Results:
# blkid --noraid
blkid: unrecognized option '--noraid'
Try 'blkid --help' for more information.
>From the list you provided I could only decipher two commands:
/lib/udev/ata_id --export /dev/sr0
/lib/udev/scsi_id --export --whitelisted -d /dev/sr0
None of them returns any dmesg
Am 13.01.20 um 14:57 schrieb pior...@gmail.com:
> None of them returned any error in dmesg so far.
You can also check the following invocations from
60-persistent-storage.rules:
> # ATA
> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi",
> ATTRS{vendor}=="ATA",
Thank you.
I have following in rules.d/60:
$ grep -E "scsi_id|cdrom_id" /lib/udev/rules.d/60-*
/lib/udev/rules.d/60-cdrom_id.rules:ENV{DISK_EJECT_REQUEST}=="?*",
RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"
/lib/udev/rules.d/60-cdrom_id.rules:IMPORT{program}="cdrom_id
--lock-media
Am 12.01.20 um 15:49 schrieb Michael Biebl:
> Am 12.01.20 um 15:12 schrieb pior...@gmail.com:
>> On 12/01/2020 13:54, Michael Biebl wrote:
>>
As far as udev is concerned, I can only think of the following
possible places:
> $ grep -E "scsi_id|cdrom_id" /lib/udev/rules.d/60-*
Am 12.01.20 um 15:12 schrieb pior...@gmail.com:
> On 12/01/2020 13:54, Michael Biebl wrote:
>
>>> As far as udev is concerned, I can only think of the following
>>> possible places:
>>>
$ grep -E "scsi_id|cdrom_id" /lib/udev/rules.d/60-*
On 12/01/2020 13:54, Michael Biebl wrote:
>> As far as udev is concerned, I can only think of the following
>> possible places:
>>
>>> $ grep -E "scsi_id|cdrom_id" /lib/udev/rules.d/60-*
>>> /lib/udev/rules.d/60-cdrom_id.rules:ENV{DISK_EJECT_REQUEST}=="?*",
>>> RUN+="cdrom_id --eject-media
Am 07.01.20 um 20:59 schrieb Michael Biebl:
> Am 07.01.20 um 19:56 schrieb pior...@gmail.com:
>>
>>>
>>> Can you elaborate why you think this is a bug in udev?
>>> Those are kernel messsage, likely a result of a bad optical media or a
>>> bad cable.
>>
>> Thanks for your reply.
>> I don't know if
Am 07.01.20 um 19:56 schrieb pior...@gmail.com:
>
>>
>> Can you elaborate why you think this is a bug in udev?
>> Those are kernel messsage, likely a result of a bad optical media or a
>> bad cable.
>
> Thanks for your reply.
> I don't know if this is error in udev or not. I searched and similar
Control: tags -1 + moreinfo
Am 07.01.2020 um 18:53 schrieb pior...@gmail.com:
> Errors in dmesg:
>
> [ 3454.212972] sr 1:0:0:0: [sr0] tag#7 FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 3454.212975] sr 1:0:0:0: [sr0] tag#7 Sense Key : Not Ready [current]
> [ 3454.212977] sr
Errors in dmesg:
[ 3454.212972] sr 1:0:0:0: [sr0] tag#7 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 3454.212975] sr 1:0:0:0: [sr0] tag#7 Sense Key : Not Ready [current]
[ 3454.212977] sr 1:0:0:0: [sr0] tag#7 Add. Sense: Medium not present -
tray closed
[ 3454.212980] sr 1:0:0:0:
13 matches
Mail list logo
