It would appear that this bug is once again causing problems with some of our automated testing.
S390x KVM deployments are failing for Focal. When attempting to investigate a big I found that it is indeed this bug.
Our MAAS Server is Version:
maas:
Installed: 2.7.0-8232-g.6e1dba4ab-0ubuntu1~18.04.1
Candidate: 2.7.0-8232-g.6e1dba4ab-0ubuntu1~18.04.1
Version table:
I've attached the console log of the -KVM machine deploying.
On MAAS the rack controller reports the following:
sfeole@bsg75:~$ cat focal-s390x-maas.txt
==> rackd.log <==
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] boots390x.bin requested by 10.246.75.177
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.177
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.177
==> regiond.log <==
2020-04-09 14:14:59 maasserver.rpc.leases: [info] Lease update: commit for 10.246.75.177 on 52:54:0:e5:d7:bb at 2020-04-09 14:14:59 (lease time: 600s)
==> rackd.log <==
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BB1 requested by 10.246.75.177
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BB requested by 10.246.75.177
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/0AF64B requested by 10.246.75.177
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 requested by 10.246.75.177
2020-04-09 14:14:59 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 requested by 10.246.75.177
2020-04-09 14:15:00 provisioningserver.rackdservices.tftp: [info] s390x/0AF requested by 10.246.75.177
2020-04-09 14:15:00 provisioningserver.rackdservices.tftp: [info] s390x/0A requested by 10.246.75.177
2020-04-09 14:15:00 provisioningserver.rackdservices.tftp: [info] s390x/0 requested by 10.246.75.177
2020-04-09 14:15:00 provisioningserver.rackdservices.tftp: [info] s390x/default requested by 10.246.75.177
It would appear that this bug is once again causing problems with some of our automated testing.
S390x KVM deployments are failing for Focal. When attempting to investigate a big I found that it is indeed this bug.
Our MAAS Server is Version:
maas: g.6e1dba4ab- 0ubuntu1~ 18.04.1 g.6e1dba4ab- 0ubuntu1~ 18.04.1
Installed: 2.7.0-8232-
Candidate: 2.7.0-8232-
Version table:
I've attached the console log of the -KVM machine deploying.
On MAAS the rack controller reports the following: maas.txt ver.rackdservic es.tftp: [info] boots390x.bin requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/65a9ca43- 9541-49be- b315-e2ca85936e a2 requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/01- 52-54-00- e5-d7-bb requested by 10.246.75.177
sfeole@bsg75:~$ cat focal-s390x-
==> rackd.log <==
2020-04-09 14:14:59 provisioningser
2020-04-09 14:14:59 provisioningser
2020-04-09 14:14:59 provisioningser
==> regiond.log <== rpc.leases: [info] Lease update: commit for 10.246.75.177 on 52:54:0:e5:d7:bb at 2020-04-09 14:14:59 (lease time: 600s)
2020-04-09 14:14:59 maasserver.
==> rackd.log <== ver.rackdservic es.tftp: [info] s390x/0AF64BB1 requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0AF64BB requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0AF64B requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0AF64 requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0AF6 requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0AF requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0A requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/0 requested by 10.246.75.177 ver.rackdservic es.tftp: [info] s390x/default requested by 10.246.75.177
2020-04-09 14:14:59 provisioningser
2020-04-09 14:14:59 provisioningser
2020-04-09 14:14:59 provisioningser
2020-04-09 14:14:59 provisioningser
2020-04-09 14:14:59 provisioningser
2020-04-09 14:15:00 provisioningser
2020-04-09 14:15:00 provisioningser
2020-04-09 14:15:00 provisioningser
2020-04-09 14:15:00 provisioningser