After discussing, I realise I had a misunderstanding in comment #30 that I'd like to correct.
I had incorrectly assumed that feeding the PXEBooting KVM guest a zero length pxelinux.cfg file *instructed* it to boot from the local disk. I now realise that is incorrect. Feeding the PXEBooting KVM guest a zero length pxelinux.cfg file only tells the guest to *fail* it's netboot attempt. It's at this stage that the architecture specific behaviour kicks in. On amd64, the netboot failure will force the KVM guest to move down to it's second specified boot option, namely the local disk. However, s390x will NEVER move to it's second specified boot option. If the first boot option (netbooting) fails, it abandons the attempt and powers the guest off. IBM has been informed of this difference in behaviour, but it is unlikely to be able to address it soon. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1859656 Title: [2.6] Unable to reboot s390x KVM machine after initial deploy Status in MAAS: Triaged Status in QEMU: Incomplete Status in Ubuntu on IBM z Systems: Triaged Bug description: MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Arch: S390x Appears that MAAS can not find the s390x bootloader to boot from the disk, not sure how maas determines this. However this was working in the past. I had originally thought that if the maas machine was deployed then it defaulted to boot from disk. If I force the VM to book from disk, the VM starts up as expected. Reproduce: - Deploy Disco on S390x KVM instance - Reboot it on the KVM console... Connected to domain s2lp6g001 Escape character is ^] done Using IPv4 address: 10.246.75.160 Using TFTP server: 10.246.72.3 Bootfile name: 'boots390x.bin' Receiving data: 0 KBytes TFTP error: file not found: boots390x.bin Trying pxelinux.cfg files... Receiving data: 0 KBytes Receiving data: 0 KBytes Failed to load OS from network ==> /var/log/maas/rackd.log <== 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] boots390x.bin requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BA0 requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BA requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64B requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 requested by 10.246.75.160 2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/default requested by 10.246.75.160 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1859656/+subscriptions
