Hi! I have just installed 10.0 and have a strange problem with automounting cd's. It looks, that as compared to 9.3 they both have a subfs mount points defined with "noauto" flag, but in case of 9.3 somewhere half-way through the boot-up process a "/usr/sbin/hald-subfs-mount" gets called and it mounts subfs over /media. However this doesn't happen to me with 10.0, and I have to mount it manually. Are there some suggestions on how to resolve it properly? At the time I have just removed noauto flag, but it should have been there for a good reason I suppose :) -- Best regards, Alexander.
On Friday 07 October 2005 12:19, Alexander S. Usov wrote:
Hi!
I have just installed 10.0 and have a strange problem with automounting cd's. It looks, that as compared to 9.3 they both have a subfs mount points defined with "noauto" flag, but in case of 9.3 somewhere half-way through the boot-up process a "/usr/sbin/hald-subfs-mount" gets called and it mounts subfs over /media. However this doesn't happen to me with 10.0, and I have to mount it manually.
Are there some suggestions on how to resolve it properly? At the time I have just removed noauto flag, but it should have been there for a good reason I suppose :)
I have done a bit more investigations, and it seems that in mine installation the hotplug part is not working correctly. It doesn't reacts on plugging in external usb hdd, it doesn't mounts subfs stuff, and even a basic stuff like lshal, hal-device or hal-device-manager doesn't work dying with some strange errors like $ lshal lshal version 0.5.4 error: libhal_ctx_init: (null): (null) The most weird in this situation is that it is reproducible -- just today I have tried to reinstall it once more, without making any fancy choices in the installer and still got the same strange result. The only reason I can imagine at this point is a somewhat strange way I do the installation -- I have put a DVD-Eval distribution on my other machine and use a boot.iso from 10.0-OSS to start the network install on this one. But it sounds too crazy to be true. Am I the only one having this kind of problems? Where then should I try to ask to get help resolving it? -- Best regards, Alexander.
On Saturday 08 October 2005 05:07, Alexander S. Usov wrote:
I have done a bit more investigations, and it seems that in mine installation the hotplug part is not working correctly. It doesn't reacts on plugging in external usb hdd, it doesn't mounts subfs stuff, and even a basic stuff like lshal, hal-device or hal-device-manager doesn't work dying with some strange errors like $ lshal lshal version 0.5.4 error: libhal_ctx_init: (null): (null)
This is the normal message from lshal if hald is not running (check with 'ps -aux | grep hal' or 'rchal status'). Cheers, Danny
On Wednesday 12 October 2005 21:17, Danny Kukawka wrote:
On Saturday 08 October 2005 05:07, Alexander S. Usov wrote:
I have done a bit more investigations, and it seems that in mine installation the hotplug part is not working correctly. It doesn't reacts on plugging in external usb hdd, it doesn't mounts subfs stuff, and even a basic stuff like lshal, hal-device or hal-device-manager doesn't work dying with some strange errors like $ lshal lshal version 0.5.4 error: libhal_ctx_init: (null): (null)
This is the normal message from lshal if hald is not running (check with 'ps -aux | grep hal' or 'rchal status').
The collective intelligence had already figured it out ;) It's incorrectly built hal package, which doesn't has one of the helpers. -- Best regards, Alexander.
On Wednesday 12 October 2005 22:59, Alexander S. Usov wrote:
On Wednesday 12 October 2005 21:17, Danny Kukawka wrote:
On Saturday 08 October 2005 05:07, Alexander S. Usov wrote:
I have done a bit more investigations, and it seems that in mine installation the hotplug part is not working correctly. It doesn't reacts on plugging in external usb hdd, it doesn't mounts subfs stuff, and even a basic stuff like lshal, hal-device or hal-device-manager doesn't work dying with some strange errors like $ lshal lshal version 0.5.4 error: libhal_ctx_init: (null): (null)
This is the normal message from lshal if hald is not running (check with 'ps -aux | grep hal' or 'rchal status').
The collective intelligence had already figured it out ;) It's incorrectly built hal package, which doesn't has one of the helpers.
As wrote in the thread the package is not incorrect. The problem is the hal package self. There is the bug. In fact the build of the helper is enclosed in ifdef's. Because of a missing libary in the build environment the helper was not compiled. The problem: in this case the related fdi-file should be changed if the helper is not compiled, but it does not happens automatically. Cheers, Danny
participants (2)
-
Alexander S. Usov
-
Danny Kukawka