maverick oem-config gtk frontend does not start on first boot because gdm runs before it

[Matt Sealey]

Binary package hint: ubiquity

Booting a system which has been "oem-config-prepare quiet" prepped, or just touching /var/lib/oem-config/run should enable and run a relevant oem-config frontend on first boot.

However, this does not happen. The scripts for oem-config and gdm conflict such that gdm starts first and takes on an Xorg instance, which then when oem-config starts, simply cannot run (because gdm is running on Xorg already and it cannot create another one on VT7).

Ideally oem-config should be run by upstart before gdm has had a chance to get there, maybe by making sure that gdm depends on oem-config having already been run (whether it gave up because /var/lib/oem-config/run did not exist or whether it ran to completion). This implies a whole new event, perhaps?

syslog, Xorg.log etc. do not show any of the information I saw spewed to VT1 once GDM had started up and oem-config had bailed out, but it was basically the usual messages you get when Xorg has been started twice. Since I cannot paste from the framebuffer console here, I guess this will have to be as much information as I can give.

To reproduce: probably make yourself a rootstock that has xubuntu-desktop or install a minimal or standard system and then aptitude install xubuntu-desktop on top. Then, install oem-config-gtk and touch /var/lib/oem-config/run and reboot, and see how it doesn't do what you expect...

[Evan (ev)]

The oem-config upstart job is set to "start on gdm", which means that GDM should never start before it. Can you please make sure you have the latest oem-config, then boot with --debug on the kernel command line? This will add upstart job debugging information to your logs (/var/log/syslog, /var/log/oem-config.log, etc), which I would then ask you to attach to this bug report.

Thanks!

[Oliver Grawert (ogra)]

rootstock already installs oem-config-gtk by default and configures it properly if you:

a) dont create a user from its commandline options (dont use -l and -p)
and
b) gdm or kdm gets installed by your packageset

it obviously starts fine in this configuartion for all other users, this issue must be related to you modifying the system after creation, could you try running rootstock with supplying a list of packages at rootstock runtime and not install them manually afterwards ?
see if that changes beahvior.

[Matt Sealey (mwsealey)]

Will try the debug thing. No changes have been made to the system since rootstock and adding packages. Way back in the deep dark past (jaunty?) this method I used worked fine. I don't think you can blame it on "modification" of the system. I ran aptitude.

Oliver, there are a couple bugs making oem-configuration from rootstock not work like 628587 and also a crazy problem we had with the permissions of the rolled tarball and the gdm user (when the tarball is created it seems to inherit the users from the host - on the chroot gdm:gdm looks like hplip:gdm and something is translating this user accounts somehow.. That is for another bug when I figure out what on earth is going on)

[Oliver Grawert (ogra)]

yes, bug 628587 clearly indicates that oem-config starts fine if you use rootstock without modifying anything (there surely is a bug with user creation we didnt have the time to research yet) ...

note also that rootstock doesnt use aptitude at any time ...

if you see permission errors with the rootstock created filesystem, please file a bug for rootstock and attach the build logs as well as /etc/passwd and /etc/groups

[Matt Sealey (mwsealey)]

After creating a rootstock with xfce about 20 times last week, and manually hacking the permissions before booting, I can safely say it does NOT start because GDM manages to get in the way every time. Rob must be very lucky to have a disgustingly slow SD card on his Beagleboard which is giving oem-config time to start.

We think we found something, more detail later.

[Robert Nelson (robertcnelson)]

Just a note...

I haven't really had a chance to test a working* oem-config/ubiquity with an xfce based image from rootstock (just bare terminal setups).. So I can't confirm or deny gdm may or may not be fighting with it..

*(just started testing the gtk gui version last week with 2.3.17/18/19 all of which seem to have random startup issues fixed the next release, so i'm just watching the builders and testing nightly...)

Regards,

[Robert Nelson (robertcnelson)]

Well with ubiquity 2.4.0 it seems to work.. (Beagle xM A 512Mb running at 800Mhz)

Other then crashing after it should be done.. but new user/settings all exist on next reboot with gdm showing my new user name...

Rootstock command:

MINIMAL_APT="btrfs-tools,i2c-tools,nano,pastebinit,uboot-envtools,uboot-mkimage,usbutils,wget,wireless-tools,wpasupplicant"
USER_PASS="--login ubuntu --password temppwd"

fixup-gui: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/tools/fixup-gui.sh

sudo ./rootstock --fqdn omap ${USER_PASS} --fullname "Demo User" --imagesize 2G \
--seed ${MINIMAL_APT},linux-firmware,xfce4,gdm,xubuntu-gdm-theme,xubuntu-artwork,xserver-xorg-video-omap3 \
--components "main universe multiverse" \
--dist maverick --serial ttyS2 --script ${DIR}/tools/fixup-gui.sh \
--kernel-image http://rcn-ee.net/deb/maverick/v2.6.35.5-l4/linux-image-2.6.35.5-l4_1.0maverick_armel.deb

Rootstock Patches I'm currently using in my tree:

http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/patches/01-rootstock-tar-output.diff
(only to speed up image creation on a beagle, let a later x86 do the compression)

http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/patches/03-rootstock-source-updates.diff
(no affect with maverick currently)

http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/patches/upgrade-old-debootstrap-packages.diff
(no affect with maverick currently)

http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/patches/oemconfig-and-user.diff
(set a default user and use oem-config)

Regards,

[Matt Sealey (mwsealey)]

Okay I guess I am going to run another minimal image up and fetch Xfce and ubiquity and see what the difference is.

We have a few fiddles to make sure GDM doesn't rocket off and make itself the owner of vt7 here but it remains to be seen if this is a real fix or just something we're going to use as a workaround. I've not seen it: just heard the results were pretty sound.

I've patched rootstock in mostly the same way, which is nice to know (although I added other compression methods, so if I set it to lzma it adds lzma etc. - simply because while it takes longer to compress the archive I get 100MB less data to move around)

[Matt Sealey (mwsealey)]

Okay our investigation showed that, empirically, once upstart has started a job (like gdm), no other job can stop it, even if it is (starts on) for that job. Actually this means that a system with gdm, kdm etc. installed they will all fight for a VT and the first one will get it, however this is a fairly rare setup (installer will never create it).

Our fix was pretty dumb, we added the same check to proceed in oem-config.conf as an exit into gdm.conf, after the 'script' marker:

if [ -f /var/lib/oem-config/run ]
then
   exit 0
fi

This way gdm will not start while oem-config is scheduled to run. Since oem-config tries to reboot afterwards this is fine and dandy.

We got the same crash as Rob here, attached. There are some errors about config-2.6.31.14-efikamx not existing: that's because we don't have a kernel package, only tar archives, so it's a hack. An initrd was created for us (yay!) successfully. I am not sure what ubiquity is trying to do here at all..

FYI for Oliver (and maybe rsalveti), "sudo oem-config-prepare quiet" is safe to run to make oem-config start on the next boot. All it does apart from checking if you're running a desktop and finding the right front-end (which it does properly here) is set the /var/lib/oem-config/run file.

[Matt Sealey (mwsealey)]

Just checked out plugininstaller.py line 761 at the crash: it's "os.symlink" to link /initrd.img to /boot/initrd.img-2.6.31.14-efikamx

I would note that the initrd.img is NOT massaged into a uImage.

The partition /boot is on is vfat, so no symlinks, so an obvious crash, no?

Rob is Beagle xM still stuck booting from FAT? Or are you using an ext2/3 partition? If so, is this a problem symlinking across filesystems or the result of a crappy filesystem irrespectively?

[Robert Nelson (robertcnelson)]

Hi Matt,

Yeah, on the omap's we are pretty much stuck with booting off FAT...

I'm not sure how Canonical does their images. But with the images I push out, I bypass the symlink problem by leaving /boot/* on the ext* partition, and mounting the fat as /boot/uboot/*... Then let some other scripts take care of updating and moving the uInitrd and uImage from /boot/* to /boot/uboot/* for u-boot..

Regards,

[Matt Sealey (mwsealey)]

Yergh, turns out that upstart hack doesn't work at all. start on (stopped oem-config) works better but oem-config seems never to technically finish. This is a nightmare.

Rob, that explains those few lines your fixup script.. :)

We're going to prep an update for all our lines soon that enables booting from ext2 partitions. We're sick of FAT. Windows doesn't mount the first partition of small SD cards anyway (it expects it to be a raw disk like a floppy) so it's kind of a useless thing..

[Alessio Treglia (quadrispro)]

I can confirm this and #9 fixes the issue.

[Matt Sealey (mwsealey)]

Here's a funny thing: if the system boots with initramfs (we only fixed U-Boot for this in November for all boards), oem-config and GDM cooperate and run fine.

[Matt Sealey (mwsealey)]

FYI this is happening again: we're starting to prep images with accelerated graphics by default, and the gdm X server is starting too fast again, so Ubiquity is failing 3 times out of 5...