What on earth would cause automount to fail, yet a manual mount attempt of the same media succeed?

Using...

• the "Terminator" script posted here and elsewhere online;
• autofs v4 support is built-in to the kernel;
• iso9660 fs support is built-in to the kernel;
• "cdrom0 -fstype=iso9660,ro,gid=100,umask=002 :/dev/sr0" in auto.cd, along with a similar line for my second cdrom drive;

...yet invariably automount's attempts fail with the following:


Manually mounting the same media on the other hand to any arbitrary mount point, works flawlessly.


I don't get it. Anyone have any ideas?

Is the CD using UDF? I know in /etc/fstab you can specify udf,iso9660 as the filesystem type. It will try UDF first and fall back to iso9660 (also called cdfs someplaces? I don't remember the details...) if the first failed. Maybe that will work here? (disclaimer: haven't tried it with the script)

I wish it was that easy.

The CDs I've been testing it with are iso9660/joliet. Not to mention that when I mount them manually, mount picks up the filesystem type on its own quite happily. I've tried setting "-fstype=auto" in auto.cd, but to no avail.


Neat... I didn't know that. Consider this filed away for future experimentation after I get automount to behave.

I've been having problems with autofs the last few days. I wonder if there is a change in config file syntax because I've been getting some warnings about wrong commands.

I had 4.0.0 running ok, then updated to 4.1.4 and things started going wrong. Also the version in -current (3.x.x) doesn't seem to help.

Just removepkg'd it installed 4.1.4 again and it works, but what I noticed was that my /etc/auto.cd gets deleted with the removepkg.

I notice your auto.cd has:

cdrom0 -fstype=iso9660,ro,gid=100,umask=002 :/dev/sr0"

But the error says:

utomount[2665]: >> mount: wrong fs type, bad option, bad superblock on /dev/sr1,

I haven't tried 4.x yet; this is all with 3.1.7 from the 10.2 distro.

Interestingly enough come to think of it, this trouble started when I moved to the 2.6 kernel. automount behaved itself when I was running 2.4.

Good catch, but as I said in my first post auto.cd includes a similar line for my second cdrom drive.

The way to do this with a 2.6.x kernel is with HAL and dbus, and you do not use the ide-scsi module anymore with the 2.6.x kernels.

I managed to get 4.1.4 running. I have had a 2.6.15 kernel for a while and have no idea why it works now. I don't have HAL installed though.

I don't see either HAL or dbus in current. Are they made completely obsolete by udev?

I noticed some pertinent changes in the *.new startup files in rc.d that affect automounting.

I haven't looked in to HAL yet, but if you compare the release dates of dbus to the timestamps of the packages in "current", dbus is ahead in the game.

I would assume that it hasn't been made obsolete; rather that "current" hasn't caught up to it yet.

I still haven't tried adding dbus to my system yet to see what effect it has on autofs. I've been intending to, but life keeps getting in the way...

I have neither HAL not DBUS and automount works fine. Just be sure to uninstall all previous versions of autofs - ie dont upgradepkg, do removepkg and installpkg separately is all I can think of that made it work for me. Also I think the auto.x file format has changed so do a 'man auto.master'. Maybe that was the problem.

Also I found after removing autofs 3.x that it also removed /etc/auto. files too.

No, they make use of it.

Thanks, but no upgrades have been done in my case. The same build of autofs has been distributed with Slack since 8.1 as far as I can remember, and that's all that I've been using.

That hal dbus kde can be tricky. I got it all working by using a wiki at kde.org and google. Can't tell you whether it will be added to future versions of slackware though. Pat's keeping it old school for now.