Applications like k3b and Kaudiocreator do not show the details correctly. Additionally, if I tried to change the mount point of the drives (they
are both /media/cdrom) - the settings you can change via MCC, they are
never remembered. so despite making a directory /media/sr0 and
/media/sr1, they are not remembered, and keep defaulting to /media/cdrom
Any suggestions where to look to sort this mess out, I don't want to add entries into fstab when they've never been there before.
Mageia 7 x86_64 with latest updates installed, using KDE.
I have a DVD-ROM and BluRay writer in the system, they are not set up in fstab (never have been). Some recent update has screwed up the drive allocations, so that:
/dev/sr0 has the device details of sr1
and
/dev/sr1 has the device details of sr0
Obviously that doesn't work properly when you want to say rip a CD
because it thinks it's in the correct drive, but it isn't, and throws en error that the path doesn't exist (which it doesn't).
Opening Dolphin (the file manager), it correctly shows the /dev/srx and correct device details.
Applications like k3b and Kaudiocreator do not show the details correctly.
Additionally, if I tried to change the mount point of the drives (they
are both /media/cdrom) - the settings you can change via MCC, they are
never remembered. so despite making a directory /media/sr0 and
/media/sr1, they are not remembered, and keep defaulting to /media/cdrom
Any suggestions where to look to sort this mess out, I don't want to add entries into fstab when they've never been there before.
Mageia 7 x86_64 with latest updates installed, using KDE.
I have a DVD-ROM and BluRay writer in the system, they are not set up in fstab (never have been). Some recent update has screwed up the drive allocations, so that:
/dev/sr0 has the device details of sr1
and
/dev/sr1 has the device details of sr0
Obviously that doesn't work properly when you want to say rip a CD
because it thinks it's in the correct drive, but it isn't, and throws en error that the path doesn't exist (which it doesn't).
Opening Dolphin (the file manager), it correctly shows the /dev/srx and correct device details.
Applications like k3b and Kaudiocreator do not show the details correctly.
Additionally, if I tried to change the mount point of the drives (they
are both /media/cdrom) - the settings you can change via MCC, they are
never remembered. so despite making a directory /media/sr0 and
/media/sr1, they are not remembered, and keep defaulting to /media/cdrom
Any suggestions where to look to sort this mess out, I don't want to add entries into fstab when they've never been there before.
Mageia 7 x86_64 with latest updates installed, using KDE.
I have a DVD-ROM and BluRay writer in the system, they are not set up in fstab (never have been). Some recent update has screwed up the drive allocations, so that:
On Tue, 10 Mar 2020 12:24:18 +0000, Ar wrote:
Mageia 7 x86_64 with latest updates installed, using KDE.
I have a DVD-ROM and BluRay writer in the system, they are not set up in
fstab (never have been). Some recent update has screwed up the drive
allocations, so that:
/dev/sr0 has the device details of sr1
and
/dev/sr1 has the device details of sr0
Obviously that doesn't work properly when you want to say rip a CD
because it thinks it's in the correct drive, but it isn't, and throws en
error that the path doesn't exist (which it doesn't).
Opening Dolphin (the file manager), it correctly shows the /dev/srx and
correct device details.
Applications like k3b and Kaudiocreator do not show the details correctly. >>
Additionally, if I tried to change the mount point of the drives (they
are both /media/cdrom) - the settings you can change via MCC, they are
never remembered. so despite making a directory /media/sr0 and
/media/sr1, they are not remembered, and keep defaulting to /media/cdrom
Any suggestions where to look to sort this mess out, I don't want to add
entries into fstab when they've never been there before.
First think I would check is the persistent-cd.rules file.
locate persistent-cd
On 2020-03-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
First think I would check is the persistent-cd.rules file.=20
locate persistent-cd =20
I have no such file anywhere.
Where is it supposed to be?
On 2020-03-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 10 Mar 2020 12:24:18 +0000, Ar wrote:
Mageia 7 x86_64 with latest updates installed, using KDE.
I have a DVD-ROM and BluRay writer in the system, they are not set up in >>> fstab (never have been). Some recent update has screwed up the drive
allocations, so that:
/dev/sr0 has the device details of sr1
and
/dev/sr1 has the device details of sr0
Obviously that doesn't work properly when you want to say rip a CD
because it thinks it's in the correct drive, but it isn't, and throws en >>> error that the path doesn't exist (which it doesn't).
Opening Dolphin (the file manager), it correctly shows the /dev/srx and
correct device details.
Applications like k3b and Kaudiocreator do not show the details correctly. >>>
Additionally, if I tried to change the mount point of the drives (they
are both /media/cdrom) - the settings you can change via MCC, they are
never remembered. so despite making a directory /media/sr0 and
/media/sr1, they are not remembered, and keep defaulting to /media/cdrom >>>
Any suggestions where to look to sort this mess out, I don't want to add >>> entries into fstab when they've never been there before.
First think I would check is the persistent-cd.rules file.
locate persistent-cd
I have no such file anywhere.
Where is it supposed to be?
Try creating a new user, add the groups cdrom and cd-writer to that new user,
log out and back in as the new user and see if it has the same problem.
Shouldn't be needed to add the groups to the user, but can't hurt.
If that user does not have the same problem, then it's some kde setting. If it does, then checking elsewhere will be needed.
On 10/03/2020 13:45, David W. Hodgins wrote:
Try creating a new user, add the groups cdrom and cd-writer to that new
user,
log out and back in as the new user and see if it has the same problem.
Shouldn't be needed to add the groups to the user, but can't hurt.
If that user does not have the same problem, then it's some kde setting. If >> it does, then checking elsewhere will be needed.
Still testing various suggestions, but I just logged in to my test user
first opportunity I have been able to, and I get the same messed up DVD/BluRay ID behaviour, and that account is only used for checking bugs
that arise in my working account. So it's a KDE problem.
On 10/03/2020 13:45, David W. Hodgins wrote:
Try creating a new user, add the groups cdrom and cd-writer to that new
user,
log out and back in as the new user and see if it has the same problem.
Shouldn't be needed to add the groups to the user, but can't hurt.
If that user does not have the same problem, then it's some kde setting. If >> it does, then checking elsewhere will be needed.
Still testing various suggestions, but I just logged in to my test user first opportunity I have been able to, and I get the same messed up DVD/BluRay ID behaviour, and that account is only used for checking bugs that arise in my working account. So it's a KDE problem.
On Thu, 12 Mar 2020 09:07:45 +0000, Ar wrote:
On 10/03/2020 13:45, David W. Hodgins wrote:
Try creating a new user, add the groups cdrom and cd-writer to that new
user,
log out and back in as the new user and see if it has the same problem.
Shouldn't be needed to add the groups to the user, but can't hurt.
If that user does not have the same problem, then it's some kde setting. If
it does, then checking elsewhere will be needed.
Still testing various suggestions, but I just logged in to my test user
first opportunity I have been able to, and I get the same messed up
DVD/BluRay ID behaviour, and that account is only used for checking bugs
that arise in my working account. So it's a KDE problem.
If /dev/whatever is not correct, I suggest it is not a Desktop Environment problem but a udev result which you might fix by swapping drive cables between drives, or make a udev rule to dictate which is which.
On 10/03/2020 13:45, David W. Hodgins wrote:
Try creating a new user, add the groups cdrom and cd-writer to that new
user,
log out and back in as the new user and see if it has the same problem.
Shouldn't be needed to add the groups to the user, but can't hurt.
If that user does not have the same problem, then it's some kde setting. If >> it does, then checking elsewhere will be needed.
Still testing various suggestions, but I just logged in to my test user
first opportunity I have been able to, and I get the same messed up DVD/BluRay ID behaviour, and that account is only used for checking bugs
that arise in my working account. So it's a KDE problem.
The rules are no longer in /etc/udev, but in /usr/lib/udev/rules.d
Maybe 60-cdrom_id.rules?
On Thu, 12 Mar 2020 16:02:52 -0000 (UTC), William Unruh wrote:
The rules are no longer in /etc/udev, but in /usr/lib/udev/rules.d
Maybe 60-cdrom_id.rules?
To any lurkers and OP, I suggest that you do not modify system supplied
files whenever possible.
Next update/release might wipe out your changes.
For example I would try copying 60-cdrom_id.rules to
62-cdrom_id.rules and change 62-cdrom_id.rules.
On Thu, 12 Mar 2020 16:02:52 -0000 (UTC), William Unruh wrote:
The rules are no longer in /etc/udev, but in /usr/lib/udev/rules.d
Maybe 60-cdrom_id.rules?
To any lurkers and OP, I suggest that you do not modify system supplied
files whenever possible.
Next update/release might wipe out your changes.
For example I would try copying 60-cdrom_id.rules to
62-cdrom_id.rules and change 62-cdrom_id.rules.
If that does not work, I would copy 60-cdrom_id.rules to
59-cdrom_id.rules make the changes and use the disallow change by
other rules with := operator
I still maintain swapping cables with each device would be preferable
to having to maintain custom rules unless you have a method to always
install your changes.
On Thu, 12 Mar 2020 05:07:45 -0400, Ar <Ar@127.0.0.1> wrote:file)
On 10/03/2020 13:45, David W. Hodgins wrote:
Try creating a new user, add the groups cdrom and cd-writer to that new
user,
log out and back in as the new user and see if it has the same problem.
Shouldn't be needed to add the groups to the user, but can't hurt.
If that user does not have the same problem, then it's some kde setting. If
it does, then checking elsewhere will be needed.
Still testing various suggestions, but I just logged in to my test user
first opportunity I have been able to, and I get the same messed up
DVD/BluRay ID behaviour, and that account is only used for checking bugs
that arise in my working account. So it's a KDE problem.
As I posted before, if it affects the test account, it's not a kde (config
problem, but rather a system wide udev problem.been
From the above, I gather the test user is not a new one, but one that has
used before, so it doesn't prove where the problem is.
Please delete and recreate the test user, or create a brand new one and see if it still has the problem.
If it does, then it's udev. It should be handled by /usr/lib/udev/rules.d/60-persistent-storage.rules
but for some reason that is not working.
If we do need to set up a custom udev rule to fix it, the output of (asroot)
"udevadm info -p /sys/block/sr?" will be needed, so a rule that fixes itproperly
can be written, preferably in a text file attached to a bug report.
Regards, Dave Hodgins
On Thu, 12 Mar 2020 11:47:43 -0500, Bit Twister wrote:
On Thu, 12 Mar 2020 16:02:52 -0000 (UTC), William Unruh wrote:
The rules are no longer in /etc/udev, but in /usr/lib/udev/rules.d
Maybe 60-cdrom_id.rules?
To any lurkers and OP, I suggest that you do not modify system supplied
files whenever possible.
Next update/release might wipe out your changes.
For example I would try copying 60-cdrom_id.rules to
62-cdrom_id.rules and change 62-cdrom_id.rules.
Ah so, after reading man udev, it looks like you can copy /usr/lib/udev/rules.d/60-cdrom_id.rules to /etc/udev/rules.d,
make your changes to /etc/udev/rules.d/60-cdrom_id.rules and udev will
not use /usr/lib/udev/rules.d/60-cdrom_id.rules on future boots.
No idea if kernel initrd has to be rebuilt.
I still maintain swapping cables with each device would be preferable
to having to maintain custom rules unless you have a method to always
install your changes.
On 3/12/20 12:47 PM, Bit Twister wrote:
I still maintain swapping cables with each device would be preferable
to having to maintain custom rules unless you have a method to always
install your changes.
I'm with you, Bit. At my level of expertise, I'd try swapping cables
first, and if that didn't work I'd learn how to live with the result, if possible, before modifying rules that I don't understand.
But that's just me. I have no idea how difficult it might be for the OP
to simply learn how to live with the situation.
Like others who have responded, I don't have any systems with more that
one optical drive anymore. My latest hardware build doesn't even have
one, and I ripped one out of my main laptop to replace it with a second
hard drive.
I just don't use optical media anymore, and I don't miss it, even a
little bit.
TJ
The problem probably is not with the current situation. As you say he
can learn to live with it (just swap sr0 and sr1 everywhere they occur). However, then two weeks from now, it will mysteriously switch back. And
then on each reboot it will randomly choose the order etc. That is of
course the worst case situation.
I know that Mageia renumbers the wireless, from wlan0 to, in my case
wlp58s0. That could well offer a clue as to how one can do one's own renumbring for sr
On Fri, 13 Mar 2020 15:12:21 -0000 (UTC), William Unruh wrote:
The problem probably is not with the current situation. As you say he
can learn to live with it (just swap sr0 and sr1 everywhere they occur).
However, then two weeks from now, it will mysteriously switch back. And
then on each reboot it will randomly choose the order etc. That is of
course the worst case situation.
Offhand, I would guess that would not be the case if the device rule
is using the hardware buss address to set device name which is what I perceive in the cdrom rules.
I know that Mageia renumbers the wireless, from wlan0 to, in my case
wlp58s0. That could well offer a clue as to how one can do one's own
renumbring for sr
I suggest that is a different horse race all together. As I misunderstand
it, the network algorithm is naming network devices on a first come first named basis when the device indicates it is ready to work.
On 2020-03-13, Bit Twister <BitTwister@mouse-potato.com> wrote:I would think that the particular machine's BIOS/UEFI firmware could be
On Fri, 13 Mar 2020 15:12:21 -0000 (UTC), William Unruh wrote:
The problem probably is not with the current situation. As you say he
can learn to live with it (just swap sr0 and sr1 everywhere they occur). >>> However, then two weeks from now, it will mysteriously switch back. And
then on each reboot it will randomly choose the order etc. That is of
course the worst case situation.
Offhand, I would guess that would not be the case if the device rule
is using the hardware buss address to set device name which is what I
perceive in the cdrom rules.
I know that Mageia renumbers the wireless, from wlan0 to, in my case
wlp58s0. That could well offer a clue as to how one can do one's own
renumbring for sr
I suggest that is a different horse race all together. As I misunderstand
it, the network algorithm is naming network devices on a first come first
named basis when the device indicates it is ready to work.
WEll I know I have had trouble with /dev/hd? naming and the system would alter its naming of the hard drives depending on the random "first
found". That was why most switched to UUID finding of drives and
partitions. It would not surprize me that optical drives have the same problem.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 82:24:34 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,096 |
Messages: | 5,276,781 |