[OE-core] postinst does not finish

[Koen Kooi]

Op 21 apr. 2013, om 17:09 heeft Richard Purdie <richard.purdie at linuxfoundation.org> het volgende geschreven:

> On Sun, 2013-04-21 at 08:59 +0200, Koen Kooi wrote:
>> Op 19 apr. 2013, om 16:00 heeft Koen Kooi <koen at dominion.thruhere.net> het volgende geschreven:
>>> Op 19 apr. 2013, om 15:37 heeft Koen Kooi <koen at dominion.thruhere.net> het volgende geschreven:
>>> And it still doesn't work :(
>>> 
>>> root at beaglebone:~# systemctl status gdm -a
>>> gdm.service - Gnome Display Manager
>>>  Loaded: loaded (/lib/systemd/system/gdm.service; enabled)
>>>  Active: active (running) since Sat 2000-01-01 19:22:11 UTC; 13 years 3 months ago
>>> Main PID: 147 (gdm-binary)
>>>  CGroup: name=systemd:/system/gdm.service
>>>          └─147 /usr/sbin/gdm-binary -nodaemon
>>> 
>>> Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Couldn't look up uid
>>> Apr 19 13:56:22 beaglebone gdm-simple-slave[337]: WARNING: User gdm doesn't exist
>>> Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Unable to parse output:
>>> Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Unable to parse D-Bus launch output
>>> Apr 19 13:56:22 beaglebone gdm-simple-slave[338]: WARNING: User gdm doesn't exist
>>> Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Could not run helper: Failed to execute child process "/usr/lib/gdm/ck-get-x11-display-device" (No such file or directory)
>>> Apr 19 13:56:22 beaglebone gdm[147]: gdm-binary[147]: WARNING: GdmDisplay: display lasted 1.401004 seconds
>>> Apr 19 13:56:22 beaglebone gdm-binary[147]: WARNING: GdmDisplay: display lasted 1.401004 seconds
>>> Apr 19 13:56:22 beaglebone gdm-binary[147]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors
>>> Apr 19 13:56:22 beaglebone gdm[147]: gdm-binary[147]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors
>>> 
>>> Hmm, let's rerun gdm.postinst:
>>> 
>>> root at beaglebone:~# sh /var/lib/opkg/info/gdm.postinst 
>>> + '[' x '!=' x ']'
>>> + grep '^gdm:' /etc/group
>>> + grep '^gdm:' /etc/passwd
>>> + adduser --disabled-password --system --home /var/lib/gdm gdm --ingroup gdm -g gdm
>>> adduser: /var/lib/gdm: File exists
>>> + '[' -d /var/lib/gdm ']'
>>> + chown -R gdm:gdm /var/lib/gdm
>>> + chmod 0750 /var/lib/gdm
>>> + mkdir -p /etc/X11/
>>> + echo /usr/bin/gdm
>>> + OPTS=
>>> + '[' -n '' ']'
>>> + type systemctl
>>> + systemctl enable gdm.service
>>> + '[' -z '' -a enable = enable ']'
>>> + systemctl restart gdm.service
>>> + test x '!=' x
>>> + OPT=-s
>>> + type update-rc.d
>>> + update-rc.d -s gdm start 99 5 2 . stop 20 0 1 6 .
>>> System startup links for /etc/init.d/gdm already exist.
>>> + '[' x '!=' x ']'
>>> + GDK_PIXBUF_MODULEDIR=/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders
>>> + gdk-pixbuf-query-loaders --update-cache
>>> [  102.324520] tilcdc 4830e000.fb: timeout waiting for framedone
>>> + for icondir in '/usr/share/icons/*'
>>> + '[' -d /usr/share/icons/Crux ']'
>>> + gtk-update-icon-cache -fqt /usr/share/icons/Crux
>>> + for icondir in '/usr/share/icons/*'
>>> + '[' -d /usr/share/icons/HighContrast ']'
>>> + gtk-update-icon-cache -fqt /usr/share/icons/HighContrast
>>> + for icondir in '/usr/share/icons/*'
>>> + '[' -d /usr/share/icons/HighContrast-SVG ']'
>>> + gtk-update-icon-cache -fqt /usr/share/icons/HighContrast-SVG
>>> + for icondir in '/usr/share/icons/*'
>>> + '[' -d /usr/share/icons/HighContrastInverse ']'
>>> + gtk-update-icon-cache -fqt /usr/share/icons/HighContrastInverse
>>> + for icondir in '/usr/share/icons/*'
>>> + '[' -d /usr/share/icons/HighContrastLargePrint ']'
>>> + gtk-update-icon-cache -fqt /usr/share/icons/HighContrastLargePrint
>>> 
>>> (etc)
>>> 
>>> So it looks like the postinsts do run when used inside run-postinst.service, but don't save their output (sucky description, I know).
>> 
>> Another datapoint, same GNOME image built for x86 finishes run-postinsts as expected, but also doesn't work, gconf stuff has to get run manually again to work.
> 
> FWIW I think there are multiple issues here and they're combining
> together to make a rather weird problem.
> 
> One issue we now know about is that the intercept code and the way it
> uses "exit 1" can cause some later parts of some postinst scripts not to
> get executed. I believe Laurentiu has a fix for this problem and this is
> the one causing the gdm issue.
> 
> I think the hang people are reporting is something else though, perhaps
> related to the hwdb. I'm also aware of matchbox-session-sato conflicting
> with settings-deamon and some multilib issues such as the wrong
> qemuwrapper being used.
> 
> We're going to have to work through each issue in turn and re-evaluate
> after each fix.
> 
> I wish we'd come across this earlier as to add fixes to the release at
> this point would mean slipping the release date by a week :(. I'm
> therefore leaning towards testing any fixes and queuing them quickly on
> the branch post-release, following up with a point release relatively
> soon to catch things that people find as the release gets more exposure.
> I know the point releases have happened slowly and I want to change
> that.

To be honest, I don't are about point releases, I only care about fixes getting into the release branch in a timely fashion. I build from git branches, not from tarballs after all.

regards,

Koen