Hi there,
I've followed the instructions on https://wiki.linaro.org/Source/ImageInstallation to generate a qemu image using linaro-media-create and although the image was generated fine, I got the following error when trying to run it:
qemu: hardware error: no boot device found CPU #0: R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=400140a4 PSR=400001d3 -Z-- A svc32 Aborted
That was using today's daily headless tarball, btw.
Any ideas what's wrong?
This didn't happen when I used an older tarball, so I guess it was a problem with yesterday's one.
On Wed, 2010-09-15 at 17:41 -0300, Guilherme Salgado wrote:
Hi there,
I've followed the instructions on https://wiki.linaro.org/Source/ImageInstallation to generate a qemu image using linaro-media-create and although the image was generated fine, I got the following error when trying to run it:
qemu: hardware error: no boot device found CPU #0: R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=400140a4 PSR=400001d3 -Z-- A svc32 AbortedThat was using today's daily headless tarball, btw.
Any ideas what's wrong?
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Sep 15, 2010, Guilherme Salgado wrote:
qemu: hardware error: no boot device found
Could you share the QEMU cmdline you're using and which version of QEMU you're using?
This error in the case of the omap3 emulation is usually when the partition table isn't correct, or MLO is missing from the first vfat.
(I would also get the error in the past when QEMU had a memory corruption issue in the FAT code, but that should be fixed in the PPA version.)
If you're using the latest qemu-maemo package from the Linaro tools PPA, then you should file a bug against lp:qemu-maemo.
Thanks!
On Thu, Sep 16, 2010 at 05:03:55PM +0200, Loïc Minier wrote:
On Wed, Sep 15, 2010, Guilherme Salgado wrote:
qemu: hardware error: no boot device found
Could you share the QEMU cmdline you're using and which version of QEMU you're using?
This error in the case of the omap3 emulation is usually when the partition table isn't correct, or MLO is missing from the first vfat.
Ah, then please make sure you're using an up-to-date linaro-media-create; the handling of x-loader in the headless images has been changed as of yesterday, so you need a matching l-m-c that knows how to extract MLO from the right location in the tarball and install it to the vfat partition when generating the image.
On Thu, Sep 16, 2010, Steve Langasek wrote:
Ah, then please make sure you're using an up-to-date linaro-media-create; the handling of x-loader in the headless images has been changed as of yesterday, so you need a matching l-m-c that knows how to extract MLO from the right location in the tarball and install it to the vfat partition when generating the image.
Sounds like we should get an updated package in maverick asap?
On Fri, Sep 17, 2010 at 12:04:49AM +0200, Loïc Minier wrote:
On Thu, Sep 16, 2010, Steve Langasek wrote:
Ah, then please make sure you're using an up-to-date linaro-media-create; the handling of x-loader in the headless images has been changed as of yesterday, so you need a matching l-m-c that knows how to extract MLO from the right location in the tarball and install it to the vfat partition when generating the image.
Sounds like we should get an updated package in maverick asap?
The bzr branch is currently in flux because of the hwpack work, and https://wiki.linaro.org/Source/ImageInstallation points at the bzr branch rather than the package; given that we're in final freeze, I think we should wait until this settles and then upload.
On Thu, 2010-09-16 at 09:22 -0700, Steve Langasek wrote:
On Thu, Sep 16, 2010 at 05:03:55PM +0200, Loïc Minier wrote:
On Wed, Sep 15, 2010, Guilherme Salgado wrote:
qemu: hardware error: no boot device found
Could you share the QEMU cmdline you're using and which version of QEMU you're using?
This error in the case of the omap3 emulation is usually when the partition table isn't correct, or MLO is missing from the first vfat.
Ah, then please make sure you're using an up-to-date linaro-media-create; the handling of x-loader in the headless images has been changed as of yesterday, so you need a matching l-m-c that knows how to extract MLO from the right location in the tarball and install it to the vfat partition when generating the image.
I was running it from the trunk branch, so I had the most recent version of it at that time. Could it have been fixed after I tried?
On Fri, Sep 17, 2010 at 10:34:15AM -0300, Guilherme Salgado wrote:
On Thu, 2010-09-16 at 09:22 -0700, Steve Langasek wrote:
On Thu, Sep 16, 2010 at 05:03:55PM +0200, Loïc Minier wrote:
On Wed, Sep 15, 2010, Guilherme Salgado wrote:
qemu: hardware error: no boot device found
Could you share the QEMU cmdline you're using and which version of QEMU you're using?
This error in the case of the omap3 emulation is usually when the partition table isn't correct, or MLO is missing from the first vfat.
Ah, then please make sure you're using an up-to-date linaro-media-create; the handling of x-loader in the headless images has been changed as of yesterday, so you need a matching l-m-c that knows how to extract MLO from the right location in the tarball and install it to the vfat partition when generating the image.
I was running it from the trunk branch, so I had the most recent version of it at that time. Could it have been fixed after I tried?
This was fixed in revision 89 on September 15th - so yes, it's possible.
I replied to my previous message when I noticed this errors seemed to be specific to the 2010-09-15 tarball -- I didn't get the error when using an older one. I guess my reply is stuck in the moderation queue, though (I may have sent it using my @canonical.com address), as I don't see it on the list.
On Thu, 2010-09-16 at 17:03 +0200, Loïc Minier wrote:
On Wed, Sep 15, 2010, Guilherme Salgado wrote:
qemu: hardware error: no boot device found
Could you share the QEMU cmdline you're using and which version of QEMU you're using?
I used the line from that wiki page:
sudo qemu-maemo-system-arm -M beagle -m 256 -sd ./beagle_sd.img -clock unix -serial stdio
This error in the case of the omap3 emulation is usually when the partition table isn't correct, or MLO is missing from the first vfat.
(I would also get the error in the past when QEMU had a memory corruption issue in the FAT code, but that should be fixed in the PPA version.)
If you're using the latest qemu-maemo package from the Linaro tools PPA, then you should file a bug against lp:qemu-maemo.
I'm using the latest package, yes, but I'm on Lucid. With the older tarball I didn't get the error but it was spinning one of my processors for hours and the last thing I saw in the console was some omap nand thing. I"ll give it another try and report a bug if it doesn't work.
On Thu, 2010-09-16 at 17:03 +0200, Loïc Minier wrote:
On Wed, Sep 15, 2010, Guilherme Salgado wrote:
qemu: hardware error: no boot device found
Could you share the QEMU cmdline you're using and which version of QEMU you're using?
This error in the case of the omap3 emulation is usually when the partition table isn't correct, or MLO is missing from the first vfat.
(I would also get the error in the past when QEMU had a memory corruption issue in the FAT code, but that should be fixed in the PPA version.)
If you're using the latest qemu-maemo package from the Linaro tools PPA, then you should file a bug against lp:qemu-maemo.
It looks like https://bugs.edge.launchpad.net/qemu-maemo/+bug/628471
And that's currently making it impossible for me to test my changes to l-m-c as my board hasn't arrived, so I was wondering if there's any way to work around it.
On Tue, Sep 21, 2010, Guilherme Salgado wrote:
It looks like https://bugs.edge.launchpad.net/qemu-maemo/+bug/628471
And that's currently making it impossible for me to test my changes to l-m-c as my board hasn't arrived, so I was wondering if there's any way to work around it.
Well, there's a patch in the bug report; I didn't try it out myself yet
On 21 September 2010 18:22, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Sep 21, 2010, Guilherme Salgado wrote:
It looks like https://bugs.edge.launchpad.net/qemu-maemo/+bug/628471
And that's currently making it impossible for me to test my changes to l-m-c as my board hasn't arrived, so I was wondering if there's any way to work around it.
Well, there's a patch in the bug report; I didn't try it out myself yet
I'm in the final stages of doing a new version of qemu-maemo with this fix in it... I've uploaded a proposed package to my PPA (still in build queue) and I'm hoping to be able to upload it to the linaro-tools PPA once we've sorted out review/access permissions/etc (maybe tomorrow? this week, at any rate, I hope).
If you don't want to wait for that you could try pulling the sources to qemu-maemo 0.0~20100921+871d996-0ubuntu1~linaro1 from https://launchpad.net/~pmaydell/+archive/ppa/+packages and building them locally, I guess.
-- PMM
-----Original Message----- From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev- bounces@lists.linaro.org] On Behalf Of Peter Maydell Sent: Tuesday, September 21, 2010 1:14 PM To: Loïc Minier Cc: Guilherme Salgado; linaro-dev@lists.linaro.org Subject: Re: Error (no boot device found) running qemu image
On 21 September 2010 18:22, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Sep 21, 2010, Guilherme Salgado wrote:
It looks like https://bugs.edge.launchpad.net/qemu-maemo/+bug/628471
And that's currently making it impossible for me to test my changes
to
l-m-c as my board hasn't arrived, so I was wondering if there's any
way
to work around it.
Well, there's a patch in the bug report; I didn't try it out myself
yet
I'm in the final stages of doing a new version of qemu-maemo with this fix in it... I've uploaded a proposed package to my PPA (still in build queue) and I'm hoping to be able to upload it to the linaro-tools PPA once we've sorted out review/access permissions/etc (maybe tomorrow? this week, at any rate, I hope).
If you don't want to wait for that you could try pulling the sources to qemu-maemo 0.0~20100921+871d996-0ubuntu1~linaro1 from https://launchpad.net/~pmaydell/+archive/ppa/+packages and building them locally, I guess.
-- PMM
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Peter,
I pulled the source from your PPA and compiled it. I booted linaro-m-headless-tar-20100818-0.tar.gz and it continues past the omap2-nand driver hang; thanks for the improvements.
Since this is my first time trying linaro, I'm not sure what I'm supposed to see, it stops now with:
[ 19.148315] 5534 reserved pages [ 19.219512] 965 slab pages [ 19.250701] 11 pages shared [ 19.335449] 0 pages swap cached init: plymouth main process (48) killed by KILL signal init: ureadahead main process (47) killed by KILL signal
Jason
On 21 September 2010 20:23, Jason Andrews jasona@cadence.com wrote:
I pulled the source from your PPA and compiled it. I booted linaro-m-headless-tar-20100818-0.tar.gz and it continues past the omap2-nand driver hang; thanks for the improvements.
Since this is my first time trying linaro, I'm not sure what I'm supposed to see, it stops now with:
[ 19.148315] 5534 reserved pages [ 19.219512] 965 slab pages [ 19.250701] 11 pages shared [ 19.335449] 0 pages swap cached init: plymouth main process (48) killed by KILL signal init: ureadahead main process (47) killed by KILL signal
(Just to check: are you using the qemu command line from https://wiki.linaro.org/Source/ImageInstallation or something else?)
plymouth and ureadahead dying is expected (because we only have 256M of memory) with that snapshot: this is https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/600359 (which it seems has just been fixed but after the date of your snapshot). How long did you wait here? It should give you a login prompt, but it does pause for a while first.
-- PMM
-----Original Message----- From: Peter Maydell [mailto:peter.maydell@linaro.org] Sent: Tuesday, September 21, 2010 2:43 PM To: Jason Andrews Cc: Loïc Minier; Guilherme Salgado; linaro-dev@lists.linaro.org Subject: Re: Error (no boot device found) running qemu image
On 21 September 2010 20:23, Jason Andrews jasona@cadence.com wrote:
I pulled the source from your PPA and compiled it. I booted linaro-m-
headless-tar-20100818-0.tar.gz and
it continues past the omap2-nand driver hang; thanks for the
improvements.
Since this is my first time trying linaro, I'm not sure what I'm
supposed to see, it stops now with:
[ 19.148315] 5534 reserved pages [ 19.219512] 965 slab pages [ 19.250701] 11 pages shared [ 19.335449] 0 pages swap cached init: plymouth main process (48) killed by KILL signal init: ureadahead main process (47) killed by KILL signal
(Just to check: are you using the qemu command line from https://wiki.linaro.org/Source/ImageInstallation or something else?)
plymouth and ureadahead dying is expected (because we only have 256M of memory) with that snapshot: this is https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/600359 (which it seems has just been fixed but after the date of your snapshot). How long did you wait here? It should give you a login prompt, but it does pause for a while first.
-- PMM
Yes, I’m following instructions on the wiki page, including the qemu command line.
I ran longer and got repetitive messages like this:
[ 241.075134] INFO: task mtdblock0:30 blocked for more than 120 seconds. [ 241.116119] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message
I'll try with a newer snapshot.
Thanks, Jason
2010/9/21 Jason Andrews jasona@cadence.com:
On 21 September 2010 20:23, Jason Andrews jasona@cadence.com wrote:
I pulled the source from your PPA and compiled it. I booted linaro-m- headless-tar-20100818-0.tar.gz and it continues past the omap2-nand driver hang; thanks for the improvements.
I ran longer and got repetitive messages like this:
[ 241.075134] INFO: task mtdblock0:30 blocked for more than 120 seconds. [ 241.116119] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message
I'll try with a newer snapshot.
Mmm, I'd misread your version number as 20100918 and thought it was rather newer than it actually was. I've been successfully booting the beta, which is here (20100830): http://releases.linaro.org/platform/linaro-m/headless/beta/
(It occurs to me that it would be a good idea to have some automated testing of booting the daily snapshots under qemu. Do we have any infrastructure to make that easy?)
-- PMM
On Tue, Sep 21, 2010, Peter Maydell wrote:
(It occurs to me that it would be a good idea to have some automated testing of booting the daily snapshots under qemu. Do we have any infrastructure to make that easy?)
I've been thinking the same thing, and it sounds like a job for hudson! :-) let's discuss how we can do that, but I suspect we should start with a daily build of qemu which would kick a daily test of the rootfs.
On Wed, Sep 22, 2010 at 3:08 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Sep 21, 2010, Peter Maydell wrote:
(It occurs to me that it would be a good idea to have some automated testing of booting the daily snapshots under qemu. Do we have any infrastructure to make that easy?)
I've been thinking the same thing, and it sounds like a job for hudson! :-) let's discuss how we can do that, but I suspect we should start with a daily build of qemu which would kick a daily test of the rootfs.
I had been thinking about this as well, would you see more benefit for this to focus on testing the latest image, or qemu itself?
Thanks, Paul Larson
On 22 September 2010 18:38, Paul Larson paul.larson@linaro.org wrote:
On Wed, Sep 22, 2010 at 3:08 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Sep 21, 2010, Peter Maydell wrote:
(It occurs to me that it would be a good idea to have some automated testing of booting the daily snapshots under qemu. Do we have any infrastructure to make that easy?)
I've been thinking the same thing, and it sounds like a job for hudson! :-) let's discuss how we can do that, but I suspect we should start with a daily build of qemu which would kick a daily test of the rootfs.
I had been thinking about this as well, would you see more benefit for this to focus on testing the latest image, or qemu itself?
I think the image (and the kernel) are going to churn at a much faster rate than qemu will, so the benefit really is in early warning if the kernel has suddenly tickled a latent qemu bug/missing bit of model. (ie I think we'd want to do this test with the latest released qemu-maemo package as well as with any new daily build of qemu.)
For changes to qemu itself, it would be good if there was an easy way to test a proposed new qemu package to check that it still booted the last release and the latest snapshot. I guess if we push changes to git and do a daily build from that then that will handle that side of it.
-- PMM
2010/9/23 Peter Maydell peter.maydell@linaro.org:
On 22 September 2010 18:38, Paul Larson paul.larson@linaro.org wrote:
On Wed, Sep 22, 2010 at 3:08 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Sep 21, 2010, Peter Maydell wrote:
(It occurs to me that it would be a good idea to have some automated testing of booting the daily snapshots under qemu. Do we have any infrastructure to make that easy?)
I've been thinking the same thing, and it sounds like a job for hudson! :-) let's discuss how we can do that, but I suspect we should start with a daily build of qemu which would kick a daily test of the rootfs.
I had been thinking about this as well, would you see more benefit for this to focus on testing the latest image, or qemu itself?
I think the image (and the kernel) are going to churn at a much faster rate than qemu will, so the benefit really is in early warning if the kernel has suddenly tickled a latent qemu bug/missing bit of model. (ie I think we'd want to do this test with the latest released qemu-maemo package as well as with any new daily build of qemu.)
To overdo things, it would be nice to mix the compiler in as well. I've been planning to add a test case to the compiler build that builds the current Ubuntu kernel and boots it inside QEMU.
-- Michael
On Thu, Sep 23, 2010, Michael Hope wrote:
To overdo things, it would be nice to mix the compiler in as well. I've been planning to add a test case to the compiler build that builds the current Ubuntu kernel and boots it inside QEMU.
I think we should have batteries of test cases of each component before it sees a release, e.g. we should have a kernel build + run test before releasing a new toolchain, and a kernel run test before releasing a new QEMU, but this needs not be based on crack of the day. It's sufficient to build / run the latest released kernel for these tests rather than a git kernel. In the same way, I don't think we need to build kernels out of bzr toolchains; the latest released toolchain would be good.
We should get sufficient cross-testing via continuous integration of our releases in our development platforms (aka package repositories, like maverick or maverick+1).
It's entirely possible to do as you say, but I think it's basically testing too many things at once resulting in unstable x unstable x unstable combination, rather than stable x stable x unstable where we can blame changes quickly.
On Thu, Sep 23, 2010 at 08:18:06AM +1200, Michael Hope wrote:
I had been thinking about this as well, would you see more benefit for this to focus on testing the latest image, or qemu itself?
I think the image (and the kernel) are going to churn at a much faster rate than qemu will, so the benefit really is in early warning if the kernel has suddenly tickled a latent qemu bug/missing bit of model. (ie I think we'd want to do this test with the latest released qemu-maemo package as well as with any new daily build of qemu.)
To overdo things, it would be nice to mix the compiler in as well. I've been planning to add a test case to the compiler build that builds the current Ubuntu kernel and boots it inside QEMU.
Let's just test the image. The toolchain and qemu will be tested as a side-effect, but let's not lessen the benefit of ensuring our image runs on a "released" qemu.
-
Christian Robottom Reis -
Guilherme Salgado -
Guilherme Salgado -
Jason Andrews -
Loïc Minier -
Michael Hope -
Paul Larson -
Peter Maydell -
Steve Langasek