@paelzer, Aye and thanks for your comment #27 , I was already aware of that, and yes that does work. However, it's a shoddy workaround at best and if this is going to be a solution to be presented to a customer MAAS would be scoffed at.
I'm aware of the issue at hand here, I think the problem existing now, is that a decision needs to be made moving forward how to fix this. I was about to suggest that what makes the most sense IMO and is the least invasive is the suggest by @paelzer from comment #29 Maas can boot from network (always) and if not deploying just issue a "reboot from disk" command -- 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: New 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
