Testing Environment =============================== Host: qemuarm sato/sdk Kernel: Image location: http://autobuilder.pokylinux.org/nightly/20110121-1/qemu/qemuarm/ Steps =============================== 1. Boot up the qemuarm with sato/sdk image 2. Open a Terminal and run 'poweroff/shutdown -h now' Observed Result =============================== 1. The command 'poweroff/shutdown' can't close the qemu completely and exit to host console. 2. The 'Shutdown' icon on desktop can close the qemu completely and exit to host console.
Pls. be noted that the bug is for laverne build (20110121), not for master.
This is related to bug 100, and shutdown still needs to be addressed for Qemuarm which may require kernel or qemu changes.
I put this as an enhancement, since this is actually consistent with the hardware behaviour!
There are no plans to fix this, since it is behaving consistent with the hardware, it's a low value fix and definitely not needed for 1.0.1, so moving out the milestone on this.
I think this can be closed as WONTFIX. We can make these systems halt at reboot and that's about as good as it can get and is consistent with the real hardware they emulate.
Actually, can we make the poweroff/shutdown commands reboot these machines? Is there some way we can indicate to those commands to reboot?
Josh had a suggestion for just mapping the poweroff/shutdown to reboot (both command line and sato) and it met with luke warm comments. I support the mapping, but others who probably didn't realize that even the hardware wouldn't support that, proposed fixing the problem. Which with a lot of digging we could do, but isn't a great use of time or value add. So if we want to just go ahead with mapping these commands, I have no issue with it.
Hmm. I take that back, I was running the sysroot git. > which git /home/bruce/poky/build/tmp/sysroots/x86_64-linux/usr/bin/git yow-bashfiel-l1 [/home/bruc...8-r2/linux]> git --version git version 1.7.7 I'll check to see if for some reason the host git is being run by the kgit* scripts.
Any update from last comments?
The last comment was from the wrong bug. There still are no plans to fix this, since we match hardware. If we update to a new emulated platform (i.e. the vexpress), we can fix this in the kernel. If we want to map the buttons to different commands, that's another question and someone that works on sato would want to do that.
Bruce, moved to 1.3 M2, can you please provide an Estimate?
10d days is the estimate for updating the BSP.
Moving this to future. The qemuarm A9+ BSPs that are supported out of the yocto version of qemu do not support disk boot, and hence are not valid options. For yocto 1.3+ we can update the machine and resolve this issue, but fixing it on the existing machine is very low value for the time it will take.
Reproduced on branch "danny": commit 86c9aa8081f107420cd3763d0566d779daddc2b1 Date: Wed Oct 3 11:01:51 2012 -0700 Last message from console: "System halted"
*** Bug 3335 has been marked as a duplicate of this bug. ***
Reproduced on master: Commit 1a9226f140f578f11696abf1a3c989fae1d4c14a Date: Thu Jan 23 12:10:01 2014 +0000 Host: Ubuntu 13.10 & Fedora 20 Last message from console: "System halted" This issue does not reproduce with the previous commit: e4c23f7bcb79072ea6028fbdf8f3f0dc17a63371 from Jan 14
Actually, this happens with NFS and with an *.ext3 image, like: http://autobuilder.yoctoproject.org/pub/nightly/20140123-3/machines/qemu/qemuarm/core-image-sato-qemuarm.ext3
Since this matches the hardware and has low value, marking as WONTFIX (or really CANTFIX).
Adding Yi. Yi, I think we can keep the test case but stop attaching this bug to our qemuarm test runs. Also, please update the test case by attaching the bug link and also the test case should reflect the bug's resolution.