Partition in hard driver shown twice...

hi all,
I found a strange problem in my system. I installed hal and dbus, when I enter my nautilus, I found some of my hard driver shown twice... some of them, not all of them. I have 4 disks. Two partitions(NTFS) in a hard driver shown twice, but other partitions(also NTFS) in it are normal. One partition(HFS+) in another disk(GPT) shown twice and other partitions in that disk are normal...
I think this problem is caused by hal, but I dont know how to troubleshoot it and solve it.
Could you help me? thx!
 
It looks like (from a quick internet search of "hal partition shown twice") that this is a broader hal issue (ubunutu, debian, etc etc). Uhh, I honestly want to avoid hal[d] like the plague, so . . . it seems that partitions/slices that appear in /etc/fstab are likely to show up twice. What you can do about that, I do not know. Good luck.

Perhaps more info?

http://ubuntuforums.org/archive/index.php/t-514882.html

HTH
 
fronclynne said:
It looks like (from a quick internet search of "hal partition shown twice") that this is a broader hal issue (ubunutu, debian, etc etc). Uhh, I honestly want to avoid hal[d] like the plague, so . . . it seems that partitions/slices that appear in /etc/fstab are likely to show up twice. What you can do about that, I do not know. Good luck.

Perhaps more info?

http://ubuntuforums.org/archive/index.php/t-514882.html

HTH

hi,
I believe there is no extra items in fstab
Code:
[bear@bear /usr/ports/multimedia/mplayer]$ cat /etc/fstab 
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad18s1b		none		swap	sw		0	0
/dev/ad18s1a		/		ufs	rw		1	1
/dev/ad18s1e		/tmp		ufs	rw		2	2
/dev/ad18s1f		/usr		ufs	rw		2	2
/dev/ad18s1d		/var		ufs	rw		2	2
/dev/acd0		/cdrom		cd9660	ro,noauto	0	0
proc			/proc		procfs	rw		0	0
[bear@bear /usr/ports/multimedia/mplayer]$

And this problem only appeared in my FreeBSD. My debian works well ;)
 
Greetings,
It sounds like you're running Gnome, or some derivative. From my experience, in FBSD 8
anyway, if running a Gnom(ish) desktop environment; remove hald_enable="YES" from
your /etc/rc.conf file. In other words, you only need dbus (dbus_enable="YES" in /etc/rc.conf) if using Gnome.

Best wishes.
 
Good joke!
Then...oops! - mouse doesn't work! :e and keyboard! :e very funny...
Actually some more tuning is required to get X and some light WMs working without hal. Gnome needs more.
Once I got same problem on KDE, it dissolved itself very soon after current updates so I don't know what was a reason. Maybe some corrupted files in /media or typo in PolicyKit.conf or hal itself required rebuilding.
This blog is about AHCI but also about disk labeling on the fly.
Perhaps this can help.
 
zeiz said:
Good joke!
Then...oops! - mouse doesn't work! :e and keyboard! :e very funny...
Well, I wasn't able to use my mouse at all. I had other problems as well. In fact
X had a complete fit. I messed with everything I could think of. Finally, I commented
both hald_enable="YES" and dbus_enable="YES", bounced the box, and tried again.
This time things didn't work smoothly, and gnome related errors appeared. So I UNcommented
dbus_enable="YES" and bounced the box again. Then restarted X. No errors, and every
application I have installed works w/o complaint. Xorg.log is clean, and error free.
I suppose I should note this is not on my amd64, but rather on an 8-STABLE/i386. I am still
building my X env on the 8.1-PRERELEASE/amd64. But preliminary testing of my Geforce 8400 GS with the newest Nvidia drivers (from Nvidia, not ports) required installing twm, and xfce4 to get any idea if my (non ports) version of the Nvidia driver worked as expected.
Turns out, it all works even better than expected. Granted, those tests were not conducted in a Gnome/Gnome-like env, but I had no issues with hald_enable="YES" commented in rc.conf. It may simply be that no mouse || keyboard is defined in your xorg.conf - purely a guess, I don't know why it always works for me and not for you. :)

Just thought it was worth mentioning. :)

Best wishes.

zeiz said:
Actually some more tuning is required to get X and some light WMs working without hal. Gnome needs more.
Once I got same problem on KDE, it dissolved itself very soon after current updates so I don't know what was a reason. Maybe some corrupted files in /media or typo in PolicyKit.conf or hal itself required rebuilding.
This blog is about AHCI but also about disk labeling on the fly.
Perhaps this can help.
 
I didn't say keyboard&mouse wouldn't work without hal. Instead I said they would but along with your proposal you supposed to explain OP what changes must be done to get them working in particular DE or at least to mention those changes and the DE.
Hopefully xorg-server-1.8 will be hal free as well as Gnome3 (if we're do talking about Gnome).
 
zeiz said:
I didn't say keyboard&mouse wouldn't work without hal. Instead I said they would but along with your proposal you supposed to explain OP what changes must be done to get them working in particular DE or at least to mention those changes and the DE.
Hopefully xorg-server-1.8 will be hal free as well as Gnome3 (if we're do talking about Gnome).
Sorry zeiz,
You're quite correct - my bad. :(
In answer to the OP; I used the defaults - relevant sections follow:
Code:
Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/sysmouse"
    Option         "ZAxisMapping" "4 5 6 7"
EndSection

Hope this helps, and sorry for the oversight.
 
Back
Top