Ubuntu
edk2 package

arm64: wily: hanging during reboot

Bug #1527047 reported by Ming Lei
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
edk2 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Inside VM wily kernel which is installed via wily d-i installer, reboot hangs, see the following message:

[ 40.294727] reboot: Restarting system

And never return to UEFI UI.

The issue can be observed too in d-i installing too.

Revision history for this message
Steve Langasek (vorlon) wrote :

Which version of edk2 did you see this issue with?

Revision history for this message
dann frazier (dannf) wrote :

I can reproduce - here are the steps:

I installed an HP m400 (mcdivitt) with wily, and installed qemu-efi (0~20150106.5c2d456b-2) and qemu-kvm (2.3+dfsg-5ubuntu9.1).

$ wget http://cloud-images.ubuntu.com/wily/current/wily-server-cloudimg-arm64-uefi1.img
$ dd if=/dev/zero of=flash0.img bs=1M count=64
$ dd if=/usr/share/qemu-efi/QEMU_EFI.fd of=flash0.img conv=notrunc
$ dd if=/dev/zero of=flash1.img bs=1M count=64

Then created my-seed.iso following instructions at http://ubuntu-smoser.blogspot.com/2013/02/using-ubuntu-cloud-images-without-cloud.html

I then booted with:
$ sudo qemu-system-aarch64 -enable-kvm -m 1024 -cpu host -smp 4 -M virt -nographic -pflash flash0.img -pflash flash1.img -drive if=none,file=wily-server-cloudimg-arm64-uefi1.img,id=hd0 -device virtio-blk-device,drive=hd0 -drive if=none,file=my-seed.img,id=hd1 -device virtio-blk-device,drive=hd1 -netdev type=tap,id=net0 -device virtio-net-device,netdev=net0,mac=ac:67:de:d2:4b:06

After logging in, my console would hang with "irq 37: nobody cared (try booting with the "irqpoll" option)". So I did so, and was able to login and type "sudo reboot". I then observed that it did not, in fact, reboot.

Changed in edk2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1527047] Re: arm64: wily: hanging during reboot

On Thu, Jan 28, 2016 at 02:03:45AM -0000, dann frazier wrote:
> I can reproduce - here are the steps:

Thanks for confirming, Dann. Do you know if this is reproducible with
0~20160104.c2a892d7 (the version that has just been uploaded to Debian
unstable)?

Revision history for this message
dann frazier (dannf) wrote :

On Wed, Jan 27, 2016 at 7:53 PM, Steve Langasek
<email address hidden> wrote:
> On Thu, Jan 28, 2016 at 02:03:45AM -0000, dann frazier wrote:
>> I can reproduce - here are the steps:
>
> Thanks for confirming, Dann. Do you know if this is reproducible with
> 0~20160104.c2a892d7 (the version that has just been uploaded to Debian
> unstable)?

Steve,
  Just tested, and yes it is. I should also note that I'm not sure
that this is necessarily an edk2 issue to fix. Seems to me that this
could also be a problem with QEMU or the guest kernel. I've tested the
latest xenial versions of each (qemu 2.5+dfsg-1ubuntu3, linux
4.4.0-2.16) along with the latest edk2 from Debian, and the problem
persists.

   -dann

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.