On Mon, Apr 22, 2013 at 10:36 AM, Koen Kooi <[email protected]> wrote: > > 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 I think I got at least a hot hint on this: opkg-cl configure seems started twice. I did
* create an image * deleted /etc/rcS.d/S98run-postinsts from this image manually * booted fine Andreas _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
