CD Mounting Errors (ISO9660)
 

Part of the output from dmesg:

attempt to access beyond end of device
sr0: rw=0, want=1341044, limit=1311284
ISOFS: unable to read i-node block
isofs_fill_super: get root inode failed

------------------------------------------

hdparm /dev/sr0

/dev/sr0:
multcount = 0 (off)
IO_support = 0 (default)
readonly = 0 (off)
readahead = 256 (on)
HDIO_GETGEO failed: Inappropriate ioctl for device

----------------------------------------------------

A similar problem has plagued me in the past only to raise its ugly head again. The WWW is filled with similar problems. First, my drive and discs are fine and work perfectly under BW64 13.0/Slackware 13.0. Obviously this problem is related to the software, likely the kernel. Physically shutting down the computer and waiting about 10 seconds and then rebooting is the ONLY way to mount a CD (only the 1st time, however) without this error. I'm using the stock huge kernel so I suspect switching to a generic kernel or rebuilding the stock kernel to allow me access to the disk driver modules might allow me to physically unload and then reload the modules without having to cut the power to the computer.

Any ideas? As it is, Slackware64 13.1 is basically useless unless some of these bugs can be identified and eliminated.

Some indications that ATI's binary driver might be causing this problem. I do have Catalyst 10.5 installed... simply conjecture at this point.

Well, for giggles, I blacklisted the fglrx driver while leaving ATI's OpenGL libraries installed. No difference as I expected.

Whatever is causing this problem: HDIO_GETGEO failed: Inappropriate ioctl for device

Critical bug:

Bump!

Sorry, I do not have any actual help except to say that I have three systems now installed with Slackware 13.1 and I have no CD problems.

Two are 32 bit the other is 64 bit... all CD/DVDs mount fine here.

Count yourself fortunate, because this bug is a major and critical one.

Don't use the huge kernel, compile your own or use generic.

There's few more threads about this issue in slack LQ. It seems like only sata dvd drives are affected.

If that's the case try putting the SATA controller in AHCI mode in the BIOS options. This may help because this will force it to use the ahci driver over whatever SATA or PATA driver it might be currently using, which may have a bug in it.

Hi,

I still think it would be best if the 'OP' would switch to the generic instead of using a installer kernel.
:hattip:

BTW, I AM using the -generic 2.6.33.4 kernel, but the problem remains. I'm hoping an upgrade to a newer kernel in the 2.6.33.x series beyond 2.6.33.5 will fix this problem. This problem might not be related to the kernel, though.

IIRC *, my BIOS is pretty restrictive in changing parameters of the drives. I do remember that this particular DVD recorder doesn't use SMART, however. I'll do more checking. Thanks for any clues.

* I just checked the BIOS. The ONLY options are to either enable or disable the SATA controller which naturally isn't an option. ;) This PC came with a PATA controller and hard drive along with a SATA controller and DVD recorder. On the main menu of the BIOS, selecting the DVD recorder only brings up a screen whose options are NOT configurable, i.e. the options are greyed out. One of the greyed out options states the DVD recorder isn't SMART compatible. No reference to AHCI can be found in the BIOS.

Hi,
By the above statement it did seem you were still using the 'huge' instead of the 'generic'.

No where until now did we know you are using the generic kernel.

What does your 'mkinitrd' line look like?

What is the motherboard model, BIOS version & manufacture?
:hattip:

I am pretty sure this is not a kernel problem. I have tried the huge-smp kernel in Slack 13.1, and I tried my own custom 2.6.34 kernel, no difference. I also am pretty sure this is not a AHCI vs ATA native issue, I've tried both ways, same result.

I still think it's something in hal/udev.

I tend to agree. When I first noticed this horrific bug, I noticed that the CD/DVD seemed to only mount properly after a cold boot and ONLY the first time. * So, it seems logical to look for the bug in software dealing with the mounting/umounting of optical devices (removable) attached to a SATA controller. I also have a hard drive attached to this SATA controller, but I don't use it when I'm booted into SW64 13.1.

* I'm not 100% positive about the accuracy of this statement, though, from my initial tests only.

Ok, now the only option left is compiling a newer kernel, that's the only thing I can think of that might fix it.

What SATA controller do you have? I have an ASUS SATA DVD drive and do not see this problem at all. lspci shows the controller to be...

00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)

I've found another piece of the puzzle. The problem isn't strictly with optical media. The problem appears to affect ALL removable media, including flash devices.

Well, I'll add my 2 cents. I run Slackware64 13.1 and Slackware 13.1 (IDE/PATA controllers, 2.6.33.4-generic), plus Xubuntu and Ubuntu (sata controllers, 10.04 LTS, 2.6.32-22-generic), and I have this issue on all of them. I can automount all DVDs, all commercial pressed CDs, but my burned CDR and CDRW that are known good on Slackware 13.0 don't always automount. I have a 2 year old data CDR that mounts fine, but recently burned CDR (from Slackware 13.0) are about 75% fail to automount. Whether KDE, Xfce, or Gnome is used is not important. Explicitly mounting as root or using fstab works ok. This problem started once I left 2.6.29 series of kernels so its not my disks and it is not my hardware. I also have WinXP, Vista. and Win7 systems that automount all disks just fine. Googling shows a lot of activity with some fixes/work arounds that do not fix the underlying issue

This is a weird bug that I unfortunately no longer have the skills to track down (last code was Z80 assembly on CP/M-80) and it is driving me nuts. Sure, I can do it the "old fashioned way" but why should I not have automounting automation in the 21st century?

tpreitzel, nope, for me every USB stick and external USB hard drive (fat32, ext3 and NTFS) automount just fine here.

I have seen no issues automounting USB drives on my 13.1 box.

I'm willing to bet that the problem of mounting flash devices (internal USB card reader) will rear it's ugly little head in due time. It doesn't happen nearly as often as optical media *, but I've seen it with my own eyes. Simply a fluke? Possibly. ;) I'm certainly tiring of waiting for another kernel in the 2.6.33.x series, though ... Hint, kernel developers. ;)

* Only once so far with flash media in my experience

Interesting and unfortunate that you're experiencing the same problem with Ubuntu. It's also interesting that only your recently burned optical discs are failing with automount, but not manual mount. In my case, I have commercially mastered discs failing as well.

Your scenario isn't exactly equivalent to my experience, though. For sure, this bug (bugs?) is driving a considerable number of people over the edge. :)

Hi,


all the questions about problems with mounting optical disk
are probably due to the kernel bug.

But it is rather hard to get the kernel bug message in syslog.

So be patient. Sooner or later should be fixed.

OK! Let try to fix your problem:

1. Did you install slackware from CD-ROM ?
a) yes, I did. Ok, my advice: reinstall your system (oh no) but only with
base system (A series) and check if you are able to mount manually CD-ROM
b) no, I did'nt. Ok, try to use the install cd-rom. I guess it will work, then go to the point a)

Oh no! * My 13.1 system has much personal data transferred from BlueWhite64 13.0 so no reinstalling of SW64 13.1 will be done. Upgrading to 13.2 (6 months) is a possibility, but certainly not reinstalling.

Lastly, precisely what kernel bug are you implying? I just upgraded to 2.6.33.6 and the problem remains ... Periodically, I work with Slackware64 13.1 and add software so I won't have to do all that work later when the next version of Slackware64 is released which hopefully will fix this nightmare. My primary system remains BW64 13.0 until this problem is fixed.

* I may try the A series at some point ... maybe. More likely, I'll just periodically update SW64 13.1 until a new version of Slackware is released...

I know mu post is not very useful.

My system once reported a kernel bug. I regret I didn't post it.

I think that at this moment all systems with new kernels 2.6.33.x
should be used carefully, always have up to date backup your
important files.

I know this sound not very nicely, especially in the view of that
slackware is supposed to be stable (for some people it is stable),
but now I am still testing slack 13.1.

At the first time I installed slack on jfs file system, but next decided to reinstall on ext2
(for me it seems to be more safe).

I don't want to blame slackware. I want to use it and I use it.
Fast inspection of the forums for other distros shows that each new release
has quite similar problems (excluding debian, centos etc... they use kernels 2.6.2).

Yeah, I agree that time for testing needs to be extended all across the board, both developers and users. Thanks for your clarification. Something is wrong. Who knows where the bug resides precisely? I'll just keep waiting and updating my SW64 13.1 system as appropriate. Best wishes to you and the people of Poland...

Well, the problem is that "something is wrong" for a subset of Slackware users. (Fine. I guess that you could also state that "something is right" for a different subset of Slackware users. :-P )

I'd say that since Pat V and the set of Slackware maintainers/contributors did not see this issue, then I don't see how they would know the problem existed if the set of folks with the problem didn't whine about it. (Hey, I whine when I have problems with something.)

If you see problems in -current, you really, really, really need to report them. Pat's a nice guy who has some pride in Slackware. Who would want to release a broken distro?

I haven't had time lately to pursue this issue, but I'll say that it is still very much a problem on my system. I have installed the latest stable kernel (2.6.34.1) and same result.

To summarize again:

The problem does not occur on Slackware 13.0, it was introduced with 13.1. Re-install 13.0 and the problem goes away.
It doesn't matter whether you use a supplied (pre-compiled) kernel or compile your own. Every kernel release that I've tried has the same result.
It doesn't matter if you use AHCI or not, same result
It doesn't matter if you have a fstab entry for /dev/sr0 or not.
I, for one, have NO problem mounting audio cd's, USB sticks, or flash cards, just cd's with a filesystem (ISO9660).

There are MANY threads all over the web on this issue, not just Slackware but other distros as well. Nobody appears to have solved it.

yeah, this is a weird one. I just double/triple checked and booted into Slackware64 13.0 multilib and had no problems with any of the CDs. In fact, this is the 1st time automatic mounting in Xfce and KDE didn't work in quite some time. The work around is simple: use "mount" ... well fine ... that "solution" is all over the 'net. However the core issue is still there. I now have issue with Slackware 13.1 (both types, various boxes), Ubuntu, Xubuntu and Absolute Linux. These are all "full" distro installations with the latest updates.

The kicker is its ONLY CDRs in my system and not even all of them: pressed, old, new, burned today, burned whenever. And NONE of these CDs has any problems being automounted on WinXP, Vista or Win7. Something broke along the way to 13.1 Is it the kernel? udev? The driver switch and /dev/srx? consolekit/policykit? Does /etc/rc.d/rc.autofs need to be set executable and if so why do DVDs automatically mount ok?

I don't run a server so a well behaved desktop GUI is important to me. The CDs mount ok manually but that is an extra step I did not need in the past.

I assume the Slackware team is aware of this and that not all of them is so "old school" that they spend all day at the CLI with mount/umount.

So what say you, gang? How do we fix this?

I also have a machine running Slackware 13.1 that won't mount CDs.
I'll see something like this from dmesg
And KDE (or XFCE) will not offer to mount the CD.

Manually mounting the CD as root works.

Thumbdrives work.

The same hardware running Slackware 13.0 works.

This is an old PIII Coppermine, running the generic smp kernel.

Interesting. message log:
Syslog:
The system seems to keep trying to mount and keeps repeating this message until I manually mount or eject the CD.

Its funny how one little thing like this can drive you absolutely bonkers.

Those are the same messages I'm getting. Repeated 5 times, 4-5 seconds apart. Then it gives up. I can manually mount the CD at this point also.

This problem is just crazy. Keep us posted as you guys and gals find the time and stumble across more information... Extraordinarily frustrating to say the least. Linux simply can't afford to continue down this path. Around 2006, for nearly 6 MONTHS as the kernel team debated various fixes, none of the kernels would boot my VIA based system due to some problem with interrupts. In the long term, I'm done with monolithic kernels. I'm slowly moving to some micro kernel based OS over the next couple of years. In the meantime, I'll continue using Linux and pray for the best. ;)

Now that my wedding anniversary is past (20 yrs whoop!), I did one more test of this automount issue. I have Lite-On CDRW 48x IDE/ATA, LG DVDR-DL 16x IDE/ATA drives. Hard drives are 80 GB WD ATA-100, 120 GB Seagate ATA-100, and 500 GB WD SATA (sata2 drive on a sata1 controller). lspci reports:
I triple boot the following:

1. WinXP: no issues with any CD, DVD, USB stick or drive
2. Slackware64 13.0 multilib (stock generic kernel): no issues with any CD, DVD, USB stick or drive
3. Slackware64 13.1 multilib (stock generic kernel): DVD (data, video), CD-audio, usb stick and drive ok. CDR, CDRW are hit and miss.

Slackware64 13.1:

1. I have 4 Sony CDRW 650MB disc (2 with data, 2 blank): 2 were not sensed, 1 was sensed in k3b but not in Slackware, 1 as sensed by both k3b and Slackware.
2. I tested known good CDRs containing data (Memorex, TDK, Maxell). Some mounted ok, some did not, I saw no pattern. These where burned on a variety of systems (Slackware32 12.2, SLAMD6412.1, Slackware64 13.0). 2 observations: (a) CDRs burned with k3b/slackware64 13.1 are always mountable (see below). (b) CDRs that did not mount were sometimes visible in k3b with the correct size, label, etc., just not readable.
3. I tested Memorex, TDK, Maxell blank CDRs (700 MB, 48x or 52x speeds). Not all blank CDRs were visble in K3B (empty drive), but all those that were visible burned ok and were mountable on this and 2 other Slackware32 13.1 systems.

My regular user login and "root" both have the same issue. As "user" I am in all the correct groups - same ones as needed for Slackware 12.2 to 13.0. This system has been rock solid since Slackware/SLAMD64 11.0.

So there you have it. I think I will drown my sorrows with a few rounds of Urban Terror.

Well, I settled for a glass of gewurztraminer, but I came to the same conclusion. I've gone back to 13.0 for now, I still have the downloads so may try later if a solution appears. I did try kernel 2.6.35, same result.