KDE/LXDE/XFCE think DVD/CD is an internal hard disc!

[jaywalker]

I have just fitted a DVD/CD read/write drive to a testbed PC (attached as /dev/hdc via an IT8212 RAID card in normal IDE mode) and the installed window managers/graphical desktops see it as an internal hard disc needing root privilege to mount.

How do I tell the system it is an optical drive? Any ideas?

Richard

Thought it might help if I add this from dmesg:

Code: Select all

[richard@DarkNight Videos]$ dmesg | grep hdc
[    2.156372] hdc: PHILIPS PBDV1640P, ATAPI CD/DVD-ROM drive
[    2.768066] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[    2.768528] hdc: UDMA/33 mode selected
[   12.496387] ide-cd: hdc: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache


[ghmitch]

It might be helpful to see your /etc/fstab config file if you could post that. - George

[jaywalker]

I'm afraid its devoid of anything interesting - just the original mount point definitions for hda and hdb. I suppose it was written by the "system" at some point in the past. I have just updated the comments to reflect the actual drive names rather than the sd* ones determined during the somewhat convoluted install process.

The DVD/CDROM drive is a late addition, just yesterday afternoon in fact.

Nevertheless, here it is:

Code: Select all

[richard@DarkNight ~]$ cat /etc/fstab
# Entry for /dev/hda1 :
UUID=441c5487-4f7c-47b6-a483-6beb9ac76225 / ext4 acl,relatime 1 1
# Entry for /dev/hda6 :
UUID=845431b5-730e-4e36-97c3-af2925881b38 /home ext4 acl,relatime 1 2
# Entry for /dev/hdb1 :
UUID=3f260b57-df5d-4e57-9611-d702e3b89676 /home/games ext4 defaults 1 2
none /proc proc defaults 0 0
# Entry for /dev/hda5 :
UUID=80e68030-b226-4a0e-acd6-4788d6b553ef /usr ext4 acl,relatime 1 2


[ghmitch]

Jay, Here is my /etc/fstab on a system where the optical drive is working normally.

[ghmitch@localhost ~]

$ cat /etc/fstab

# Entry for /dev/sdc1 :
UUID=2ead7897-2203-4846-9fef-22aac314634d / btrfs relatime 1 1
LABEL=HOME32 /home ext4 acl,relatime 1 2
LABEL=REAL_HOME /common ext4 acl,relatime 1 2
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
none /proc proc defaults 0 0
none /tmp tmpfs defaults 0 0

1) ALL ATA/SATA hard drives are now treated as SCSI drives from the kernel down and thus the officially sanctioned designation is "sd" rather than "hd". It went back and forth a number of years ago but I believe most distros have settled on the "sd" designation. If you look in your /dev directory you will see that is what is used on the actual device names. So you can modify the comment however you like but /dev/sdX is actually the correct usage with Mageia.

2) By not having a CDROM entry in fstab, you are leaving it to the booting kernel to try to guess what kind of drive it is dealing with. Try adding the CDROM line you see above to your fstab and see if that helps.

Good luck!

George

[jaywalker]

[ghmitch@localhost ~]

[...]
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
[...]

That is pretty much identical to the one I had in my MGA2 fstab, before I had to comment it out... something to do with HAL and UDEV and stuff not letting me access the drive in LXDE. The BIG difference between that and this is that I have no /dev/cdrom on this MGA3 PC, so I am somewhat at a loss as to what to do about it.

1) ALL ATA/SATA hard drives are now treated as SCSI drives from the kernel down and thus the officially sanctioned designation is "sd" rather than "hd". It went back and forth a number of years ago but I believe most distros have settled on the "sd" designation. If you look in your /dev directory you will see that is what is used on the actual device names. So you can modify the comment however you like but /dev/sdX is actually the correct usage with Mageia.

That was what I was expecting to find in /dev, but there is something screwy about this installation (3rd or maybe 4th try) and all of the others before it; there seems to be something missing, some module isn't loaded or some configuration step is missed, which results in all devices attached to the IT8212 RAID card being identified as /dev/hd?*. I have tried adding

Code: Select all

hdc=ide-scsi

to the boot command but to no obvious effect - clearly not what is needed.

2) By not having a CDROM entry in fstab, you are leaving it to the booting kernel to try to guess what kind of drive it is dealing with. Try adding the CDROM line you see above to your fstab and see if that helps.

I'll try making a /dev/cdrom entry in fstab and see if that provokes osmething other than "device not found", but I have a strange fancy that I might find something of interest in the udev rules which I believe are invoked before any reference to fstab..... who knows, but I reckon it is worth at least a good look.

Richard

[ghmitch]

Richard, If you do NOT have an existing /dev/cdrom entry, the fstab line is not going to do the job. Can you check if you have /dev/sr0?:

Code: Select all


[root@localhost ghmitch]# ls -l /dev/cdrom
lrwxrwxrwx 1 root root 3 Mar 31 19:56 /dev/cdrom -> sr0
[root@localhost ghmitch]# ls -l /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Mar 31 19:56 /dev/sr0



If you do not, I *believe* udev should be creating it. If you do, then apparentlly something is not creating the symlink to /dev/sr0.

Hopefully at some point a light will go on among some onlooker as we try to track this down.

- George

[doktor5000]

Guys, please lets keep this structured.

For one, there should be no fstab entries for cd/dvd drives, as that only gets you into problem with automatic mounting of the various desktop environments.
fstab entries for cd/dvd drives are obsolete and should be removed.

For two, the detection of the drive is done via udev, it creates the device nodes below /dev.
Check /etc/udev/rules.d/70-persistent-cd.rules or please post the contents here.
You may need to rename/delete that file to get udev to cleanly rewrite it and redetect current hardware on next boot.
(You get the same problem if you clone a machine, or exchange the harddrive into another machine - the network
interfaces will be recreated, as the MAC adress changed in between - also done by udev)

If you got that, we can continue.

[jaywalker]

Code: Select all

[richard@DarkNight ~]$ cat /etc/udev/rules.d/70-persistent-cd.rules
cat: /etc/udev/rules.d/70-persistent-cd.rules: No such file or directory


There's the first clue I think, George. Thank you Dok for once again cutting through all of the undergrowth for a clear look at the trees :~)

I did a bit more searching for 70-persistent-cd.rules and found it nowhere in the MGA3 packages. It looks like it might be expected to be in the systemd rpm -

Currently installed version: 195-16.mga3

along with

Code: Select all

[root@DarkNight udev]# locate udev/rules | grep persistent
/usr/lib/udev/rules.d/60-persistent-alsa.rules
/usr/lib/udev/rules.d/60-persistent-input.rules
/usr/lib/udev/rules.d/60-persistent-serial.rules
/usr/lib/udev/rules.d/60-persistent-storage-tape.rules
/usr/lib/udev/rules.d/60-persistent-storage.rules
/usr/lib/udev/rules.d/60-persistent-v4l.rules
/usr/lib/udev/rules.d/75-persistent-net-generator.rules


However I did find this which looks significant:

Code: Select all

[root@DarkNight udev]# cat /usr/lib/udev/rules.d/60-cdrom_id.rules
# do not edit this file, it will be overwritten on update

ACTION=="remove", GOTO="cdrom_end"
SUBSYSTEM!="block", GOTO="cdrom_end"
KERNEL!="sr[0-9]*|xvd*", GOTO="cdrom_end"
ENV{DEVTYPE}!="disk", GOTO="cdrom_end"

# unconditionally tag device as CDROM
KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"

# media eject button pressed
ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end"

# import device and media properties and lock tray to
# enable the receiving of media eject button events
IMPORT{program}="cdrom_id --lock-media $devnode"

KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"

LABEL="cdrom_end"


If that is the only route to a normally functioning CDROM drive then I can see why it didn't work. This box has no drives of any type called anything other than /dev/hd*. It wouldn't even have those were it not for the add-in card occupying the sole PCI slot on the motherboard:

Code: Select all

Identification
Vendor: ‎Integrated Technology Express, Inc.

Description: ‎IT8212 Dual channel ATA RAID controller

Media class: ‎Mass storage controller


I tell a lie, from time to time I may have external USB storage attached. The first such device will be /dev/sda. I don't know if it helps any, but here is my /etc/modprobe.conf showing the storage device modules selected during install:

Code: Select all

[richard@DarkNight home]$ cat /etc/modprobe.conf
install scsi_hostadapter /sbin/modprobe it821x; /sbin/modprobe ahci; /sbin/modprobe ata_piix; /bin/true
install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ehci_pci; /sbin/modprobe ohci_hcd; /sbin/modprobe xhci_hcd; /bin/true
install ide-controller /sbin/modprobe it821x; /bin/true
alias eth0 r8169


So I reckon it is a matter of discovering which module or script is responsible for identifying and tagging the CDROM device and then finding out why it didn't load/work as expected..... Should we call a time-out here and formulate this problem for bugzilla?

Richard

PS: Just for completeness, here is what mount says:

Code: Select all

[richard@DarkNight home]$ mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=3774816k,nr_inodes=943704,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/hda1 on / type ext4 (rw,relatime,data=ordered)
/dev/hda6 on /usr type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
/dev/hda8 on /home type ext4 (rw,relatime,data=ordered)
/dev/hdb1 on /home/games type ext4 (rw,relatime,data=ordered)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)


[ghmitch]

My bluray is working fine here and my /dev/scanner IS being created, but -

Code: Select all


[root@localhost ghmitch]# cat /etc/udev/rules.d/70-persistent-cd.rules
cat: /etc/udev/rules.d/70-persistent-cd.rules: No such file or directory



In fact my whole /etc/udev directory is essentially empty. IN FACT, udev is was NOT installed on a clean new install. So the question at this point seems to be "what has taken over the funtion of udev?" Is this now somehow tied into systemd? (Like just about everything else these days?)

And ... well ... actually it looks like udev rules have now been moved out of /etc to /usr/lib/udev/rules with the relevant rule being - /usr/lib/udev/rules.d/60-cdrom_id.rules? The specific line in question would be: "KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100""

Oh ... and the kicker! If the udev package is not installed, what provides the udev functionality? Answer:

Code: Select all


[root@localhost rules.d]# rpm -q --whatprovides  /usr/lib/udev/rules.d
systemd-195-18.mga3



They DID merge udev into systemd!

So at this point you might want to do a quick `rpm -V systemd` and make sure that nothing is amiss their.

[ghmitch]

For one, there should be no fstab entries for cd/dvd drives, as that only gets you into problem with automatic mounting of the various desktop environments.
fstab entries for cd/dvd drives are obsolete and should be removed.

That is interesting. My fstab has the cdrom entry. This was a very recent new install of beta 2 and I don't remember putting that line in there. So I suspect it was put there by the installer. Perhaps you could double check on this?

[jaywalker]

...
That is interesting. My fstab has the cdrom entry. This was a very recent new install of beta 2 and I don't remember putting that line in there. So I suspect it was put there by the installer. Perhaps you could double check on this?

George, I can confirm that there is absolutely no need for the fstab entry for CDROM in MGA3 (or MGA2, for that matter). I think it's because it gets in the way of the New Way. I can remember having to remove that entry (and perl-HAL-cdrom, and udev v1) from all my MGA2 installations, but as this machine had no CDROM when I installed MGA3, I have no way of knowing if it would have created it.

I have done some searching around this issue today and the best guess I can come up with is that my IDE interface does not have (and probably never will have) support in libata. I think that means NO pseudo-scsi layer and thus no /dev/sd* or /dev/sr*. So I bit the bullet and scurried out to the shops to get a SATA CD/DVD burner, now fitted and providing a pristine /dev/sr0 and symlinked /dev/cdrom. All that just to get an optical drive to be accepted for what it is!

I am pretty certain that if any of The Old Ones are out there in Magiealand they would know how to get the system to behave the way it would have done before all this automated, self-configuring fakery took over, but life is short and I had to get this thing working before next weekend.

I may come back to this in the future as I am fairly sure that a cleverly written udev rule for cdroms, which accepted the possibility of the device being on an hd* node, might have done the trick. There is one other possible way forward; although the card has been discontinued for many years, there have been BIOS upgrades issued and one in particular addresses some ATAPI bugs. Still, without libata support (am I right about this?), it would probably still need some rule trickery at the very least.

The annoying point of all this is that if I were content to supply root authorisation every time I wanted to read an optical disc then I could almost live with the default situation. Almost. There are still problems getting Xine to use /dev/hdc in place of /dev/sr0, but one could always rip the video and watch that instead ... perhaps not.

Thanks again Dok for your pointers. It got me on the trail (convoluted though it was) of the likely cause of the problem.


Richard

[ghmitch]

It also may have been one or more missing kernel modules. But one would think that harddrake would have found and configured them. Over the years I had so much trouble with IDE that I have taken two of my four systems to 100% SATA. It is just a whole lot less headaches. I have one P4 system that does not support SATA, so it is IDE only. I hang onto it because its my only remaining system that can run Win98 in a pinch. I have another system that will eventually end up going SATA one way or another. Like it or not, SATA is the future and IDE support is getting more and more depreciated all the time. - George

[jaywalker]

I feel your pain:-) well, sort of. I haven't had your exposure to the nasty side of PATA (until today) but I did spend some few hours today rescuing old games from my last Windows system, W98lite. Though separated from their host PC I still harbour thoughts of reuniting them with a spare AMD K6 box I keep lying around for that purpose. One day...

Richard