Hello, linaro-dev,
I am trying to follow the instructions at
https://wiki.linaro.org/Source/ImageBuilding
However, when I run "sudo lh build", I get the following output
P: Setting up cleanup function P: Begin caching bootstrap stage... P: Begin bootstrapping system... P: If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy. P: Running debootstrap (download-only)... I: Retrieving Release E: Failed getting release file http://ftp.de.debian.org/debian/dists/lenny/Release P: Begin unmounting filesystems...
Why is it trying to download files for lenny?
Hi!
On Mon, Jul 2, 2012 at 11:52 AM, David Cullen David.Cullen@koe-americas.com wrote:
Hello, linaro-dev,
I am trying to follow the instructions at
Hmm those instructions look a bit out of date and I suspect that's why you're having issues. I sure hope your build system doesn't date back to lucid for instance! :-)
That said, are you running this native on arm hardware or cross on intel?
If cross, here's what I do : https://wiki.ubuntu.com/TomGall/CrossBuild
If native steps are pretty much the same. Be careful what directory you start the build in and that you've run the conf_create.sh IE
bzr branch lp:~linaro-maintainers/linaro/live-helper.config.precise.ubuntu-desktop config cp config/conf_create.sh . sh conf_create.sh lb build
Looking at lp:~linaro-maintainers/linaro/live-helper.config.precise.ubuntu-desktop however I don't see much activity so I'm slightly concerned that it might not be up entirely to date. Should be fine but if you run into problems, please post.
Hopefully someone from dev platforms will speak up.
However, when I run "sudo lh build", I get the following output
P: Setting up cleanup function P: Begin caching bootstrap stage... P: Begin bootstrapping system... P: If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy. P: Running debootstrap (download-only)... I: Retrieving Release E: Failed getting release file http://ftp.de.debian.org/debian/dists/lenny/Release P: Begin unmounting filesystems...
Why is it trying to download files for lenny?
It shouldn't be.
-- Thank you, David Cullen
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hello, Tom,
I have replies inline below, but ultimately, I am really trying to figure out how are the Linaro devs building these files:
http://releases.linaro.org/12.06/ubuntu/leb-panda/
On 7/2/2012 1:30 PM, Tom Gall wrote:
On Mon, Jul 2, 2012 at 11:52 AM, David Cullen David.Cullen@koe-americas.com wrote:
Hello, linaro-dev,
I am trying to follow the instructions at
https://wiki.linaro.org/Source/ImageBuilding
Hmm those instructions look a bit out of date and I suspect that's why you're having issues. I sure hope your build system doesn't date back to lucid for instance! :-)
I was working with the OMAP3 EVM software from the TI site. Their instructions said that the only platform known to work with their software was Ubuntu 10.04 Desktop 32-bit.
I can switch to an Ubuntu 12.04 Server VM; but for cross-builds, it shouldn't make much difference.
That said, are you running this native on arm hardware or cross on intel?
I am trying to do a cross-build using the Linaro toolchain.
If cross, here's what I do : https://wiki.ubuntu.com/TomGall/CrossBuild
It worries me that your instructions are not merged with the Linaro wiki. Is there some good reason for this?
If native steps are pretty much the same. Be careful what directory you start the build in and that you've run the conf_create.sh IE
bzr branch lp:~linaro-maintainers/linaro/live-helper.config.precise.ubuntu-desktop config cp config/conf_create.sh . sh conf_create.sh lb build
Looking at lp:~linaro-maintainers/linaro/live-helper.config.precise.ubuntu-desktop however I don't see much activity so I'm slightly concerned that it might not be up entirely to date. Should be fine but if you run into problems, please post.
I got the link from here:
https://code.launchpad.net/~linaro-maintainers/linaro
But the "Last Modified" date is "2012-01-06" which does not inspire confidence.
Hopefully someone from dev platforms will speak up.
What is the difference between .nano and .developer?
Hi David
On Mon, Jul 2, 2012 at 1:06 PM, David Cullen David.Cullen@koe-americas.com wrote:
Hello, Tom,
I have replies inline below, but ultimately, I am really trying to figure out how are the Linaro devs building these files:
Sure thing. This helps.
On 7/2/2012 1:30 PM, Tom Gall wrote:
On Mon, Jul 2, 2012 at 11:52 AM, David Cullen David.Cullen@koe-americas.com wrote:
Hello, linaro-dev,
I am trying to follow the instructions at
Hmm those instructions look a bit out of date and I suspect that's why you're having issues. I sure hope your build system doesn't date back to lucid for instance! :-)
I was working with the OMAP3 EVM software from the TI site. Their instructions said that the only platform known to work with their software was Ubuntu 10.04 Desktop 32-bit.
That "should" work fine. What's important for cross assembling your own images is that qemu is reasonably up to date. Lucid is getting fairly old now. Speaking for myself I haven't built anything on lucid for some time.
I can switch to an Ubuntu 12.04 Server VM; but for cross-builds, it shouldn't make much difference.
I think this would be worthwhile looking into.
That said, are you running this native on arm hardware or cross on intel?
I am trying to do a cross-build using the Linaro toolchain.
Ok. One thing to note. When using live build it doesn't actually build the packages, it just assembles images. It uses .debs which are found in all the various archives (including your own) to accomplish this.
If cross, here's what I do : https://wiki.ubuntu.com/TomGall/CrossBuild
It worries me that your instructions are not merged with the Linaro wiki. Is there some good reason for this?
I'm a former Linaro assignee from IBM. The instructions also live here:
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild
(which I also wrote). I don't know if I will get to keep my wiki.linaro.org space yet, but if I do, then I'll keep the master copy on the linaro wiki and copy from my latest draft version to the official wiki as the Linaro.
So that's the reason. It'll get sorted out very soon.
If native steps are pretty much the same. Be careful what directory you start the build in and that you've run the conf_create.sh IE
bzr branch lp:~linaro-maintainers/linaro/live-helper.config.precise.ubuntu-desktop config cp config/conf_create.sh . sh conf_create.sh lb build
Looking at lp:~linaro-maintainers/linaro/live-helper.config.precise.ubuntu-desktop however I don't see much activity so I'm slightly concerned that it might not be up entirely to date. Should be fine but if you run into problems, please post.
I got the link from here:
https://code.launchpad.net/~linaro-maintainers/linaro
But the "Last Modified" date is "2012-01-06" which does not inspire confidence.
Hopefully someone from dev platforms will speak up.
What is the difference between .nano and .developer?
Nano is mean to be a minimal system.
Developer builds on top of that and includes a number of tools for building software. Both Nano and Developer do not include a GUI.
-- Thank you, David Cullen
Hope that helps!
On Mon, Jul 2, 2012 at 8:29 PM, Tom Gall tom.gall@linaro.org wrote:
I have replies inline below, but ultimately, I am really trying to figure out how are the Linaro devs building these files:
http://releases.linaro.org/12.06/ubuntu/leb-panda/
Sure thing. This helps.
Ubuntu LEB are images built out of Ubuntu Launchpad. An image is a 'collection' of ubuntu packages (packages as in .deb). each binary package is built on Launchpad builders, natively on ARM devices. when a developer is *done* with something he would build a source package locally (.dsc + sources) and *push* it into Launchad (either into the main archives if application, or most likely into the Linaro 'overlay' PPA : https://launchpad.net/~linaro-maintainers/+archive/overlay/). Then a builder will build the package locally (you can check the build log on the PPA). typically a source package build on a builder is made of: 1- boot a minimal rootfs (if you build for 12.04, it uses a 12.04 root fs) 2- run apt-get build-dep <the package to build> 3- run dpkg-buildpackage -b 4- archive the generated artifacts (.deb, logs, ..) into PPA
then regularly packages are assembled into images.
Hello, Tom,
On 7/2/2012 2:29 PM, Tom Gall wrote:
That "should" work fine. What's important for cross assembling your own images is that qemu is reasonably up to date. Lucid is getting fairly old now. Speaking for myself I haven't built anything on lucid for some time.
You have a good point about qemu. One of the reasons I created the Ubuntu 12.04 Server VM was to get a newer version of qemu-user-static.
Ok. One thing to note. When using live build it doesn't actually build the packages, it just assembles images. It uses .debs which are found in all the various archives (including your own) to accomplish this.
Well, that's not what I need. I need to rebuild the kernel.
I'm just going to chroot into a copy of the root file system that I got from the image I downloaded from here:
http://www.omappedia.com/wiki/Ubuntu_Pre-Built_Binaries
That way, I can just install the linux-source package, build-essential, and whatever else I need in a self-contained environment.
I originally started looking at the Linaro stuff because the armhf+omap4 Ubuntu image runs very slowly, even after installing the PowerSVG binary driver.
However, when I loaded the 12.05 and 12.06 Linaro Ubuntu images, all I got was a black screen with a mouse pointer.
After running some experiments here, I discovered that the Linaro Ubuntu images only work with displays that have a native resolution of 1920x1080.
I tried to use kernel command line arguments to force the resolution to work with my 1680x1050 monitor, but my changes had no effect. I wanted to look at the kernel source for the Linaro Ubuntu image because I can probably figure out the correct kernel command line arguments from that. However, I could not figure out which git tree to use.
The whole thing reminds me of the line from Zork: "You are in a maze of twisty little passages, all alike."
On 07/03/12 03:47, the mail apparently from David Cullen included:
Hello, Tom,
On 7/2/2012 2:29 PM, Tom Gall wrote:
That "should" work fine. What's important for cross assembling your own images is that qemu is reasonably up to date. Lucid is getting fairly old now. Speaking for myself I haven't built anything on lucid for some time.
You have a good point about qemu. One of the reasons I created the Ubuntu 12.04 Server VM was to get a newer version of qemu-user-static.
Ok. One thing to note. When using live build it doesn't actually build the packages, it just assembles images. It uses .debs which are found in all the various archives (including your own) to accomplish this.
Well, that's not what I need. I need to rebuild the kernel.
I'm just going to chroot into a copy of the root file system that I got from the image I downloaded from here:
http://www.omappedia.com/wiki/Ubuntu_Pre-Built_Binaries
That way, I can just install the linux-source package, build-essential, and whatever else I need in a self-contained environment.
I originally started looking at the Linaro stuff because the armhf+omap4 Ubuntu image runs very slowly, even after installing the PowerSVG binary driver.
However, when I loaded the 12.05 and 12.06 Linaro Ubuntu images, all I got was a black screen with a mouse pointer.
After running some experiments here, I discovered that the Linaro Ubuntu images only work with displays that have a native resolution of 1920x1080.
I tried to use kernel command line arguments to force the resolution to work with my 1680x1050 monitor, but my changes had no effect. I wanted to look at the kernel source for the Linaro Ubuntu image because I can probably figure out the correct kernel command line arguments from that. However, I could not figure out which git tree to use.
The whole thing reminds me of the line from Zork: "You are in a maze of twisty little passages, all alike."
Just to be clear, the kernel is recognizing your monitor and coming up with kms OK at your native resolution?
IIUI Xorg starts and you get a pointer you can move around but Xorg chokes somewhere.
Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal?
If I did get the idea I am not sure recooking the kernel will change much, it's actually doing its side (as distinct from SGX module perhaps) okay from the sound of it.
-Andy
Hello, Andy,
On 7/3/2012 2:14 AM, Andy Green wrote:
On 07/03/12 03:47, the mail apparently from David Cullen included:
After running some experiments here, I discovered that the Linaro Ubuntu images only work with displays that have a native resolution of 1920x1080.
I tried to use kernel command line arguments to force the resolution to work with my 1680x1050 monitor, but my changes had no effect. I wanted to look at the kernel source for the Linaro Ubuntu image because I can probably figure out the correct kernel command line arguments from that. However, I could not figure out which git tree to use.
Just to be clear, the kernel is recognizing your monitor and coming up with kms OK at your native resolution?
What's "kms"? But yes, the kernel appears to be driving the monitor at the native resolution.
IIUI Xorg starts and you get a pointer you can move around but Xorg chokes somewhere.
If Xorg choked, would I even have a mouse pointer?
Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal?
No. I'm not an expert at troubleshooting Xorg problems, so I didn't even think about doing any of that. I'll give it a shot and post my findings.
If I did get the idea I am not sure recooking the kernel will change much, it's actually doing its side (as distinct from SGX module perhaps) okay from the sound of it.
After looking at the kernel source for another project, I was able to figure out how to pass LCD panel timings via the kernel command line to get the resolution I needed. So one reason I wanted to look at the Linaro kernel source was to try to figure out how to force the DVI output to use a specific resolution and bit depth.
However, the image from here
http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-d...
does display the GUI properly on my monitor, so I know it can be done. This raises the question, "What are the differences between the Ubuntu image and the Linaro image?" If the primary difference is the kernel, then rebuilding the kernel may fix the problem.
However, the real reason I need to rebuild the kernel has nothing to do with getting the GUI working. Unfortunately, it is not obvious to me how to acquire the source to the kernel that goes with the image here
http://releases.linaro.org/12.06/ubuntu/leb-panda/
Using apt, I can easily get the source for the Ubuntu image mentioned above. So, I will be sticking with the Ubuntu image for now.
On 03/07/12 22:03, the mail apparently from David Cullen included:
Hello, Andy,
On 7/3/2012 2:14 AM, Andy Green wrote:
On 07/03/12 03:47, the mail apparently from David Cullen included:
After running some experiments here, I discovered that the Linaro Ubuntu images only work with displays that have a native resolution of 1920x1080.
I tried to use kernel command line arguments to force the resolution to work with my 1680x1050 monitor, but my changes had no effect. I wanted to look at the kernel source for the Linaro Ubuntu image because I can probably figure out the correct kernel command line arguments from that. However, I could not figure out which git tree to use.
Just to be clear, the kernel is recognizing your monitor and coming up with kms OK at your native resolution?
What's "kms"? But yes, the kernel appears to be driving the monitor at the native resolution.
Kernel Mode Select.
IIUI Xorg starts and you get a pointer you can move around but Xorg chokes somewhere.
If Xorg choked, would I even have a mouse pointer?
Right what I mean is Xorg + display manager and points south, ie, your "desktop" choked somewhere.
Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal?
No. I'm not an expert at troubleshooting Xorg problems, so I didn't even think about doing any of that. I'll give it a shot and post my findings.
You can often hear about problems in the display manager logs, for gdm it's /var/log/gdm/:0-greeter.log I am not sure what it is on Ubuntu.
If you do start X from the commandline, you will get valuable stderr coming quite deep into the whole desktop startup process.
If I did get the idea I am not sure recooking the kernel will change much, it's actually doing its side (as distinct from SGX module perhaps) okay from the sound of it.
After looking at the kernel source for another project, I was able to figure out how to pass LCD panel timings via the kernel command line to get the resolution I needed. So one reason I wanted to look at the Linaro kernel source was to try to figure out how to force the DVI output to use a specific resolution and bit depth.
However, the image from here
http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-d...
Well that is 12.04, the kernel will be quite different.
does display the GUI properly on my monitor, so I know it can be done. This raises the question, "What are the differences between the Ubuntu image and the Linaro image?" If the primary difference is the kernel, then rebuilding the kernel may fix the problem.
Well, good luck... I think a more certain result will come from finding some evidence from the desktop logs about where it gets stuck.
However, the real reason I need to rebuild the kernel has nothing to do with getting the GUI working. Unfortunately, it is not obvious to me how to acquire the source to the kernel that goes with the image here
http://releases.linaro.org/12.06/ubuntu/leb-panda/
Using apt, I can easily get the source for the Ubuntu image mentioned above. So, I will be sticking with the Ubuntu image for now.
Ubuntu's Panda kernel as the Linaro Ubuntu LEB kernel, is based on our LT kernel here
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
I don't know where they put the exact tree, but they basically set their own config similar to our omap4plus_defconfig and add a bunch of UBUNTU SAUCE patches on top, almost all of which are affecting generic kernel code.
-Andy
Hello, Andy,
On 7/3/2012 9:11 PM, Andy Green wrote:
You can often hear about problems in the display manager logs, for gdm it's /var/log/gdm/:0-greeter.log I am not sure what it is on Ubuntu.
I see this:
root@linaro-ubuntu-desktop:~# cat /var/log/lightdm/x-0.log
X.Org X Server 1.11.3 Release Date: 2011-12-16 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.38-1209-omap4 armv7l Linaro Current Operating System: Linux linaro-ubuntu-desktop 3.4.0-1-linaro-lt-omap #1~120625232503-Ubuntu SMP PREEMPT Tue Jun 26 01:25:56 UTC 2012 armv7l Kernel command line: console=tty0 console=ttyO2,115200n8 root=UUID=0edc8b61-42d7-4434-ab9d-7ae6996efd5e rootwait ro earlyprintk fixrtc nocompcache vram=48M omapfb.vram=0:24M Build Date: 21 June 2012 04:25:29AM xorg-server 2:1.11.4-0ubuntu10.2+ti1.0linaro3 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.24.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul 3 18:02:24 2012 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Failed to load module "pvr" (module does not exist, 0) (EE) Failed to load module "pvr" (module does not exist, 0) (EE) OMAP(1): ERROR: Cannot set the DRM interface version. (EE) OMAP(0): failed to set gamma: Invalid argument (EE) OMAP(0): failed to set gamma: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/omap_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/omap_dri.so: cannot open shared object file: No such file or directory) (EE) AIGLX: reverting to software rendering (EE) OMAP(0): ERROR: get vblank counter failed: Invalid argument (EE) OMAP(0): ERROR: get vblank counter failed: Invalid argument (EE) OMAP(0): ERROR: get vblank counter failed: Invalid argument (EE) OMAP(0): ERROR: get vblank counter failed: Invalid argument (EE) OMAP(0): ERROR: get vblank counter failed: Invalid argument (EE) OMAP(0): failed to set gamma: Invalid argument
That file is the only one that has today's date:
root@linaro-ubuntu-desktop:~# ls -hl /var/log/lightdm/ total 76K -rw------- 1 root root 2.4K Jul 3 18:02 lightdm.log -rw------- 1 root root 13K Jul 9 15:17 x-0.log -rw------- 1 root root 5.6K Jul 3 16:44 x-1-greeter.log -rw------- 1 root root 6.7K Jul 3 15:51 x-1-greeter.log.old -rw------- 1 root root 13K Jul 3 16:44 x-1.log -rw------- 1 root root 5.5K Jul 3 15:52 x-2-greeter.log -rw------- 1 root root 13K Jul 3 15:56 x-2.log
I guess the other files are from my experiments last week.
If you do start X from the commandline, you will get valuable stderr coming quite deep into the whole desktop startup process.
Does anyone know how to keep lightdm from starting during boot without using update-rc.d to delete the symlinks? Ubuntu does not have a multi-user command-line runlevel.
On Mon, Jul 9, 2012 at 5:30 PM, David Cullen David.Cullen@koe-americas.comwrote:
If you do start X from the commandline, you will get valuable stderr coming quite deep into the whole desktop startup process.
Does anyone know how to keep lightdm from starting during boot without using update-rc.d to delete the symlinks? Ubuntu does not have a multi-user command-line runlevel.
adding 'text' in the bootargs should do that.
Hello, Nicholas,
On 7/9/2012 11:42 AM, Dechesne, Nicolas wrote:
On Mon, Jul 9, 2012 at 5:30 PM, David Cullen wrote:
Does anyone know how to keep lightdm from starting during boot without using update-rc.d to delete the symlinks? Ubuntu does not have a multi-user command-line runlevel.
adding 'text' in the bootargs should do that.
On a desktop system that would be an easy way to do it.
Unfortunately, on the PandaBoard, it requires mounting the SD card boot partition on another system, modifying the boot.cmd script, and running mkimage to create a new boot.scr.
I think I will go with the method that is buried in this thread
http://askubuntu.com/questions/19320/whats-the-recommended-way-to-enable-dis...
echo "manual" > /etc/init/lightdm.override
On Mon, Jul 9, 2012 at 6:02 PM, David Cullen David.Cullen@koe-americas.comwrote:
adding 'text' in the bootargs should do that.
On a desktop system that would be an easy way to do it.
Unfortunately, on the PandaBoard, it requires mounting the SD card boot partition on another system, modifying the boot.cmd script, and running mkimage to create a new boot.scr.
I think I will go with the method that is buried in this thread
nope, that easy on a pandaboard too ;-)
1- boot your panda 2- edit /boot/boot.script and change the bootargs 3- run sudo flash-kernel 4- reboot
the flash-kernel command will regenerate the boot.scr and place it in the BOOT partition.
Hello, Nicolas,
On 7/9/2012 12:05 PM, Dechesne, Nicolas wrote:
On Mon, Jul 9, 2012 at 6:02 PM, David Cullen wrote:
On a desktop system that would be an easy way to do it. Unfortunately, on the PandaBoard, it requires mounting the SD card boot partition on another system, modifying the boot.cmd script, and running mkimage to create a new boot.scr. I think I will go with the method that is buried in this thread
nope, that easy on a pandaboard too ;-)
1- boot your panda 2- edit /boot/boot.script and change the bootargs 3- run sudo flash-kernel 4- reboot
the flash-kernel command will regenerate the boot.scr and place it in the BOOT partition.
I guess I didn't consider that option because I had to modify the "flash-kernel" script in the Ubuntu supplied image because it looks for "omap4" as the sub-architecture and the Linaro kernel ends with "omap".
Also, 'echo "manual" > /etc/init/lightdm.override' is a one-liner and will work for other services, so I needed to know how to do it anyway.
Speaking of the "flash-kernel" script, where would I file a bug about not being able to install a Linaro kernel without modifying the script? Do I use this same link:
https://bugs.launchpad.net/linaro-ubuntu/+filebug
Hello, Andy,
On 7/3/2012 2:14 AM, Andy Green wrote:
Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal?
Here's a link to the Xorg.0.log:
I'm afraid I don't know how to interpret it.
I stopped lightdm using
# service lightdm stop
and then ran "startx", but the result was the same.
I didn't mess with the run levels because Ubuntu doesn't have a multi-user non-gui run level.
Hi David,
I looked at your log. I agree with Andy, this is probably not a rebuild the kernel kind of situation.
Does the log really cut off at 1239 lines or is there more?
Thanks! Tom
On Tue, Jul 3, 2012 at 9:51 AM, David Cullen David.Cullen@koe-americas.com wrote:
Hello, Andy,
On 7/3/2012 2:14 AM, Andy Green wrote:
Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal?
Here's a link to the Xorg.0.log:
I'm afraid I don't know how to interpret it.
I stopped lightdm using
# service lightdm stop
and then ran "startx", but the result was the same.
I didn't mess with the run levels because Ubuntu doesn't have a multi-user non-gui run level.
-- Thank you, David Cullen
Hello, Tom,
On 7/3/2012 11:16 AM, Tom Gall wrote:
I looked at your log. I agree with Andy, this is probably not a rebuild the kernel kind of situation.
Ok. But that begs the question, "What else is different between the Linaro image and the Ubuntu image?"
Does the log really cut off at 1239 lines or is there more?
Yes, it stops there. Do you think something crashed?