Op 21 apr. 2013, om 17:09 heeft Richard Purdie <[email protected]> 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 <[email protected]> het >> volgende geschreven: >>> Op 19 apr. 2013, om 15:37 heeft Koen Kooi <[email protected]> het >>> volgende geschreven: >>> And it still doesn't work :( >>> >>> root@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@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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
