FS#12853 - dbus-core and dbus post_install() commands not being executed

Attached to Project: Arch Linux
Opened by Richard Seward (ghosthack) - Sunday, 18 January 2009, 21:49 GMT
Last edited by Jan de Groot (JGC) - Sunday, 08 March 2009, 13:03 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

The commands in the post-install section of the dbus.install script are not being executed in the dbus-core package (and dbus in [extra]). Not sure if this is a package issue or a pacman issue as the similar commands in the hal.install script are executed.

This causes a problem when a user tries to start hal for the first time as the implict starting of the dbus daemon fails.

Additional info:
* package version(s)
dbus-core 1.2.4-1
dbus 1.2.4-1
* config and/or log files etc.


Steps to reproduce:

perform an ftp install, then examine the /etc/group and /etc/passwd files, the dbus user and group are not present, despite dbus-core being installed. If the dbus package is subsequently installed from [extra] the dbus user and group are still not present.
This task depends upon

Closed by  Jan de Groot (JGC)
Sunday, 08 March 2009, 13:03 GMT
Reason for closing:  Fixed
Comment by Jan de Groot (JGC) - Sunday, 18 January 2009, 22:40 GMT
Do you have some other group using gid 81 on your system? If the post_install scriptlet can't create the group, it won't create the user either.
Comment by Richard Seward (ghosthack) - Sunday, 18 January 2009, 23:21 GMT
No, this was from a fresh install. I was re-installing arch on my laptop (switched from 32-64bit), I used an ftp install to install base, base-devel and a few other things from core (wifi etc), then when I had re-booted into the installed system I installed hal in preparation for xorg and got the error when starting /etc/rc.d/hal since dbus could not start. At this point I had done very little additional configuration and there were no packages from outside of [core] or [extra] installed.
Comment by Richard Seward (ghosthack) - Monday, 19 January 2009, 00:34 GMT
Update:

I just tried another install on a spare partition installing only the 'base' group and this appears to have worked, I'm currently going through the pacman.log files to try and see if there are any obvious differences between the tailored install I did originally and the base group install. One thing that does seem strange is that dbus-core does not appear in the pacman.log files despite pacman -Q reporting that it is installed.
Comment by tuxce (tuxce) - Monday, 19 January 2009, 14:25 GMT
I also had this problem on 2 fresh installs (x86_64), but i didn't know why until now. (I thought it was me :))

Actually, the dbus-core package is installed before shadow package so the 2 commands: groupadd and useradd are not available while pacman is performing dbus.install so group and user dbus are not created.

part of /tmp/pacman.log:
----
installing dbus-core...
/tmp/alpm_EmwQ0N/.INSTALL: line 2: usr/sbin/groupadd: No such file or directory
/tmp/alpm_EmwQ0N/.INSTALL: line 3: usr/sbin/useradd: No such file or directory
installing attr...
installing acl...
installing binutils...
installing bzip2...
installing cracklib...
installing gcc-libs...
installing db...
installing pam...
installing shadow...
----
Comment by tuxce (tuxce) - Monday, 19 January 2009, 14:26 GMT
in addition: I used "archlinux-2008.06-ftp-x86_64.img"
Comment by Jan de Groot (JGC) - Monday, 19 January 2009, 14:43 GMT
ok, this makes sense. filesystem and shadow should be dependencies for dbus-core.
Comment by Greg (dolby) - Monday, 19 January 2009, 19:18 GMT
If wpa_supplicant moves out of base (  FS#12391  ) then this is automagically solved, no?
Comment by Richard Seward (ghosthack) - Monday, 19 January 2009, 20:48 GMT
"If wpa_supplicant moves out of base (  FS#12391  ) then this is automagically solved, no?"

I don't think so because [core] is still available during the system install phase so if a user requires wpa_supplicant to be on their fresh system then dbus-core will get pulled in so I think JGC's suggestion is still required.
Comment by Gerhard Brauer (GerBra) - Thursday, 22 January 2009, 13:35 GMT
Reason is IMHO errors in the .install scripts of extra/dbus and core/dbus-core.
Most/all command with an explicit path are missing the leading /, ex.:
getent group dbus >/dev/null || usr/sbin/groupadd -g 81 dbus
should be
getent group dbus >/dev/null || /usr/sbin/groupadd -g 81 dbus

Comment by Jan de Groot (JGC) - Thursday, 22 January 2009, 13:56 GMT
the install scriptlets are executed from /, so the command works fine.
Comment by Gerhard Brauer (GerBra) - Thursday, 22 January 2009, 14:10 GMT
@Jan: Sorry, you're right.
Deleting dbus user and reinstalling dbus-core does create the dbus user again.
Only get these error running with debug:
debug: adding entry 'dbus-core' in 'local' cache
debug: executing post_upgrade script...
debug: . /tmp/alpm_1gF6Gt/.INSTALL; post_upgrade 1.2.4-1 1.2.4-1
debug: chrooting in /
debug: executing ". /tmp/alpm_1gF6Gt/.INSTALL; post_upgrade 1.2.4-1 1.2.4-1"
debug: call to waitpid succeeded
error: scriptlet failed to execute correctly
debug: running "ldconfig -r /"
debug: closing database 'local'
Comment by Jan de Groot (JGC) - Thursday, 22 January 2009, 14:27 GMT
The error is because of the instruction in post_install. That entry returns false on recent installs. Rewriting that part to if/then should make the exit status work again.

Loading...