• Screwed up DVD mount points

    From Ar@2:250/0 to All on Tue Mar 10 12:24:18 2020
    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.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: - (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Tue Mar 10 13:45:47 2020
    On Tue, 10 Mar 2020 08:24:18 -0400, Ar <Ar@127.0.0.1> wrote:
    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.

    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.

    Please report back on the test results. This is not a problem I've heard of before. I don't have any optical devices on my current system, let alone two
    of them, so can't test any of that here.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Tue Mar 10 17:38:50 2020
    On 2020-03-10, Ar <Ar@127.0.0.1> 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

    The /dev/{sd,sr}* labeling has always been unstable which is why the
    standard went to UUID as a way of identifying the devices/partitions. I
    think it has to do with exactly which device the system came across
    first during the boot process, and that could depend on many things.
    For optical drives without anything in them, I do not know if there is a
    way of identifying them and getting them to have the right names.
    I was also one of the reasons why udev was created (and is not longer maintained since I think the writer disappeared). The weird modern
    naming of sata disks (eg nmp6s45) also arose as this I believe, names
    the disks from exactly where on the bus they are located ( and if you
    move the drives to a different place, that could change).
    Unfortunately I do not know what one can do for cd/dvd/etc devices to
    identify them if they are empty.



    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.

    What is
    ls -l /dev/cdrom?
    or ls -l /dev/cdrom*

    I have only one optical device on any of my machines so cannot test what
    to do with 2.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Bit Twister@2:250/0 to All on Tue Mar 10 19:07:28 2020
    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



    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From faeychild@2:250/0 to All on Tue Mar 10 21:42:02 2020
    On 10/3/20 11:24 pm, 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:

    probably similar was my lack of access to USB devices after an update.

    I had to re-chown all my sticks. Which caused me to wonder if FAT32
    formatted devices had chown properties anyway.
    I wasn't going there though and chown fixed the problem


    --
    faeychild
    Running plasmashell 5.15.4 on 5.5.6-desktop-2.mga7 kernel.
    Mageia release 7 (Official) for x86_64 installed via Mageia-7-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Wed Mar 11 03:02:55 2020
    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?

    And

    root:> urpmf persistent-cd lib64freehdl-devel:/usr/include/freehdl/kernel-persistent-cdfg-dump.hh

    http://mirror.math.princeton.edu/pub/mageia/distrib/7/x86_64/media/core/updates /media_info/20200310-185150-files.xml.lzma

    http://mirror.math.princeton.edu/pub/mageia/distrib/7/x86_64/media/nonfree/upda tes/media_info/20200306-205557-files.xml.lzma

    http://mirror.math.princeton.edu/pub/mageia/distrib/7/x86_64/media/tainted/upda tes/media_info/20200310-184221-files.xml.lzma libfreehdl-devel:/usr/include/freehdl/kernel-persistent-cdfg-dump.hh

    http://mirror.math.princeton.edu/pub/mageia/distrib/7/i586/media/core/updates/m edia_info/20200310-184709-files.xml.lzma

    http://mirror.math.princeton.edu/pub/mageia/distrib/7/i586/media/nonfree/update s/media_info/20200306-205554-files.xml.lzma

    http://mirror.math.princeton.edu/pub/mageia/distrib/7/i586/media/tainted/update s/media_info/20200310-184219-files.xml.lzma
    no xml-info available for medium "google-chrome"

    So it does not seem to be in any package either.



    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Aragorn@2:250/0 to All on Wed Mar 11 03:22:31 2020
    On 11.03.2020 at 03:02, William Unruh scribbled:

    On 2020-03-10, Bit Twister <BitTwister@mouse-potato.com> wrote:

    First think I would check is the persistent-cd.rules file.
    locate persistent-cd =20
    =20
    I have no such file anywhere.
    Where is it supposed to be?

    I presume he means under /etc/udev/rules.d, or whatever Mageia's
    equivalent of that may be [*] =E2=80=94 I run Manjaro, and on my system that directory is empty.



    [*] Maybe /etc/udev.d/rules.d?

    --=20
    With respect,
    =3D Aragorn =3D


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (2:250/0@fidonet)
  • From Bit Twister@2:250/0 to All on Wed Mar 11 04:10:33 2020
    On Wed, 11 Mar 2020 03:02:55 -0000 (UTC), William Unruh wrote:
    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?

    Frap, Sorry my fault. I should have checked my new_install script a
    little bit closer.

    That file did exist in older releases but became obsolete with newer
    releases of udev.

    As I see it, the OP either tries swapping cables on the devices or
    can write a /etc/udev/rules.d/user_fn_here udev rule to set the desired definitions.
    Quick google search result https://askubuntu.com/questions/126764/how-can-i-properly-create-dev-dvd


    Example saved rule from an old release on an old system with two devices

    $ cat /var/local/config/*persistent-cd.rules
    # This file was automatically generated by the /lib/udev/write_cd_rules
    # program, run by the cd-aliases-generator.rules rules file.
    #
    # You can modify it, as long as you keep each rule on a single
    # line, and set the $GENERATED variable.

    # DVD+-RAM_530L_v1 (pci-0000:00:14.1-scsi-1:0:0:0)
    SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
    SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
    SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
    SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-1:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

    # DVD-E616A (pci-0000:00:14.1-scsi-1:0:1:0)
    SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-1:0:1:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
    SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-1:0:1:0", SYMLINK+="dvd1", ENV{GENERATED}="1"



    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Ar@2:250/0 to All on Thu Mar 12 09:07:45 2020
    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.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: - (2:250/0@fidonet)
  • From Bit Twister@2:250/0 to All on Thu Mar 12 13:35:27 2020
    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.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Thu Mar 12 15:46:40 2020
    On 2020-03-12, Ar <Ar@127.0.0.1> 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.

    No, if I am right it is not a kde problem. It is Linux kernel problem.
    The naming of drives occurs very early in the Linux boot process and is strongly dependent on the timing. The first one the kernel comes across
    in searching through what is attached to the system is labeled sr0. That
    "first one" can depend on exactly what is going on in the boot system,
    minor changes to the what is connected to the bus, etc.
    udev, which seems to have disappeared, was an attempt to answer that
    problem. UUIDs or labels is an answer for hard disks. Unfortunately
    dvd/blurays etc have no content when the kernel is trying to name them.
    You could try delving into the arcana of udev to see if there is
    something there that you can use to force the system to give the right
    labels. Or write something so that you have make the links /dev/dvd and /dev/bluray point to the right /dev/sr? no matter what label the
    computer might have given them.

    Or write a little script yourself to run in /etc/rc.d/rc.local to search through the output to dmesg for the naming of the attached devices.
    (search for sr in the output to dmesg and see what it is saying)


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Thu Mar 12 16:02:52 2020
    On 2020-03-12, Bit Twister <BitTwister@mouse-potato.com> wrote:
    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.

    The problem is that, I think, udev is deprecated these days-- didn't the developer disappear

    The rules are no longer in /etc/udev, but in /usr/lib/udev/rules.d
    Maybe 60-cdrom_id.rules?
    I think your own private rules still go into /etc/udev.



    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Thu Mar 12 16:22:59 2020
    On Thu, 12 Mar 2020 05:07:45 -0400, Ar <Ar@127.0.0.1> 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.

    As I posted before, if it affects the test account, it's not a kde (config file)
    problem, but rather a system wide udev problem.

    From the above, I gather the test user is not a new one, but one that has been
    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 (as root) "udevadm info -p /sys/block/sr?" will be needed, so a rule that fixes it properly
    can be written, preferably in a text file attached to a bug report.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Bit Twister@2:250/0 to All on Thu Mar 12 16:47:43 2020
    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.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Bit Twister@2:250/0 to All on Thu Mar 12 17:02:53 2020
    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.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Thu Mar 12 18:46:46 2020
    On 2020-03-12, Bit Twister <BitTwister@mouse-potato.com> 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.

    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.

    I think that the correct process is to put the local changes into /etc/udev/rules.d

    man udev says

    The udev rules are read from the files located in the system rules directory
    /usr/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local
    administration directory /etc/udev/rules.d. All rules files are collectively sorted
    and processed in lexical order, regardless of the directories in which they live.
    However, files with identical filenames replace each other. Files in /etc have the
    highest priority, files in /run take precedence over files with the same name in
    /usr/lib.


    And yes, I agree that altering the files in /usr/lib/udev/rules.d is
    dangerous as they will be replaced when next you install an update for
    udev, or rather of some program which dumps those files into that
    directory (ion my system there are about 34 different packages that do so.)
    So I agree entirely with your advice to not alter the files in /usr/lib/udev/rules.d


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Thu Mar 12 18:54:43 2020
    On 2020-03-12, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Thu, 12 Mar 2020 05:07:45 -0400, Ar <Ar@127.0.0.1> 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.

    As I posted before, if it affects the test account, it's not a kde (config
    file)
    problem, but rather a system wide udev problem.

    From the above, I gather the test user is not a new one, but one that has
    been
    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.

    It seems to me that that file assumes that the kernel has already
    allocated a /dev/sr? label to the device. It would seem to be somewhere
    earlier in the boot process that the kernel allocates the names.

    I have no idea where the links /dev/cdrom, /dev/dvd,... are allocated so
    that might be where you would want to make changes.


    If we do need to set up a custom udev rule to fix it, the output of (as
    root)
    "udevadm info -p /sys/block/sr?" will be needed, so a rule that fixes it
    properly
    can be written, preferably in a text file attached to a bug report.

    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From David W. Hodgins@2:250/0 to All on Fri Mar 13 05:04:36 2020
    On Thu, 12 Mar 2020 13:02:53 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:

    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 didn't, and would not have suggested editing the /usr file. Custom rules
    do belong in /etc. Yes, the initrd has to be rebuilt, and will automatically include any rules from /etc.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From TJ@2:250/0 to All on Fri Mar 13 13:05:02 2020
    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

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Fri Mar 13 15:12:21 2020
    On 2020-03-13, TJ <TJ@noneofyour.business> wrote:
    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.

    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

    In dmesg,
    ath10k_pci 0000:3a:00.0 wlp58s0: renamed fom wlan0
    now, where and how this is done I do not know.

    Mint apparently has a file /etc/udev/rules.d/70-persistent-net.rules
    in which they do the renaming apparently. Or you could set up a script
    to use ip to rename the interfaces on each boot, although you would have
    to figure out which is which each time you boot.



    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

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From Bit Twister@2:250/0 to All on Fri Mar 13 18:27:21 2020
    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.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From William Unruh@2:250/0 to All on Sat Mar 14 04:49:10 2020
    On 2020-03-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
    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.


    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)
  • From TJ@2:250/0 to All on Sat Mar 14 12:19:13 2020
    On 3/14/20 12:49 AM, William Unruh wrote:
    On 2020-03-13, Bit Twister <BitTwister@mouse-potato.com> wrote:
    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.

    I would think that the particular machine's BIOS/UEFI firmware could be
    a factor, too. No experience with UEFI, but I know that over the years
    some BIOSs would have the option of setting which hard drive and/or
    optical drive would take precedence in the boot order, while others
    would not.

    It doesn't take much speculation to think that setting could affect the
    order in which Mageia "finds" a particular drive during the boot process.

    TJ

    --- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/0@fidonet)