Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
I installed all dependencies mentioned in the README and tried to run linaro-media-create like below:
sudo ./linaro-media-create --rootfs ext3 --mmc /dev/sdb1 --binary /home/a0393566local/linaro/headless/linaro-natty-headless- tar-20110206-0.tar.gz --hwpack /home/a0393566local/linaro/hwpack /hwpack_linaro-panda_20110206-0_armel_supported.tar.gz --dev panda
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
Any idea what could be going wrong?
Thanks, Aneesh
On Mon, Feb 7, 2011 at 8:25 AM, Aneesh V aneesh@ti.com wrote:
Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
Hi Aneesh, this is a known problem. For the moment, if you are not using natty, the easiest workround is to simply upgrade to the version of qemu-kvm-extras-static in natty.
Thanks, Paul Larson
On 7 February 2011 14:25, Aneesh V aneesh@ti.com wrote:
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
[qemu: fatal: cp15 insn ee1d6f70]
You need a newer qemu (specifically a /usr/bin/qemu-system-arm which is upstream 0.13 or better). Natty's qemu-kvm-extras-static version 0.13.0+noroms-0ubuntu12 will do.
-- PMM
Hi Aneesh,
Do you have the latest qemu-user-static from https://launchpad.net/~linaro-maintainers/+archive/tools ?
On Mon, 2011-02-07 at 19:55 +0530, Aneesh V wrote:
Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
I installed all dependencies mentioned in the README and tried to run linaro-media-create like below:
sudo ./linaro-media-create --rootfs ext3 --mmc /dev/sdb1 --binary /home/a0393566local/linaro/headless/linaro-natty-headless- tar-20110206-0.tar.gz --hwpack /home/a0393566local/linaro/hwpack /hwpack_linaro-panda_20110206-0_armel_supported.tar.gz --dev panda
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Thoughts?
On Mon, Feb 7, 2011 at 3:33 PM, Guilherme Salgado guilherme.salgado@linaro.org wrote:
Hi Aneesh,
Do you have the latest qemu-user-static from https://launchpad.net/~linaro-maintainers/+archive/tools ?
On Mon, 2011-02-07 at 19:55 +0530, Aneesh V wrote:
Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
I installed all dependencies mentioned in the README and tried to run linaro-media-create like below:
sudo ./linaro-media-create --rootfs ext3 --mmc /dev/sdb1 --binary /home/a0393566local/linaro/headless/linaro-natty-headless- tar-20110206-0.tar.gz --hwpack /home/a0393566local/linaro/hwpack /hwpack_linaro-panda_20110206-0_armel_supported.tar.gz --dev panda
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
-- Guilherme Salgado https://launchpad.net/~salgado
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
In lmc we already have some code which checks if a given utility is present and if not, install (via apt-get) a package which provides that. We could extend it to check for a specific version and try to install a version greater or equal that (can we tell apt-get to install only if it finds a package whose version is greater than X?).
When it fails to install, we would direct the user to the README, which has pointers for the things that are not available in the usual channels.
On Mon, 2011-02-07 at 15:59 +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Thoughts?
On Mon, Feb 7, 2011 at 3:33 PM, Guilherme Salgado guilherme.salgado@linaro.org wrote:
Hi Aneesh,
Do you have the latest qemu-user-static from https://launchpad.net/~linaro-maintainers/+archive/tools ?
On Mon, 2011-02-07 at 19:55 +0530, Aneesh V wrote:
Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
I installed all dependencies mentioned in the README and tried to run linaro-media-create like below:
sudo ./linaro-media-create --rootfs ext3 --mmc /dev/sdb1 --binary /home/a0393566local/linaro/headless/linaro-natty-headless- tar-20110206-0.tar.gz --hwpack /home/a0393566local/linaro/hwpack /hwpack_linaro-panda_20110206-0_armel_supported.tar.gz --dev panda
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
-- Guilherme Salgado https://launchpad.net/~salgado
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, Feb 8, 2011 at 5:50 AM, Guilherme Salgado guilherme.salgado@linaro.org wrote:
In lmc we already have some code which checks if a given utility is present and if not, install (via apt-get) a package which provides that.
(I don't like that - am I prompted first? A script shouldn't be allowed to install packages on my machine)
We could extend it to check for a specific version and try to install a version greater or equal that (can we tell apt-get to install only if it finds a package whose version is greater than X?).
I ran into the same CP15 problem a few days ago and was left with a l-m-c that was stuck waiting for QEMU. It wasn't obvious what to do next. I like the idea of an explicit version check but you will need to tie the l-m-c, qemu, and hwpack versions together.
-- Michael
On Tue, Feb 08, 2011, Michael Hope wrote:
(I don't like that - am I prompted first? A script shouldn't be allowed to install packages on my machine)
I don't like it either; that's already reported: https://bugs.launchpad.net/linaro-image-tools/+bug/704029
On Tue, 2011-02-08 at 08:14 +1300, Michael Hope wrote:
On Tue, Feb 8, 2011 at 5:50 AM, Guilherme Salgado guilherme.salgado@linaro.org wrote:
In lmc we already have some code which checks if a given utility is present and if not, install (via apt-get) a package which provides that.
(I don't like that - am I prompted first? A script shouldn't be allowed to install packages on my machine)
Right now it may install stuff automatically, but we plan to have it do so only with the user's consent: https://bugs.launchpad.net/linaro-image-tools/+bug/704029
We could extend it to check for a specific version and try to install a version greater or equal that (can we tell apt-get to install only if it finds a package whose version is greater than X?).
I ran into the same CP15 problem a few days ago and was left with a l-m-c that was stuck waiting for QEMU. It wasn't obvious what to do next. I like the idea of an explicit version check but you will need to tie the l-m-c, qemu, and hwpack versions together.
-- Michael
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed wasn't running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
Until we can work out how best to include static binaries in tarball releases, I think the fallback is to provide instructions on how to build the needed components from the qemu-linaro tarball releases.
Cheers,
Hi Steve,
On Monday 07 February 2011 11:07 PM, Steve Langasek wrote:
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed wasn't running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
I am running Ubuntu Maverick on my desktop. However apt-get didn't work for linaro-image-tools. I got this message:
E: Couldn't find package linaro-image-tools
So, I downloaded it from launchpad as mentioned in the wiki.
Best regards, Aneesh
Hi Aneesh,
On Tue, Feb 08, 2011 at 05:43:39PM +0530, Aneesh V wrote:
On Monday 07 February 2011 11:07 PM, Steve Langasek wrote:
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed wasn't running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
I am running Ubuntu Maverick on my desktop. However apt-get didn't work for linaro-image-tools. I got this message:
E: Couldn't find package linaro-image-tools
So, I downloaded it from launchpad as mentioned in the wiki.
Ok. Which wiki page did you look at? We should be directing maverick users to enable the linaro-maintainers/tools ppa, which includes both the linaro-image-tools and qemu-linaro packages.
https://wiki.linaro.org/Releases/DailyBuilds#On%20Ubuntu%2010.10
Is there another wiki page with conflicting instructions that we need to clean up? Or did you read this and go for the download instead of the ppa (in which case we should clarify the text to direct people to the ppa more strongly)?
Thanks,
On 9 February 2011 04:16, Steve Langasek steve.langasek@linaro.org wrote:
Hi Aneesh,
On Tue, Feb 08, 2011 at 05:43:39PM +0530, Aneesh V wrote:
On Monday 07 February 2011 11:07 PM, Steve Langasek wrote:
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed
wasn't
running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
I am running Ubuntu Maverick on my desktop. However apt-get didn't work for linaro-image-tools. I got this message:
E: Couldn't find package linaro-image-tools
So, I downloaded it from launchpad as mentioned in the wiki.
Ok. Which wiki page did you look at? We should be directing maverick users to enable the linaro-maintainers/tools ppa, which includes both the linaro-image-tools and qemu-linaro packages.
I can find linaro-image-tools, but no qemu-linaro on maverick, and I added PPA.
https://wiki.linaro.org/Releases/DailyBuilds#On%20Ubuntu%2010.10
Is there another wiki page with conflicting instructions that we need to clean up? Or did you read this and go for the download instead of the ppa (in which case we should clarify the text to direct people to the ppa more strongly)?
Thanks,
Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIVAwUBTVGkqlaNMPMhshM9AQgvkRAArRamc/hlkcFzghRMQvELQAwSC4/SdtVx umM3CfYPwzw3iQdx20ay2ogRzrRttjac22wvEFCO+a3Jqvv/57tTYge9z27Fqrk2 +oyK7/2tXKcPd0P5u3CMxkSSXSMdgB2C3sShrl/Bwlfy+PGF2G09+nier3C3cVm7 g0+nTbQpeKRveqYRr89oJtIYtscmdb/GZDMg9uGWeCHX9N37ZJBL+/mXi9OmAGkx YXIq/1o6fpEWNjZ5a+ulgnyOfFk99kyfjMrBgEpgBb4oompzghMXHmaII9Gd2Tgd WCV7Go8z/gzagn/voHiOFlabyRr+ea0VAKRDkBKMx8Kb5H4mBJSiruw7VdRv0JWA 6nKao+IZcbIa2KI9j9zratygy4PaeHUKwKkUDyRyHbB6F1orNjRNScNZQOy53wg+ i9CUI0m5z5ctc664VKU/xRS82mPBA5BP/ZFx2MS4K1ossopBH4EZ/Z9gR/kbyeea YY2Ut37+5XW8e7oK89COvfYgDBSTjwF88mzCSkl99UhGSNk7sN57dAp5xUBD3u6D e8LgH9KvUW7SY9TX80iy/RKwEIN83ng+8qBuXMJXw6HHdSBjReWMGq4zUwNr7L6g 1bjwL1YDmfxV3P5QSDKch0ITRMpHs77vbwsCSoEUP3SkJHlqypkeURcyaHTEDGTZ ZIT3wkXavTU= =167/ -----END PGP SIGNATURE-----
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, Mar 4, 2011 at 8:09 AM, Spring Zhang spring.zhang@linaro.org wrote:
On 9 February 2011 04:16, Steve Langasek steve.langasek@linaro.org wrote:
Hi Aneesh,
On Tue, Feb 08, 2011 at 05:43:39PM +0530, Aneesh V wrote:
On Monday 07 February 2011 11:07 PM, Steve Langasek wrote:
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed wasn't running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
I am running Ubuntu Maverick on my desktop. However apt-get didn't work for linaro-image-tools. I got this message:
E: Couldn't find package linaro-image-tools
So, I downloaded it from launchpad as mentioned in the wiki.
Ok. Which wiki page did you look at? We should be directing maverick users to enable the linaro-maintainers/tools ppa, which includes both the linaro-image-tools and qemu-linaro packages.
I can find linaro-image-tools, but no qemu-linaro on maverick, and I added PPA.
https://wiki.linaro.org/Releases/DailyBuilds#On%20Ubuntu%2010.10
Is there another wiki page with conflicting instructions that we need to clean up? Or did you read this and go for the download instead of the ppa (in which case we should clarify the text to direct people to the ppa more strongly)?
Adding the PPA should achieve the necessary thing.
qemu-linaro is the name of the source package: the generated binary packages you need are called qemu-kvm (from the main archive) and qemu-user-static (from the PPA). However, the dependencies for linaro-image-tools should pull these in automatically.
What's the exact problem you're seeing when trying to install?
What output do you get from apt-cache policy linaro-image-tools ?
Cheers ---Dave
Hello Dave,
On Fri, Mar 04, 2011 at 12:03:51PM +0000, Dave Martin wrote:
On Fri, Mar 4, 2011 at 8:09 AM, Spring Zhang spring.zhang@linaro.org wrote:
On 9 February 2011 04:16, Steve Langasek steve.langasek@linaro.org wrote:
Hi Aneesh,
On Tue, Feb 08, 2011 at 05:43:39PM +0530, Aneesh V wrote:
On Monday 07 February 2011 11:07 PM, Steve Langasek wrote:
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed wasn't running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
I am running Ubuntu Maverick on my desktop. However apt-get didn't work for linaro-image-tools. I got this message:
E: Couldn't find package linaro-image-tools
So, I downloaded it from launchpad as mentioned in the wiki.
Ok. Which wiki page did you look at? We should be directing maverick users to enable the linaro-maintainers/tools ppa, which includes both the linaro-image-tools and qemu-linaro packages.
I can find linaro-image-tools, but no qemu-linaro on maverick, and I added PPA.
https://wiki.linaro.org/Releases/DailyBuilds#On%20Ubuntu%2010.10
Is there another wiki page with conflicting instructions that we need to clean up? Or did you read this and go for the download instead of the ppa (in which case we should clarify the text to direct people to the ppa more strongly)?
Adding the PPA should achieve the necessary thing.
qemu-linaro is the name of the source package: the generated binary packages you need are called qemu-kvm (from the main archive) and qemu-user-static (from the PPA). However, the dependencies for linaro-image-tools should pull these in automatically.
What's the exact problem you're seeing when trying to install?
I'm not sure what the Spring's is, but here is mine.
$ linaro-media-create --rootfs ext3 --mmc /dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk Traceback (most recent call last): File "/usr/bin/linaro-media-create", line 109, in <module> if not confirm_device_selection_and_ensure_it_is_ready(args.device): File "/usr/lib/pymodules/python2.6/linaro_media_create/check_device.py", line 122, in confirm_device_selection_and_ensure_it_is_ready if _does_device_exist(device): File "/usr/lib/pymodules/python2.6/linaro_media_create/check_device.py", line 58, in _does_device_exist bus, udisks = _get_system_bus_and_udisks_iface() File "/usr/lib/pymodules/python2.6/linaro_media_create/check_device.py", line 34, in _get_system_bus_and_udisks_iface bus.get_object("org.freedesktop.UDisks", "/org/freedesktop/UDisks"), File "/usr/lib/pymodules/python2.6/dbus/bus.py", line 244, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 241, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/pymodules/python2.6/dbus/bus.py", line 183, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/pymodules/python2.6/dbus/bus.py", line 281, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UDisks was not provided by any .service files
What output do you get from apt-cache policy linaro-image-tools ?
$ apt-cache policy linaro-image-tools linaro-image-tools: Installed: 0.4.3-0ubuntu2~linaro1 Candidate: 0.4.3-0ubuntu2~linaro1 Version table: *** 0.4.3-0ubuntu2~linaro1 0 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status 0.3 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick-updates/universe amd64 Packages 0.2 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
And I'm running Maverick server edition on a 'AMD Athlon(tm) 64 X2 Dual Core Processor 3800+'.
On Sun, Mar 6, 2011 at 1:51 PM, Shawn Guo shawn.guo@freescale.com wrote:
Hello Dave,
On Fri, Mar 04, 2011 at 12:03:51PM +0000, Dave Martin wrote:
On Fri, Mar 4, 2011 at 8:09 AM, Spring Zhang spring.zhang@linaro.org wrote:
On 9 February 2011 04:16, Steve Langasek steve.langasek@linaro.org wrote:
Hi Aneesh,
On Tue, Feb 08, 2011 at 05:43:39PM +0530, Aneesh V wrote:
On Monday 07 February 2011 11:07 PM, Steve Langasek wrote:
On Mon, Feb 07, 2011 at 03:59:06PM +0100, Alexander Sack wrote: >Since we only really support developer platform hosts with the tools >ppa enabled, could we improve l-m-c to print a warning if that ppa >isn't enabled?
>The other idea I had was to include the working qemu-arm-static in >the tarball releases ... in that way things might even work on >non-ubuntu platform.
Well, given that Aneesh's original message mentioned he was downloading l-i-t directly from launchpad, my first thought was that he indeed wasn't running Ubuntu on the desktop. Aneesh, was this the case? What are you running on your desktop (distro, version)?
I am running Ubuntu Maverick on my desktop. However apt-get didn't work for linaro-image-tools. I got this message:
E: Couldn't find package linaro-image-tools
So, I downloaded it from launchpad as mentioned in the wiki.
Ok. Which wiki page did you look at? We should be directing maverick users to enable the linaro-maintainers/tools ppa, which includes both the linaro-image-tools and qemu-linaro packages.
I can find linaro-image-tools, but no qemu-linaro on maverick, and I added PPA.
https://wiki.linaro.org/Releases/DailyBuilds#On%20Ubuntu%2010.10
Is there another wiki page with conflicting instructions that we need to clean up? Or did you read this and go for the download instead of the ppa (in which case we should clarify the text to direct people to the ppa more strongly)?
Adding the PPA should achieve the necessary thing.
qemu-linaro is the name of the source package: the generated binary packages you need are called qemu-kvm (from the main archive) and qemu-user-static (from the PPA). However, the dependencies for linaro-image-tools should pull these in automatically.
What's the exact problem you're seeing when trying to install?
I'm not sure what the Spring's is, but here is mine.
$ linaro-media-create --rootfs ext3 --mmc /dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk Traceback (most recent call last): File "/usr/bin/linaro-media-create", line 109, in <module> if not confirm_device_selection_and_ensure_it_is_ready(args.device): File "/usr/lib/pymodules/python2.6/linaro_media_create/check_device.py", line 122, in confirm_device_selection_and_ensure_it_is_ready if _does_device_exist(device): File "/usr/lib/pymodules/python2.6/linaro_media_create/check_device.py", line 58, in _does_device_exist bus, udisks = _get_system_bus_and_udisks_iface() File "/usr/lib/pymodules/python2.6/linaro_media_create/check_device.py", line 34, in _get_system_bus_and_udisks_iface bus.get_object("org.freedesktop.UDisks", "/org/freedesktop/UDisks"), File "/usr/lib/pymodules/python2.6/dbus/bus.py", line 244, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 241, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/pymodules/python2.6/dbus/bus.py", line 183, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/pymodules/python2.6/dbus/bus.py", line 281, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UDisks was not provided by any .service files
What output do you get from apt-cache policy linaro-image-tools ?
$ apt-cache policy linaro-image-tools linaro-image-tools: Installed: 0.4.3-0ubuntu2~linaro1 Candidate: 0.4.3-0ubuntu2~linaro1 Version table: *** 0.4.3-0ubuntu2~linaro1 0 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status 0.3 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick-updates/universe amd64 Packages 0.2 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
And I'm running Maverick server edition on a 'AMD Athlon(tm) 64 X2 Dual Core Processor 3800+'.
It looks like you have the correct linaro-image-tools installed.
Do you have udisks installed though? The error messages suggest it might not be there--- that could be the problem. Let us know if that fixes the problem for you; it implies a missing entry in the package dependencies list if so.
Cheers ---Dave
On Mon, Mar 07, 2011 at 10:34:52AM +0000, Dave Martin wrote:
On Sun, Mar 6, 2011 at 1:51 PM, Shawn Guo shawn.guo@freescale.com wrote:
Hello Dave,
[...]
And I'm running Maverick server edition on a 'AMD Athlon(tm) 64 X2 Dual Core Processor 3800+'.
It looks like you have the correct linaro-image-tools installed.
Do you have udisks installed though? The error messages suggest it might not be there--- that could be the problem. Let us know if that fixes the problem for you; it implies a missing entry in the package dependencies list if so.
Thanks, Dave. Installing udisks helps. But now, it ends up with other problem. Here is the full log. (Sorry for the long paste)
$ linaro-media-create --rootfs ext3 --mmc /dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk
I see... Device Mount point Size /dev/sda5 none 76048MB /dev/dm-0 / 72868MB /dev/dm-1 none 3136MB /dev/sda none 76293MB /dev/sda1 /boot 243MB /dev/sda2 none 76048MB /dev/sr0 none 0MB /dev/sdb none 3781MB Are you 100% sure, on selecting [/dev/sdb] (y/n)? y ------------------------------------------------------------ Installing (apt-get) hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz in target rootfs. Unpacking hardware pack ...Done qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 Updating apt package lists ... qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Ign file: ./ Translation-en Ign http://ports.ubuntu.com natty InRelease Ign http://ports.ubuntu.com natty-security InRelease Ign http://ports.ubuntu.com natty-updates InRelease Ign http://ports.ubuntu.com natty-security InRelease Ign http://ports.ubuntu.com natty InRelease Ign http://ports.ubuntu.com natty-updates InRelease Get:1 http://ports.ubuntu.com natty Release.gpg [198 B] Hit http://ports.ubuntu.com natty-security Release.gpg Hit http://ports.ubuntu.com natty-updates Release.gpg Get:2 http://ports.ubuntu.com natty-security Release.gpg [198 B] Get:3 http://ports.ubuntu.com natty Release.gpg [198 B] Get:4 http://ports.ubuntu.com natty-updates Release.gpg [198 B] Get:5 http://ports.ubuntu.com natty Release [39.8 kB] Ign http://ppa.launchpad.net natty InRelease Ign http://ppa.launchpad.net natty InRelease Get:6 http://ppa.launchpad.net natty Release.gpg [316 B] Hit http://ppa.launchpad.net natty Release.gpg Hit http://ports.ubuntu.com natty-security Release Hit http://ports.ubuntu.com natty-updates Release Get:7 http://ports.ubuntu.com natty-security Release [23.2 kB] Get:8 http://ppa.launchpad.net natty Release [9751 B] Get:9 http://ports.ubuntu.com natty Release [39.8 kB] Hit http://ppa.launchpad.net natty Release Get:10 http://ppa.launchpad.net natty/main armel Packages [2832 B] Ign http://ppa.launchpad.net natty/main TranslationIndex Hit http://ppa.launchpad.net natty/main armel Packages Ign http://ppa.launchpad.net natty/main TranslationIndex Get:11 http://ports.ubuntu.com natty-updates Release [23.2 kB] Get:12 http://ports.ubuntu.com natty/main armel Packages [1540 kB] Ign http://ppa.launchpad.net natty/main Translation-en Ign http://ppa.launchpad.net natty/main Translation-en Get:13 http://ports.ubuntu.com natty/universe armel Packages [5875 kB] Ign http://ports.ubuntu.com natty/main TranslationIndex Ign http://ports.ubuntu.com natty/universe TranslationIndex Hit http://ports.ubuntu.com natty-security/main armel Packages Hit http://ports.ubuntu.com natty-security/universe armel Packages Ign http://ports.ubuntu.com natty-security/main TranslationIndex Ign http://ports.ubuntu.com natty-security/universe TranslationIndex Hit http://ports.ubuntu.com natty-updates/main armel Packages Hit http://ports.ubuntu.com natty-updates/universe armel Packages Ign http://ports.ubuntu.com natty-updates/main TranslationIndex Ign http://ports.ubuntu.com natty-updates/universe TranslationIndex Get:14 http://ports.ubuntu.com natty-security/main armel Packages [14 B] Get:15 http://ports.ubuntu.com natty-security/universe armel Packages [14 B] Ign http://ports.ubuntu.com natty-security/main TranslationIndex Ign http://ports.ubuntu.com natty-security/universe TranslationIndex Get:16 http://ports.ubuntu.com natty/main armel Packages [1540 kB] Get:17 http://ports.ubuntu.com natty/universe armel Packages [5875 kB] Ign http://ports.ubuntu.com natty/main TranslationIndex Ign http://ports.ubuntu.com natty/universe TranslationIndex Get:18 http://ports.ubuntu.com natty-updates/main armel Packages [14 B] Get:19 http://ports.ubuntu.com natty-updates/universe armel Packages [14 B] Ign http://ports.ubuntu.com natty-updates/main TranslationIndex Ign http://ports.ubuntu.com natty-updates/universe TranslationIndex Ign http://ports.ubuntu.com natty/main Translation-en Ign http://ports.ubuntu.com natty/universe Translation-en Ign http://ports.ubuntu.com natty-security/main Translation-en Ign http://ports.ubuntu.com natty-security/universe Translation-en Ign http://ports.ubuntu.com natty-updates/main Translation-en Ign http://ports.ubuntu.com natty-updates/universe Translation-en Ign http://ports.ubuntu.com natty-security/main Translation-en Ign http://ports.ubuntu.com natty-security/universe Translation-en Ign http://ports.ubuntu.com natty/main Translation-en Ign http://ports.ubuntu.com natty/universe Translation-en Ign http://ports.ubuntu.com natty-updates/main Translation-en Ign http://ports.ubuntu.com natty-updates/universe Translation-en Fetched 15.0 MB in 7min 10s (34.7 kB/s) Reading package lists... Installing packages ...qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: devio flash-kernel linux-firmware linux-image-2.6.38-1000-linaro-mx51 linux-image-linaro-mx51 u-boot-linaro-mx51evk u-boot-tools uboot-mkimage wireless-crda 0 upgraded, 9 newly installed, 0 to remove and 16 not upgraded. Need to get 0 B/21.6 MB of archives. After this operation, 0 B of additional disk space will be used. WARNING: The following packages cannot be authenticated! wireless-crda linux-image-2.6.38-1000-linaro-mx51 devio flash-kernel linux-firmware linux-image-linaro-mx51 u-boot-linaro-mx51evk u-boot-tools uboot-mkimage Install these packages without verification [y/N]? y debconf: delaying package configuration, since apt-utils is not installed Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously deselected package wireless-crda. (Reading database ... 16235 files and directories currently installed.) Unpacking wireless-crda (from .../wireless-crda_1.13_armel.deb) ... Selecting previously deselected package linux-image-2.6.38-1000-linaro-mx51. Unpacking linux-image-2.6.38-1000-linaro-mx51 (from .../linux-image-2.6.38-1000-linaro-mx51_2.6.38-1000.1_armel.deb) ... Done. Selecting previously deselected package devio. Unpacking devio (from .../devio_1.2-1build1_armel.deb) ... Selecting previously deselected package flash-kernel. Unpacking flash-kernel (from .../flash-kernel_2.28ubuntu15_armel.deb) ... Selecting previously deselected package linux-firmware. Unpacking linux-firmware (from .../linux-firmware_1.47_all.deb) ... Selecting previously deselected package linux-image-linaro-mx51. Unpacking linux-image-linaro-mx51 (from .../linux-image-linaro-mx51_2.6.38.1000.1_armel.deb) ... Selecting previously deselected package u-boot-linaro-mx51evk. Unpacking u-boot-linaro-mx51evk (from .../u-boot-linaro-mx51evk_2011.02.1-0ubuntu1_armel.deb) ... Selecting previously deselected package u-boot-tools. Unpacking u-boot-tools (from .../u-boot-tools_2010.12-2_armel.deb) ... Selecting previously deselected package uboot-mkimage. Unpacking uboot-mkimage (from .../uboot-mkimage_2010.12-2_all.deb) ... Can not write log, openpty() failed (/dev/pts not mounted?) Setting up wireless-crda (1.13) ... Setting up linux-image-2.6.38-1000-linaro-mx51 (2.6.38-1000.1) ... Running depmod. update-initramfs: Generating /boot/initrd.img-2.6.38-1000-linaro-mx51 /bin/df: Warning: cannot read table of mounted file systems: No such file or directory Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.38-1000-linaro-mx51 /boot/vmlinuz-2.6.38-1000-linaro-mx51 Setting up devio (1.2-1build1) ... Setting up flash-kernel (2.28ubuntu15) ... Setting up linux-firmware (1.47) ... Setting up linux-image-linaro-mx51 (2.6.38.1000.1) ... Setting up u-boot-linaro-mx51evk (2011.02.1-0ubuntu1) ... Setting up u-boot-tools (2010.12-2) ... Setting up uboot-mkimage (2010.12-2) ... Done Cleaning up ...qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 qemu: Unsupported syscall: 369 Done ------------------------------------------------------------ proc umounted /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write Traceback (most recent call last): File "/usr/bin/linaro-media-create", line 127, in <module> args.should_format_rootfs) File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 71, in setup_partitions board_config, media, HEADS, SECTORS, cylinders) File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 310, in create_partitions run_sfdisk_commands(sfdisk_cmd, heads, sectors, cylinders, media.path) File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 288, in run_sfdisk_commands return proc.communicate("%s\n" % commands) File "/usr/lib/python2.6/subprocess.py", line 691, in communicate return self._communicate(input) File "/usr/lib/python2.6/subprocess.py", line 1258, in _communicate self.wait() File "/usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py", line 65, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', 'sfdisk', '-D', '-H', '255', '-S', '63', '/dev/sdb']" returned a non-zero value: 1
On 7 March 2011 12:43, Shawn Guo shawn.guo@freescale.com wrote:
Thanks, Dave. Installing udisks helps. But now, it ends up with other problem. Here is the full log. (Sorry for the long paste)
$ linaro-media-create --rootfs ext3 --mmc /dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk
qemu: Unsupported syscall: 369
These qemu warnings are harmless, by the way: https://bugs.launchpad.net/qemu-linaro/+bug/728630 (qemu-linaro 2011.03, due for release tomorrow, will include a patch which silences them.) They're not related to your actual problem.
-- PMM
On Mon, Mar 07, 2011, Shawn Guo wrote:
proc umounted /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write
Hmm that's really bad; the only thing that I can think of is that your device goes away for some time after the empty partition table is created, and so the sfdisk call comes too soon; could you try this on your MMC: parted -s /dev/sdN mklabel msdos && sfdisk -L /dev/sdN if sfdisk fails when called immediately after parted, it probably means we have to poll for readyness of /dev/sdN before calling sfdisk.
Thanks!
This will most lokalu not help. Try my hacking branch of linaro-image-tools. I had the same problem as you and I added a workaround.
Sorry for the brevity, I'm on holiday + phone
Wysłane z iPhone'a
Dnia 07-03-2011 o godz. 14:03 Loïc Minier loic.minier@linaro.org napisał(a):
On Mon, Mar 07, 2011, Shawn Guo wrote:
proc umounted /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write
Hmm that's really bad; the only thing that I can think of is that your device goes away for some time after the empty partition table is created, and so the sfdisk call comes too soon; could you try this on your MMC: parted -s /dev/sdN mklabel msdos && sfdisk -L /dev/sdN if sfdisk fails when called immediately after parted, it probably means we have to poll for readyness of /dev/sdN before calling sfdisk.
Thanks!
Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi Zygmunt,
On Mon, Mar 07, 2011 at 02:19:41PM +0100, Zygmunt Bazyli Krynicki wrote:
This will most lokalu not help. Try my hacking branch of linaro-image-tools. I had the same problem as you and I added a workaround.
Thanks. But using your branch make it fail at some other place.
--- quote begin --- [...] Ign http://ports.ubuntu.com natty/main Translation-en Ign http://ports.ubuntu.com natty/universe Translation-en Ign http://ports.ubuntu.com natty-updates/main Translation-en Ign http://ports.ubuntu.com natty-updates/universe Translation-en Fetched 15.0 MB in 10min 34s (23.6 kB/s) W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_natty_universe_binary-armel_Packages Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead. Cleaning up ...Done [sudo] password for r65073: proc umounted Traceback (most recent call last): File "/home/r65073/repos/linaro/lmc/hacking/linaro-media-create", line 128, in <module> ROOTFS_DIR, TMP_DIR, lmc_dir, args.hwpack_force_yes, *hwpacks) File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/hwpack.py", line 58, in install_hwpacks install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes) File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/hwpack.py", line 78, in install_hwpack cmd_runner.run(args, as_root=True).wait() File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/cmd_runner.py", line 65, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', 'chroot', '/tmp/tmp6xLw4j/binary', 'linaro-hwpack-install', '/hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz']" returned a non-zero value: 100 --- quote end ---
On Tue, Mar 08, 2011 at 03:10:56PM +0800, Shawn Guo wrote:
Hi Zygmunt,
On Mon, Mar 07, 2011 at 02:19:41PM +0100, Zygmunt Bazyli Krynicki wrote:
This will most lokalu not help. Try my hacking branch of linaro-image-tools. I had the same problem as you and I added a workaround.
Thanks. But using your branch make it fail at some other place.
--- quote begin --- [...] Ign http://ports.ubuntu.com natty/main Translation-en Ign http://ports.ubuntu.com natty/universe Translation-en Ign http://ports.ubuntu.com natty-updates/main Translation-en Ign http://ports.ubuntu.com natty-updates/universe Translation-en Fetched 15.0 MB in 10min 34s (23.6 kB/s) W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_natty_universe_binary-armel_Packages Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead. Cleaning up ...Done [sudo] password for r65073: proc umounted Traceback (most recent call last): File "/home/r65073/repos/linaro/lmc/hacking/linaro-media-create", line 128, in <module> ROOTFS_DIR, TMP_DIR, lmc_dir, args.hwpack_force_yes, *hwpacks) File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/hwpack.py", line 58, in install_hwpacks install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes) File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/hwpack.py", line 78, in install_hwpack cmd_runner.run(args, as_root=True).wait() File "/home/r65073/repos/linaro/lmc/hacking/linaro_media_create/cmd_runner.py", line 65, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', 'chroot', '/tmp/tmp6xLw4j/binary', 'linaro-hwpack-install', '/hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz']" returned a non-zero value: 100 --- quote end ---
By looking the workaround on the hacking branch, I changed the sleep(1) to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py, and almost made it, but sadly it still fails at the last step.
--- quote begin --- proc umounted Checking that no-one is using this disk right now ... OK If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).)
Formating boot partition
mkfs.vfat 3.0.9 (31 Jan 2010)
Formating root partition
mke2fs 1.41.12 (17-May-2010) Filesystem label=rootfs OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 237104 inodes, 947835 blocks 47391 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=973078528 29 block groups 32768 blocks per group, 32768 fragments per group 8176 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 24 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. 162+1 records in 162+1 records out 166624 bytes (167 kB) copied, 0.0412763 s, 4.0 MB/s mkimage: Write error on /tmp/tmpXkyS2N/boot-disc/uImage: Success Traceback (most recent call last): File "/usr/bin/linaro-media-create", line 134, in <module> args.device, args.is_live, args.is_lowmem, args.consoles) File "/usr/lib/pymodules/python2.6/linaro_media_create/populate_boot.py", line 57, in populate_boot boot_disk, boot_script, boot_device_or_file) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 118, in make_boot_files boot_device_or_file) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 312, in _make_boot_files cls.load_addr, uboot_parts_dir, cls.kernel_suffix, boot_dir) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 389, in make_uImage 'kernel', load_addr, load_addr, 'Linux', img_data, img) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 363, in _run_mkimage proc.wait() File "/usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py", line 65, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', 'mkimage', '-A', 'arm', '-O', 'linux', '-T', 'kernel', '-C', 'none', '-a', '0x90008000', '-e', '0x90008000', '-n', 'Linux', '-d', '/tmp/tmpXkyS2N/binary/boot/vmlinuz-2.6.38-1000-linaro-mx51', '/tmp/tmpXkyS2N/boot-disc/uImage']" returned a non-zero value: 1 --- quote end ---
Looking at the packaging branch lp:ubuntu/linaro-image-tools, I see there are now multiple binary packages generated from linaro-image-tools.
The udisks dependency needs to be added somewhere -- does anyone know which package needs it? I'm guessing it's either linaro-image-tools or python-linaro-image-tools (possibly both).
Cheers ---Dave
On Tue, Mar 08, 2011, Dave Martin wrote:
Looking at the packaging branch lp:ubuntu/linaro-image-tools, I see there are now multiple binary packages generated from linaro-image-tools.
The udisks dependency needs to be added somewhere -- does anyone know which package needs it? I'm guessing it's either linaro-image-tools or python-linaro-image-tools (possibly both).
grep udisks to the rescue, and /usr/share/pyshared/linaro_media_create/check_device.py and /usr/share/pyshared/linaro_media_create/partitions.py seem to use it, so I'd say python-linaro-media-create needs it.
W dniu 08.03.2011 09:51, Shawn Guo pisze:
By looking the workaround on the hacking branch, I changed the sleep(1) to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py, and almost made it, but sadly it still fails at the last step.
You most likely missed another sleep (there should be two). Could you please confirm that?
Thanks ZK
On Tue, Mar 08, 2011 at 03:16:32PM +0100, Zygmunt Krynicki wrote:
W dniu 08.03.2011 09:51, Shawn Guo pisze:
By looking the workaround on the hacking branch, I changed the sleep(1) to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py, and almost made it, but sadly it still fails at the last step.
You most likely missed another sleep (there should be two). Could you please confirm that?
I only see one sleep in /usr/share/pyshared/linaro_media_create/partitions.py. You meant there is another one in partitions.py or other files?
I attached the /usr/share/pyshared/linaro_media_create/partitions.py for your checking.
W dniu 08.03.2011 15:48, Shawn Guo pisze:
On Tue, Mar 08, 2011 at 03:16:32PM +0100, Zygmunt Krynicki wrote:
W dniu 08.03.2011 09:51, Shawn Guo pisze:
By looking the workaround on the hacking branch, I changed the sleep(1) to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py, and almost made it, but sadly it still fails at the last step.
You most likely missed another sleep (there should be two). Could you please confirm that?
I only see one sleep in /usr/share/pyshared/linaro_media_create/partitions.py. You meant there is another one in partitions.py or other files?
I attached the /usr/share/pyshared/linaro_media_create/partitions.py for your checking.
I meant that I needed those two changes to make l-m-c work on my laptop:
http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/2...
http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/2...
The file you attached seems to have only one of them. Please look at the sleep call after "parted -s" in create_partitions()
Best regards ZK
On Tue, Mar 08, 2011 at 04:03:12PM +0100, Zygmunt Krynicki wrote:
W dniu 08.03.2011 15:48, Shawn Guo pisze:
On Tue, Mar 08, 2011 at 03:16:32PM +0100, Zygmunt Krynicki wrote:
W dniu 08.03.2011 09:51, Shawn Guo pisze:
By looking the workaround on the hacking branch, I changed the sleep(1) to sleep(5) in /usr/share/pyshared/linaro_media_create/partitions.py, and almost made it, but sadly it still fails at the last step.
You most likely missed another sleep (there should be two). Could you please confirm that?
I only see one sleep in /usr/share/pyshared/linaro_media_create/partitions.py. You meant there is another one in partitions.py or other files?
I attached the /usr/share/pyshared/linaro_media_create/partitions.py for your checking.
I meant that I needed those two changes to make l-m-c work on my laptop:
http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/2...
http://bazaar.launchpad.net/~zkrynicki/linaro-image-tools/hacking/revision/2...
The file you attached seems to have only one of them. Please look at the sleep call after "parted -s" in create_partitions()
I just added this one, and it does not help. The l-m-c still fails at the last step.
mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just added this one, and it does not help. The l-m-c still fails at the last step. mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
This error sounded a bit weird; I checked the u-boot sources, and this string is used in a bunch of places, but essentially it's either on write() or on close() that this fails. I bet it's on write() as I don't see close() failing without an useful errno, but I could imagine the write tests failing: if (write(ifd, tparams->hdr, tparams->header_size) != tparams->header_size) { fprintf (stderr, "%s: Write error on %s: %s\n", params.cmdname, params.imagefile, strerror(errno)); notably if this is a partial write.
We could change mkimage's write()s to actually account for the number of bytes written rather than just failing when not all bytes were written.
Could you log a bug on the u-boot package on that one? Or rather, could you check before hand where your mkimage comes from? dpkg -S `which mkimage`
apt-cache policy name-of-the-package-returned-above
Thanks!
On Tue, Mar 08, 2011 at 05:39:27PM +0100, Loïc Minier wrote:
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just added this one, and it does not help. The l-m-c still fails at the last step. mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
This error sounded a bit weird; I checked the u-boot sources, and this string is used in a bunch of places, but essentially it's either on write() or on close() that this fails. I bet it's on write() as I don't see close() failing without an useful errno, but I could imagine the write tests failing: if (write(ifd, tparams->hdr, tparams->header_size) != tparams->header_size) { fprintf (stderr, "%s: Write error on %s: %s\n", params.cmdname, params.imagefile, strerror(errno)); notably if this is a partial write.
We could change mkimage's write()s to actually account for the number of bytes written rather than just failing when not all bytes were written.
Could you log a bug on the u-boot package on that one? Or rather, could you check before hand where your mkimage comes from? dpkg -S `which mkimage`
apt-cache policy name-of-the-package-returned-above
$ apt-cache policy uboot-mkimage uboot-mkimage: Installed: 0.4build1 Candidate: 0.4build1 Version table: *** 0.4build1 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status
On Wed, Mar 09, 2011, Shawn Guo wrote:
$ apt-cache policy uboot-mkimage uboot-mkimage: Installed: 0.4build1 Candidate: 0.4build1 Version table: *** 0.4build1 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status
Ok; natty has a more recent version built from u-boot upstream in the u-boot-tools package (superseding uboot-mkimage which was a fork); mind trying that out?
On Tue, Mar 8, 2011 at 4:39 PM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just added this one, and it does not help. The l-m-c still fails at the last step. mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
This error sounded a bit weird; I checked the u-boot sources, and this string is used in a bunch of places, but essentially it's either on write() or on close() that this fails. I bet it's on write() as I don't see close() failing without an useful errno, but I could imagine the write tests failing: if (write(ifd, tparams->hdr, tparams->header_size) != tparams->header_size) { fprintf (stderr, "%s: Write error on %s: %s\n", params.cmdname, params.imagefile, strerror(errno)); notably if this is a partial write.
libc.info in particular says (of write()): "The return value is the number of bytes actually written. This may be SIZE, but can always be smaller. Your program should always call `write' in a loop, iterating until all the data is written."
We could change mkimage's write()s to actually account for the number of bytes written rather than just failing when not all bytes were written.
There's no reason I can see for mkimage to use the low-level POSIX read/write interface. Life would be simpler (and more portable) if it just used stdio, because it provides the desired semantics...
More realistically, we could just propose a write() wrapper contains the necessary loop to provide the expected semantics.
We should check for other instances of the same error, possibly including calls to read() as well. However, I can't find clear documentation on whether a short read() should ever occur on a normal file in the absence of signals, provided there is enough data in the file. Usually I assume that short reads might happen because otherwise the program won't work properly on pipes, sockets etc., but this is probably not so much of a concern for mkimage.
The natty version of u-boot has just the same error with write(); see:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/u-boot/natty/view/...
The upstream master branch of U-Boot on git://git.denx.de/u-boot.git has the bug too.
Cheers ---Dave
On Wed, Mar 09, 2011, Dave Martin wrote:
The upstream master branch of U-Boot on git://git.denx.de/u-boot.git has the bug too.
Yes, this is where I was pasting the bogus code from; I just have no idea why write() would suddenly become partial ones, but I didn't check the eglibc or linux code to see the cases it might happen, so my first reaction was proposing to try the latest version as it might also be an old bug.
In any case we should fix the handling of write() (and read()).
On Wed, Mar 9, 2011 at 10:42 AM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Mar 09, 2011, Dave Martin wrote:
The upstream master branch of U-Boot on git://git.denx.de/u-boot.git has the bug too.
Yes, this is where I was pasting the bogus code from; I just have no idea why write() would suddenly become partial ones, but I didn't check the eglibc or linux code to see the cases it might happen, so my first reaction was proposing to try the latest version as it might also be an old bug.
Don't know about that. Maybe it depends on the precise kernel being used; though it the I/O is slow enough that could maybe have an impact too.
Cheers ---Dave
On Mon, Mar 07, 2011 at 02:03:15PM +0100, Loïc Minier wrote:
On Mon, Mar 07, 2011, Shawn Guo wrote:
proc umounted /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write
Hmm that's really bad; the only thing that I can think of is that your device goes away for some time after the empty partition table is created, and so the sfdisk call comes too soon; could you try this on your MMC: parted -s /dev/sdN mklabel msdos && sfdisk -L /dev/sdN
$ sudo parted -s /dev/sdb mklabel msdos && sfdisk -L /dev/sdb /dev/sdb: Permission denied
sfdisk: cannot open /dev/sdb read-write
if sfdisk fails when called immediately after parted, it probably means we have to poll for readyness of /dev/sdN before calling sfdisk.
On Tue, Mar 08, 2011 at 10:23:17AM +0100, Loïc Minier wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
parted -s /dev/sdN mklabel msdos && sfdisk -L /dev/sdN$ sudo parted -s /dev/sdb mklabel msdos && sfdisk -L /dev/sdb /dev/sdb: Permission denied
sfdisk: cannot open /dev/sdb read-write
you want to sudo the sfdisk call too
Have a look at the /dev/sdb change in device report before and after the command you suggest ...
--- quote begin --- r65073@S2101-09:~/image/linaro$ linaro-media-create --rootfs ext3 --mmc /dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk
I see... Device Mount point Size /dev/sda5 none 76048MB /dev/dm-0 / 72868MB /dev/dm-1 none 3136MB /dev/sdb1 none 3780MB /dev/sda none 76293MB /dev/sda1 /boot 243MB /dev/sda2 none 76048MB /dev/sr0 none 0MB /dev/sdb none 3781MB Are you 100% sure, on selecting [/dev/sdb] (y/n)? n r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && sudo sfdisk -L /dev/sdb /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write r65073@S2101-09:~/image/linaro$ linaro-media-create --rootfs ext3 --mmc /dev/sdb --binary linaro-n-developer-tar-20110302-0.tar.gz --hwpack hwpack_linaro-imx51_20110302-0_armel_unsupported.tar.gz --dev mx51evk
I see... Device Mount point Size /dev/sda5 none 76048MB /dev/dm-0 / 72868MB /dev/dm-1 none 3136MB /dev/sda none 76293MB /dev/sda1 /boot 243MB /dev/sda2 none 76048MB /dev/sr0 none 0MB /dev/sdb none 0MB Are you 100% sure, on selecting [/dev/sdb] (y/n)? n --- quote end ---
On Tue, Mar 08, 2011, Shawn Guo wrote:
Have a look at the /dev/sdb change in device report before and after the command you suggest ...
Interesting :-)
But the linaro-media-create "size" output is probably broken for the same reason: sdb appears to be unavailable for some time after changing the partition table:
Are you 100% sure, on selecting [/dev/sdb] (y/n)? n r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && sudo sfdisk -L /dev/sdb /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write
That's pretty convincing to me; anything relevant in dmesg?
We could do something like the attached shell script; would you mind running it to confirm this works without removing/reinserting the MMC? I'm curious to see how much time your drive needs to come back.
On 8 March 2011 18:52, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
Have a look at the /dev/sdb change in device report before and after the command you suggest ...
Interesting :-)
But the linaro-media-create "size" output is probably broken for the same reason: sdb appears to be unavailable for some time after changing the partition table:
Are you 100% sure, on selecting [/dev/sdb] (y/n)? n r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && sudo sfdisk -L /dev/sdb /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write
That's pretty convincing to me; anything relevant in dmesg?
We could do something like the attached shell script; would you mind running it to confirm this works without removing/reinserting the MMC? I'm curious to see how much time your drive needs to come back.
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
1) Transend 4GB SD 2) SanDisk 2GB SD 3) KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
4) SanDisk 4GB SD 5) SanDisk 4GB SD 6) SanDisk 4GB SD 7) SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
Here are two more tests I will do.
* With adding two sleep(5) in partitions.py that Zygmunt suggests, I will run l-m-c on the failing card to see if it can get through. * With the original l-m-c installation, I will run l-m-c on one of card 1) ~ 3), probably 1) to see how l-m-c goes with the card passed wait_device.
Again, due to the slow apt-get natty speed, the tests are time consuming. I will update the result once it gets done.
On Tue, Mar 08, 2011, Shawn Guo wrote:
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
- Transend 4GB SD
- SanDisk 2GB SD
- KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter.
On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
- Transend 4GB SD
- SanDisk 2GB SD
- KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter.
Will do when I'm in office tomorrow.
On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
- Transend 4GB SD
- SanDisk 2GB SD
- KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter.
Today in office, with another reader and another maverick machine, the result seems consistent. The new thing is those four failing cards sometime ends up with "Could list partitions after 2 seconds!", besides the two possible results reported before, 0 second and failed to list.
On Wed, Mar 09, 2011 at 09:01:33PM +0800, Shawn Guo wrote:
On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
- Transend 4GB SD
- SanDisk 2GB SD
- KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter.
Today in office, with another reader and another maverick machine, the result seems consistent. The new thing is those four failing cards sometime ends up with "Could list partitions after 2 seconds!", besides the two possible results reported before, 0 second and failed to list.
I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports:
Could list partitions after 0 seconds! --> 13 times Could list partitions after 2 seconds! --> 5 times Could list partitions after 4 seconds! --> once Could list partitions after 8 seconds! --> once
But it never ends up "Giving up after 30 seconds failing to list partitions".
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports:
Could list partitions after 0 seconds! --> 13 times Could list partitions after 2 seconds! --> 5 times Could list partitions after 4 seconds! --> once Could list partitions after 8 seconds! --> once
Gah that's still pretty bad, but I guess we could wait up to 30 seconds and output some messages on the console.
Guilherme, what do you think?
On Wed, 2011-03-09 at 14:34 +0100, Loïc Minier wrote:
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports:
Could list partitions after 0 seconds! --> 13 times Could list partitions after 2 seconds! --> 5 times Could list partitions after 4 seconds! --> once Could list partitions after 8 seconds! --> once
Gah that's still pretty bad, but I guess we could wait up to 30 seconds and output some messages on the console.
Guilherme, what do you think?
Do we know why this happens in some cases? It'd be better if we could only sleep when we know there's a chance that the partitions may be available after that.
On Wed, Mar 09, 2011, Guilherme Salgado wrote:
Do we know why this happens in some cases? It'd be better if we could only sleep when we know there's a chance that the partitions may be available after that.
I'm not sure what you're asking; are you asking for a test on whether we need to sleep? That's sfdisk -l, as I do in the script before sleeping
On Wed, 2011-03-09 at 20:14 +0100, Loïc Minier wrote:
On Wed, Mar 09, 2011, Guilherme Salgado wrote:
Do we know why this happens in some cases? It'd be better if we could only sleep when we know there's a chance that the partitions may be available after that.
I'm not sure what you're asking; are you asking for a test on whether we need to sleep? That's sfdisk -l, as I do in the script before sleeping
My concern is that sfdisk -l returning non-zero may not be a very good indication that we should sleep. It will return non-zero on any error and I expect most errors to not go away after a 30 seconds sleep, in which case we'd be delaying l-m-c's exit unnecessarily. That may not be a big deal, though.
On Wed, Mar 09, 2011, Guilherme Salgado wrote:
My concern is that sfdisk -l returning non-zero may not be a very good indication that we should sleep. It will return non-zero on any error and I expect most errors to not go away after a 30 seconds sleep, in which case we'd be delaying l-m-c's exit unnecessarily. That may not be a big deal, though.
Ah I see what you mean, for instance if the MMC is definitely dead and wont ever come back, you'd like to be able to detect that.
I don't know what to test for though: we just wrote a blank partition table (parted mklabel msdos), and we're just trying sfdisk -l on it. What test did you have in mind?
On Wed, 2011-03-09 at 20:30 +0100, Loïc Minier wrote:
On Wed, Mar 09, 2011, Guilherme Salgado wrote:
My concern is that sfdisk -l returning non-zero may not be a very good indication that we should sleep. It will return non-zero on any error and I expect most errors to not go away after a 30 seconds sleep, in which case we'd be delaying l-m-c's exit unnecessarily. That may not be a big deal, though.
Ah I see what you mean, for instance if the MMC is definitely dead and wont ever come back, you'd like to be able to detect that.
I don't know what to test for though: we just wrote a blank partition table (parted mklabel msdos), and we're just trying sfdisk -l on it. What test did you have in mind?
I didn't have anything in mind; just wanted to know what was the cause of the delay to see if there's anything we could use to identify failure modes which can be resolved with just a sleep.
On Wed, Mar 09, 2011 at 09:01:33PM +0800, Shawn Guo wrote:
On Tue, Mar 08, 2011 at 04:59:18PM +0100, Loïc Minier wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
- Transend 4GB SD
- SanDisk 2GB SD
- KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter.
Today in office, with another reader and another maverick machine, the result seems consistent. The new thing is those four failing cards sometime ends up with "Could list partitions after 2 seconds!", besides the two possible results reported before, 0 second and failed to list.
I have to add something here to correct the conclusion about reader's impact.
I just got the third reader to play with, and interestingly it can get all of these failing cards give 'Could list partitions after 0 seconds!'. Let's focus one failing card (#4, the very first one) to see the difference that readers make here.
Reader #1: SSK Reader #2: PISEN Reader #3: another SSK (golden one)
Host machine (office one): Intel(R) Pentium(R) 4 CPU 2.80GHz + Maverick Server
=== wait_device testing === * On reader #1, consistently fails with 30 seconds timeout * On reader #2, very likely succeeds after 2 seconds (5 out of 6 iterations), (fails with 30 seconds timeout on the 6th iteration) * On reader #3, consistently succeeds after 0 seconds
=== l-m-c installing with sleep(5) === * On reader #1, fails on '/dev/sdb: No medium found' like below. [...] proc umounted /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write Traceback (most recent call last): File "/usr/bin/linaro-media-create", line 127, in <module> args.should_format_rootfs) File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 71, in setup_partitions board_config, media, HEADS, SECTORS, cylinders) File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 310, in create_partitions run_sfdisk_commands(sfdisk_cmd, heads, sectors, cylinders, media.path) File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 288, in run_sfdisk_commands return proc.communicate("%s\n" % commands) File "/usr/lib/python2.6/subprocess.py", line 691, in communicate return self._communicate(input) File "/usr/lib/python2.6/subprocess.py", line 1258, in _communicate self.wait() File "/usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py", line 66, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', '-E', 'sfdisk', '-D', '-H'
* On reader #2, fails on 'mkimage: Write error on /tmp/tmpViO9KL/boot-disc/uImage: Success' as below. [...] This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. 162+1 records in 162+1 records out 166624 bytes (167 kB) copied, 0.0407654 s, 4.1 MB/s mkimage: Write error on /tmp/tmpViO9KL/boot-disc/uImage: Success Traceback (most recent call last): File "/usr/bin/linaro-media-create", line 134, in <module> args.device, args.is_live, args.is_lowmem, args.consoles) File "/usr/lib/pymodules/python2.6/linaro_media_create/populate_boot.py", line 57, in populate_boot boot_disk, boot_script, boot_device_or_file) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 118, in make_boot_files boot_device_or_file) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 312, in _make_boot_files cls.load_addr, uboot_parts_dir, cls.kernel_suffix, boot_dir) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 389, in make_uImage 'kernel', load_addr, load_addr, 'Linux', img_data, img) File "/usr/lib/pymodules/python2.6/linaro_media_create/boards.py", line 363, in _run_mkimage proc.wait() File "/usr/lib/pymodules/python2.6/linaro_media_create/cmd_runner.py", line 66, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_media_create.cmd_runner.SubcommandNonZeroReturnValue: Sub process "['sudo', '-E', 'mkimage', '-A', 'arm', '-O', 'linux', '-T', 'kernel', '-C', 'none', '-a', '0x90008000', '-e', '0x90008000', '-n', 'Linux', '-d', '/tmp/tmpViO9KL/binary/boot/vmlinuz-2.6.38-1000-linaro-mx51', '/tmp/tmpViO9KL/boot-disc/uImage']" returned a non-zero value: 1
* On reader #3, succeeds !!!
So I would say the result not only depends on the cards but also readers.
On Thu, Mar 10, 2011 at 12:32:29PM +0800, Shawn Guo wrote:
On Wed, Mar 09, 2011 at 09:01:33PM +0800, Shawn Guo wrote:
[...]
I have to add something here to correct the conclusion about reader's impact.
I just got the third reader to play with, and interestingly it can get all of these failing cards give 'Could list partitions after 0 seconds!'. Let's focus one failing card (#4, the very first one) to see the difference that readers make here.
Reader #1: SSK Reader #2: PISEN Reader #3: another SSK (golden one)
Reader #3: another SSK (different model from #1)
On Thu, Mar 10, 2011, Shawn Guo wrote:
=== wait_device testing ===
- On reader #1, consistently fails with 30 seconds timeout
- On reader #2, very likely succeeds after 2 seconds (5 out of 6 iterations), (fails with 30 seconds timeout on the 6th iteration)
- On reader #3, consistently succeeds after 0 seconds
This is really valuable information, thanks a lot for your testing
Can you think of a way we could distinguish between these readers? I don't want us to start tracking USB reader vendor information, but maybe they expose some SDHC bit, or have SDHC in their description instead of MMC or...? Maybe the good readers perform at higher speeds and we could do a speed test and refuse to work with slow readers?
So I would say the result not only depends on the cards but also readers.
Absolutely
On Tue, Mar 08, 2011 at 11:44:36PM +0800, Shawn Guo wrote:
On 8 March 2011 18:52, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Mar 08, 2011, Shawn Guo wrote:
Have a look at the /dev/sdb change in device report before and after the command you suggest ...
Interesting :-)
But the linaro-media-create "size" output is probably broken for the same reason: sdb appears to be unavailable for some time after changing the partition table:
Are you 100% sure, on selecting [/dev/sdb] (y/n)? n r65073@S2101-09:~/image/linaro$ sudo parted -s /dev/sdb mklabel msdos && sudo sfdisk -L /dev/sdb /dev/sdb: No medium found
sfdisk: cannot open /dev/sdb read-write
That's pretty convincing to me; anything relevant in dmesg?
We could do something like the attached shell script; would you mind running it to confirm this works without removing/reinserting the MMC? I'm curious to see how much time your drive needs to come back.
I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test.
- Transend 4GB SD
- SanDisk 2GB SD
- KingMax MMC Mobile 2GB
All above 3 cards passed the test with giving "Could list partitions after 0 seconds!"
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
- SanDisk 4GB SD
All above 4 cards failed with giving "Giving up after 30 seconds failing to list partitions". The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it.
Here are two more tests I will do.
- With adding two sleep(5) in partitions.py that Zygmunt suggests, I
will run l-m-c on the failing card to see if it can get through.
As I replied Zygmunt in another message, it still fails at 'mkimage: Write error ...'.
- With the original l-m-c installation, I will run l-m-c on one of
card 1) ~ 3), probably 1) to see how l-m-c goes with the card passed wait_device.
It works good on card #1, and system boots on mx51evk board.
I also did the third test below suggested by Zygmunt and David on IRC.
* Create image_file and dd it to failing card
I did it on the failing card I used to report the issue originally, and it works no problem, and system boots on mx51evk board.
On Fri, Mar 4, 2011 at 2:09 AM, Spring Zhang spring.zhang@linaro.orgwrote:
Ok. Which wiki page did you look at? We should be directing maverick
users to enable the linaro-maintainers/tools ppa, which includes both the linaro-image-tools and qemu-linaro packages.
I can find linaro-image-tools, but no qemu-linaro on maverick, and I added PPA.
qemu-linaro is just the source package name. If you already have the
necessary qemu bits installed, just update. Otherwise, iirc you need qemu-user-static or qemu-kvm-extras-static.
Thanks, Paul Larson
On Mon, Feb 07, 2011, Alexander Sack wrote:
Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled?
This sounds awfully Ubuntu specific; we released a standalone tarball as to allow people to grab the tools on other distros as well
The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform.
bundled binaries are so wrong; then we need to provide source, allow people to override them, this is really a path I don't want us to go to, and something I would complain about if an upstream was doing that...
Linaro is distributing a qemu version which is fixed; we should just point people at it.
Concerning testing the version, this is something we could easily do, but I don't really like it: for instance if we fix this issue in a qemu patch to an older version, the version check will decide that qemu is broken when it is not. The only correct thing to do would be to try to run a piece of code for which we know emulation is broken, and then report the result of this test to the end-user (e.g. we could point at a wiki page with a FAQ entry on the qemu fix). Implementing a version check is much easier though.
I don't really want us to be in the business of meta-distributing fixes , or defensively testing for everything in the environment -- we have better things to work on.
How about we call this a common issue and we add it on the wiki page where the installation instructions live, and we bundle a FAQ with linaro-image-tools?
Hi Aneesh
On 02/07/2011 07:25 AM, Aneesh V wrote:
Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
I installed all dependencies mentioned in the README and tried to run linaro-media-create like below:
sudo ./linaro-media-create --rootfs ext3 --mmc /dev/sdb1 --binary /home/a0393566local/linaro/headless/linaro-natty-headless- tar-20110206-0.tar.gz --hwpack /home/a0393566local/linaro/hwpack /hwpack_linaro-panda_20110206-0_armel_supported.tar.gz --dev panda
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
You need to upgrade some of the qemu packages. Look at comments in bug:
https://bugs.launchpad.net/linaro-image-tools/+bug/705236
--Matt
Any idea what could be going wrong?
Thanks, Aneesh
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi All,
Thanks for the quick help. qemu update helped me. Maybe, I should have read the README more carefully.
Thanks, Aneesh
On Monday 07 February 2011 08:54 PM, Matt Waddel wrote:
Hi Aneesh
On 02/07/2011 07:25 AM, Aneesh V wrote:
Hi,
I am trying to prepare an MMC card to boot up Panda with Linaro daily build image.
I downloaded linaro-image-tools from: https://launchpad.net/linaro-image-tools
I installed all dependencies mentioned in the README and tried to run linaro-media-create like below:
sudo ./linaro-media-create --rootfs ext3 --mmc /dev/sdb1 --binary /home/a0393566local/linaro/headless/linaro-natty-headless- tar-20110206-0.tar.gz --hwpack /home/a0393566local/linaro/hwpack /hwpack_linaro-panda_20110206-0_armel_supported.tar.gz --dev panda
However, it crashes immediately with the following dump: http://pastebin.com/SV78dP8L
You need to upgrade some of the qemu packages. Look at comments in bug:
https://bugs.launchpad.net/linaro-image-tools/+bug/705236
--Matt
Any idea what could be going wrong?
Thanks, Aneesh
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-
Alexander Sack -
Aneesh V -
Dave Martin -
Guilherme Salgado -
Loïc Minier -
Matt Waddel -
Michael Hope -
Paul Larson -
Peter Maydell -
Shawn Guo -
Shawn Guo -
Spring Zhang -
Steve Langasek -
Zygmunt Bazyli Krynicki -
Zygmunt Krynicki