Guest gasparov Posted February 21, 2005 Report Share Posted February 21, 2005 Hi, I just wondering how mandrake automagically mounts usb drives, I know that when you plug a device udev and hotplug do the job and you can find your device in /dev. Here comes my first problem: where can you write udev specific rules?It seems that Mandrake use udev its way, you should add your rules in a file that comes before 50-udev.rules,in mandrake all first lexical position are already occupied. What happend next ,who writes stuff in my /etc/fstab? gconfd,hal ,autofs what are they?I'm using 10.1 official. I'd like to know how mandrake specifically deals with this things before starting playing around.... Quote Link to comment Share on other sites More sharing options...
aRTee Posted February 21, 2005 Report Share Posted February 21, 2005 I'm sorry to have no hands-on know-how, but did you check /var/log/messages? I'm also very interested, I really hope someone can dig up some more info on this. Quote Link to comment Share on other sites More sharing options...
adamw Posted February 21, 2005 Report Share Posted February 21, 2005 drakupdate_fstab is called by hotplug, it writes a line for the device into /etc/fstab, and mount is then called to mount it. When the device is removed, the line is taken out. At least, that's my understanding. I'm not entirely sure where magicdev plugs in. 10.2 will be different again, just for kicks. Quote Link to comment Share on other sites More sharing options...
aRTee Posted February 21, 2005 Report Share Posted February 21, 2005 Yeah, that is what shows up in /var/log/messages too, but I read somewhere that it's even possible to make sure that some kind of usb-storage device always gets a certain mountpoint, for instance, if you have more than one digital cam, to have one mounted at /mnt/panasonic and the other at /mnt/sony, depending on the info the system gets from lsusb or in whatever way it gets the info... Quote Link to comment Share on other sites More sharing options...
scarecrow Posted February 22, 2005 Report Share Posted February 22, 2005 (edited) Try kernel 2.6.10 combined with udev, dbus and hal... Everything is done much more easily, without having to touch udev.rules at all. Edited February 22, 2005 by scarecrow Quote Link to comment Share on other sites More sharing options...
adamw Posted February 22, 2005 Report Share Posted February 22, 2005 (edited) artee: that already works, or at least is *supposed* to, in 10.2 beta / Cooker. whichever component actually does the reporting (dbus, or whatever, I lose track...) passes on the manufacturer ID, and fstab-sync uses that for the mountpoint. The hal rules are quite an illuminating read on how all this stuff works, they have pages and pages of special cases and exceptions etc. Edited February 22, 2005 by adamw Quote Link to comment Share on other sites More sharing options...
aRTee Posted February 22, 2005 Report Share Posted February 22, 2005 Thanks a lot for the info guys. Ok, so I'll be getting ready to test Mdk10.2.... sorry, no time for betatesting, I will test RC's and CE to the bone instead... Quote Link to comment Share on other sites More sharing options...
archiesteel Posted February 24, 2005 Report Share Posted February 24, 2005 I'm on a cookerized 10.1 and for the life of me I can't get dbus, hal and gnome-volume-manager to work together. Inserted CDs don't appear on my desktop, and calling hal-device-manager shows devices, but my IDE devices are not identified (Unknown devices)... :-/ I've been trying to figure this out for a couple of days...any pointers would be very much appreciated! Otherwise I'll wait for 10.2. I figure my problem is that I've always been upgrading my box through rpmdrake ever since 9.2, instead of doing a clean reinstall. I probably have customized configuration files that prevent hal or dbus or gnome-manager from working properly... Quote Link to comment Share on other sites More sharing options...
adamw Posted February 25, 2005 Report Share Posted February 25, 2005 archiesteel: that does happen on cooker machines, yeah. It's a good idea on Cooker every couple of weeks to do this: updatedb slocate rpmnew diff all rpmnew files compared to the files that are actually being used. rpmnew files are created when you've changed a configuration file manually, basically; instead of replacing it, the system keeps it but installs the new version as filename.rpmnew. If the changes you made weren't significant and you don't need them, just replace the file with filename.rpmnew. If you need the changes, try and roll them into .rpmnew then use that. Do the same thing with .rpmsave; if the system really wants to overwrite a modified config file, it will, and save your modified version as .rpmsave. So check the .rpmsave for modifications you really needed, and roll them into the updated file. This can definitely help solve weird bugs like the above. Quote Link to comment Share on other sites More sharing options...
archiesteel Posted February 25, 2005 Report Share Posted February 25, 2005 Thanks adamw, I'll definitely try that tonight, I think a cleanup of rpmnew and rpmsave is well overdue on my system (it might not help solving my problem right away, though, as there seems to be a problem with the latest dbus-python package: hal-device-manager crashes when importing dbus.py...) Say, are you the same adamw that posts on OSNews? I'm known as "A nun, he moos" over there... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.