dbus/hal problem after package upgrade

nightfrost · 2005-11-12 14:23:58

is something wrong with the latest dbus or hal? After an upgrade I am no longer getting fstab updated properly after sticking in external devices. Previously I used to get /media/[volume name] created and added to fstab. Now, I only get /media/sdXY created (instead of volume name), and fstab doesn't get updated.

Output of lshal seems normal to me...

any ideas?

EDIT: Alright; just notice that the subdirs under /etc/hal/fdi are empty. Shouldn't they contain config files?

nightfrost · 2005-11-12 14:40:45

I can now confirm that it's hal. I reverted to 0.5.4-1, and I'm back to normal. Should I file a bug report?

JimboP · 2005-11-12 15:48:36

According to CVS that is by design for HAL:

upgpkg: hal 0.5.4-2
Add patch to fix ipod-like device mountpoints
Disable fstab-sync
Run hal as unprivileged user
Change RC script to start dbus when required
clean up configure parameters

since fstab is no longer edited, use pmount to mount removable devices as normal user

nightfrost · 2005-11-12 16:03:16

but doesn't that mess up gnome's volume manager? Doesn't gnome-volume-manager depend on the fstab and the mount points at /media?

T-Dawg · 2005-11-12 17:24:00

yeah fstab syncing is compiled out of hal now. You can use pmount in place of it:

pmount /dev/sda1 flashdrive

that will mount the device into the /media directory as flashdrive without any fstab entry for it.

nightfrost · 2005-11-12 17:27:59

Thanks; that sounds fair enough. But hal is still creating /dev/sda1 for me (without syncing fstab). So if I mount with pmount /dev/sda1 external_disk, I'll have /media/sda1 and /media/external_disk..

JGC · 2005-11-12 17:44:17

I still need to fix some bugs in this:

- hal needs to have some rules fixed (/media/sda1 will turn into /media/usbdisk again after this)
- gnome-vfs needs to know about pmount-hal (it uses pmount now)
- gnome-volume-manager needs to know about pmount (it uses mount now)

I'm bugfixing hal for the floppydrive mount handling, without this patch I would have to fuck up gnome-vfs the same way I did to KDE with 3.4.2. I don't like that at all.

nightfrost · 2005-11-12 18:02:12

ah alright. thanks for the clarification..

T-Dawg · 2005-11-12 23:03:25

JGC:
I'm getting "unknown user 'hal' " when I start dbus and I thought I had an error from udev during boot which I couldn't read in time.
It was fine once I downgrade hal.

JGC · 2005-11-13 00:46:30

Seems on some systems the useradd right after the groupadd doesn't work. When I'm building the new fixed version, I will hardcode the group membership of hal to the correct gid. Reinstalling hal will also solve your "unknown user hal" bug.

T-Dawg · 2005-11-13 02:02:14

JGC wrote:

Reinstalling hal will also solve your "unknown user hal" bug.

I tried that before and it didn't work. I was going to try to build it but it was missing the .install and some other patch after running abs.

Thikasabrik · 2005-11-13 21:06:31

I had that problem - turned out I already had a group with the same id as the hal.install tries to use...

Also, shouldn't hal be a member of 'disks' too?

MartinZ · 2005-11-14 12:53:14

The problem with udev says something like

"greb: mdadm.conf not found"

I don't know why i'm getting this error, i haven't dmadm installed (don't use RAID devices).

Will i be able to use the xfce-mount-plugin after the fix for hal pkg?

Thanks

JGC · 2005-11-14 13:57:24

Thikasabrik wrote:

I had that problem - turned out I already had a group with the same id as the hal.install tries to use...
Also, shouldn't hal be a member of 'disks' too?

Having hal as group membership "disks" is plain stupid: whoever has membership to this group can dd/cat your harddrive, transfer the image somewhere else and read all your root-only-readable files on that other system. If hal would be member of the disk group, we could just run hal as root instead, because it has no use whatsoever to run it different then.

Thikasabrik · 2005-11-14 22:06:19

JGC wrote:

Thikasabrik wrote:
I had that problem - turned out I already had a group with the same id as the hal.install tries to use...
Also, shouldn't hal be a member of 'disks' too?
Having hal as group membership "disks" is plain stupid: whoever has membership to this group can dd/cat your harddrive, transfer the image somewhere else and read all your root-only-readable files on that other system. If hal would be member of the disk group, we could just run hal as root instead, because it has no use whatsoever to run it different then.

Allright, but the same applies to storage.. what if I have a big external USB disk formatted in ext3, or whatever, with root-only-readable files on? Maybe I keep all my most important docs on there and put it in a safe when I finish with it... maybe.. 8) Is hal a big security risk?

T-Dawg · 2005-11-15 01:05:35

JGC:
I was messing around trying to manually add the group and user hal from the .install file from the package I had and entered:

sudo /usr/sbin/useradd -c 'HAL daemon' -u 82 -g hal -G floppy,optical,storage -d '/' -s /bin/false hal

this gave me:

useradd: unknown group floppy
useradd: unknown group optical
useradd: unknown group storage

So I reinstalled filesystem and and then hal and now Its working fine without the hang-ups or "Uknown user 'hal" messages.

Why these groups were missing in the first place I have no idea.

Mythoz · 2005-11-15 07:56:48

Penguin wrote:

Why these groups were missing in the first place I have no idea.

Groups are defined in /etc/group file which belongs to filesystem package. Because you can add your own custom groups it's never overwritten (God forbid!). Instead everytime you update the filesystem package the default group file is saved as /etc/group.pacnew.

But there is no automatic mechanism which syncs old and new group files. So newly introduced groups in a filessytem package update are never transported to your current /etc/groups. You have to do it by hand.

A nice feature would be some post_install magic in the filesystem package. It could inform the user which default groups are added or removed with the new update so you can care of this. Or it could do it even automatically or interactive ("Do you want to remove group ... [y/N]").

T-Dawg · 2005-11-15 10:29:03

I don't understand. The filesystem package has this .install file you speak of which creates the proper groups. I know the default goes to .pacnew thats why I never touched it. I have about forty users on this machine running as a server, the last thing I wan't to do is monky with passwd or group

Mythoz · 2005-11-15 12:33:14

Penguin wrote:

I don't understand. The filesystem package has this .install file you speak of which creates the proper groups.

Argh! Yes, you are absolutly right. Stupid me, I have should have looked first before writing this (nonsense)...

Penguin wrote:

I know the default goes to .pacnew thats why I never touched it. I have about forty users on this machine running as a server, the last thing I wan't to do is monky with passwd or group

Full acknowledge!

Stalwart · 2005-11-15 18:35:00

That's why i came to forums. After dbus/hal upgrade my flash mp3-player doesn't mount automatically anymore I am using gnome-volume-manager

MartinZ · 2005-11-16 16:07:18

Now everything goes ok with last upgrade. Thanks JGC

MartinZ · 2005-11-16 21:34:05

No, it isn't. I was wrong, xfce-mount-plugin still doesn't work. Sorry, i don't know what did i "wrong" the last time that it worked.

Downgraded to hal 0.5.4-1 again

T-Dawg · 2005-11-17 06:13:55

MartinZ wrote:

No, it isn't. I was wrong, xfce-mount-plugin still doesn't work. Sorry, i don't know what did i "wrong" the last time that it worked.
Downgraded to hal 0.5.4-1 again

Works fine here. Whats the problem?
BTW: xfce4-mount-plugin isn't an official arch package.

JGC · 2005-11-17 07:48:32

With the new hal, pmount is required to mount volumes as regular user. xfce4-mount-plugin only supports things in fstab and has mount hardcoded in it. This package is useless without hal running as root.

nightfrost · 2005-11-17 10:24:31

Let me just get this straight. If hal is supposed not to be run as root anymore, are we expected to remove it from the damons array in rc.conf? Should it be put in .bashrc or something? Or is KDE, GNOME, et. al. supposed to start the service automatically for the user?

Arch Linux

#1 2005-11-12 14:23:58

dbus/hal problem after package upgrade

#2 2005-11-12 14:40:45

Re: dbus/hal problem after package upgrade

#3 2005-11-12 15:48:36

Re: dbus/hal problem after package upgrade

#4 2005-11-12 16:03:16

Re: dbus/hal problem after package upgrade

#5 2005-11-12 17:24:00

Re: dbus/hal problem after package upgrade

#6 2005-11-12 17:27:59

Re: dbus/hal problem after package upgrade

#7 2005-11-12 17:44:17

Re: dbus/hal problem after package upgrade

#8 2005-11-12 18:02:12

Re: dbus/hal problem after package upgrade

#9 2005-11-12 23:03:25

Re: dbus/hal problem after package upgrade

#10 2005-11-13 00:46:30

Re: dbus/hal problem after package upgrade

#11 2005-11-13 02:02:14

Re: dbus/hal problem after package upgrade

#12 2005-11-13 21:06:31

Re: dbus/hal problem after package upgrade

#13 2005-11-14 12:53:14

Re: dbus/hal problem after package upgrade

#14 2005-11-14 13:57:24

Re: dbus/hal problem after package upgrade

#15 2005-11-14 22:06:19

Re: dbus/hal problem after package upgrade

#16 2005-11-15 01:05:35

Re: dbus/hal problem after package upgrade

#17 2005-11-15 07:56:48

Re: dbus/hal problem after package upgrade

#18 2005-11-15 10:29:03

Re: dbus/hal problem after package upgrade

#19 2005-11-15 12:33:14

Re: dbus/hal problem after package upgrade

#20 2005-11-15 18:35:00

Re: dbus/hal problem after package upgrade

#21 2005-11-16 16:07:18

Re: dbus/hal problem after package upgrade

#22 2005-11-16 21:34:05

Re: dbus/hal problem after package upgrade

#23 2005-11-17 06:13:55

Re: dbus/hal problem after package upgrade

#24 2005-11-17 07:48:32

Re: dbus/hal problem after package upgrade

#25 2005-11-17 10:24:31

Re: dbus/hal problem after package upgrade

Board footer