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
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
|
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
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.
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...
----
FS#12391) then this is automagically solved, no?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.
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
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'