*** This bug is a duplicate of bug 650703 ***
https://bugs.launchpad.net/bugs/650703
** This bug has been marked a duplicate of bug 650703
oem-config-prepare works, but oem-config fails to start after reboot
* You can subscribe to bug 650703 by following this link:
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...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Also affects: efikamx
Importance: Undecided
Status: New
** Changed in: efikamx
Status: New = Confirmed
** Changed in: efikamx
Assignee: (unassigned) = Matt Sealey (mwsealey)
** Changed in: efikamx
Importance: Undecided = Medium
--
You received this bug notification
I can confirm this and #9 fixes the issue.
** Changed in: ubiquity (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/644638
Title:
maverick oem-config
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
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
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
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
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,
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
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
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
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
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
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:
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
17 matches
Mail list logo
