[Bug 2055003] Re: Qemu cmdline core dumped with more(8193 or more) cpus
** Also affects: qemu Importance: Undecided Status: New ** No longer affects: qemu ** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) ** Changed in: qemu (Ubuntu) Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => (unassigned) ** Changed in: ubuntu-power-systems Importance: Undecided => High ** Changed in: qemu (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/2055003 Title: Qemu cmdline core dumped with more(8193 or more) cpus Status in The Ubuntu-power-systems project: New Status in qemu package in Ubuntu: New Bug description: ---Debugger--- A debugger is not configured ---Steps to Reproduce--- ---Problem Description--- Qemu cmdline core dumped with more(8193 or more) cpus ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Qemu cmdline core dumped when more number of CPUs were given. [root@ltcmihawk39 ~]# qemu-system-ppc64 -accel tcg -smp 10,maxcpus=9000 ** ERROR:../tcg/region.c:782:tcg_region_init: assertion failed: (region_size >= 2 * page_size) Bail out! ERROR:../tcg/region.c:782:tcg_region_init: assertion failed: (region_size >= 2 * page_size) Aborted (core dumped) Expected Result: Warning message like "Number of cpus requested exceeds the cpus supported" Actual Result: core dumped Steps to Reproduce: 1. Clone the upstream qemu from https://gitlab.com/qemu-project/qemu.git 2. Compile qemu with below steps. cd qemu/ git submodule init git submodule update --recursive ./configure --target-list=ppc64-softmmu --prefix=/usr make make install 3. set maxcpus=8193 or more [root@ltcmihawk39 ~]# qemu-system-ppc64 --version QEMU emulator version 8.0.94 (v8.1.0-rc4) Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers NOTE: This behavior is observed only when qemu is built without disabling the tcg. Contact Information = sthou...@in.ibm.com Machine Type = x ---uname output--- x Action needed Our IBM Dev want to include this patch in latest Canonical distro. Need the distro to review and integrate fixes provided by IBM https://github.com/qemu/qemu/commit/c4f91d7b7be76c47015521ab0109c6e998a369b0 Need to include this commit in latest Canonical distro. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/2055003/+subscriptions
[Bug 1967814] Re: Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path.
Changing the affected package from "linux (Ubuntu)" (kernel) to "qemu
(Ubuntu)" as affected package, since the attached patch set is for qemu.
** Package changed: linux (Ubuntu) => qemu (Ubuntu)
** Also affects: qemu
Importance: Undecided
Status: New
** No longer affects: qemu
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Changed in: qemu (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => Canonical Server
Team (canonical-server)
** Changed in: ubuntu-z-systems
Importance: Undecided => High
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1967814
Title:
Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having
miscompares on disktests when there is a failed path.
Status in Ubuntu on IBM z Systems:
New
Status in qemu package in Ubuntu:
New
Status in qemu source package in Focal:
New
Bug description:
== Comment: #63 - Halil Pasic - 2022-03-28 17:33:34 ==
I'm pretty confident I've figured out what is going on.
From the guest side, the decision whether the SCSI command was completed
successfully or not comes down to looking at the sense data. Prior to commit
a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers."), we
don't
build sense data as a response to seeing a host status presented by the host
SCSI stack (e.g. kernel).
Thus when the kernel tells us that a given SCSI command did not get
completed via
SCSI_HOST_TRANSPORT_DISRUPTED or SCSI_HOST_NO_LUN, we end up fooling the
guest into believing that the command completed successfully.
The guest kernel, and especially virtio and multipath are at no fault
(AFAIU). Given these facts, it isn't all that surprising, that we end
up with corruptions.
All we have to do is do backports for QEMU (when necessary). I didn't
investigate vhost-scsi -- my guess is, that it ain't affected.
How do we want to handle the back-ports?
== Comment: #66 - Halil Pasic - 2022-04-04 05:36:33 ==
This is a proposed backport containing 7 patches in mbox format. I tried to
pick patches sanely, and all I had to do was basically resolving merge
conflicts.
I have to admit I have no extensive experience in doing such invasive
backports, and my knowledge of the QEMU SCSI stack is very limited. I
would be happy if the Ubuntu folks would have a good look at this, and
if possible improve on it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1967814/+subscriptions
[Bug 1921468] Re: [UBUNTU 20.04] KVM guest fails to find zipl boot menu index
** Also affects: qemu
Importance: Undecided
Status: New
** No longer affects: qemu
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Changed in: qemu (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => Canonical Server
Team (canonical-server)
** Changed in: ubuntu-z-systems
Importance: Undecided => Medium
** Changed in: qemu (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921468
Title:
[UBUNTU 20.04] KVM guest fails to find zipl boot menu index
Status in Ubuntu on IBM z Systems:
New
Status in qemu package in Ubuntu:
New
Bug description:
---Problem Description---
A KVM guest fails to find the zipl boot menu index if the "zIPL" magic value
is listed at the end of a disk block.
---System Hang---
System sits in disabled wait, last console display
LOADPARM=[]
Using virtio-blk.
Using ECKD scheme (block size 4096), CDL
VOLSER=[0X0067]
---Steps to Reproduce---
1. Install Distro KVM guest from ISO on a DASD, e.g. using virt-install, my
invocation was
$ virt-install --name secguest2 --memory 2048 --disk
path=/dev/disk/by-path/ccw-0.0.af6a --cdrom /var/lib/libvirt/images/xx.iso
2. Select DHCP networking and ASCII console, and accept all defaults
of the installer
3. Let the installer reboot after the installation completes
It is possible to recover by editing the domain XML with an explicit loadparm
to select a boot menu entry. E.g. I changed the disk definition to
The patches are now upstream:
5f97ba0c74cc ("pc-bios/s390-ccw: fix off-by-one error")
468184ec9024 ("pc-bios/s390-ccw: break loop if a null block number is
reached")
Current versions of qemu within Ubuntu
focal (20.04LTS) 1:4.2-3ubuntu6 [ports]: arm64 armhf ppc64el s390x
focal-updates (metapackages): 1:4.2-3ubuntu6.14: amd64 arm64 armhf ppc64el
s390x
groovy (20.10) (metapackages): 1:5.0-5ubuntu9 [ports]: arm64 armhf ppc64el
s390x
groovy-updates (metapackages): 1:5.0-5ubuntu9.6: amd64 arm64 armhf ppc64el
s390x
hirsute (metapackages): 1:5.2+dfsg-9ubuntu1: amd64 arm64 armhf ppc64el
s390x
git-commits will apply seamlessley for the requested levels if not already
integrated
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1921468/+subscriptions
[Bug 1920784] Re: qemu-system-ppc64le fails with kvm acceleration
The fix was sent to the kernel teams mailing list: https://lists.ubuntu.com/archives/kernel-team/2021-March/thread.html#118449 ** Changed in: linux (Ubuntu) Status: Confirmed => In Progress ** Changed in: ubuntu-power-systems Status: Confirmed => In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920784 Title: qemu-system-ppc64le fails with kvm acceleration Status in QEMU: Invalid Status in The Ubuntu-power-systems project: In Progress Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Invalid Bug description: (Suspected glibc issue!) qemu-system-ppc64(le) fails when invoked with kvm acceleration with error "illegal instruction" > qemu-system-ppc64(le) -M pseries,accel=kvm Illegal instruction (core dumped) In dmesg: Facility 'SCV' unavailable (12), exception at 0x7624f8134c0c, MSR=9280f033 Version-Release number of selected component (if applicable): qemu 5.2.0 Linux kernel 5.11 glibc 2.33 all latest updates as of submitting the bug report How reproducible: Always Steps to Reproduce: 1. Run qemu with kvm acceleration Actual results: Illegal instruction Expected results: Normal VM execution Additional info: The machine is a Raptor Talos II Lite with a Sforza V1 8-core, but was also observed on a Raptor Blackbird with the same processor. This was also observed on Fedora 34 beta, which uses glibc 2.33 Also tested on ArchPOWER (unofficial port of Arch Linux for ppc64le) with glibc 2.33 Fedora 33 and Ubuntu 20.10, both using glibc 2.32 do not have this issue, and downgrading the Linux kernel from 5.11 to 5.4 LTS on ArchPOWER solved the problem. Kernel 5.9 and 5.10 have the same issue when combined with glibc2.33 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: qemu-system 1:5.2+dfsg-6ubuntu2 ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 Uname: Linux 5.11.0-11-generic ppc64le .sys.firmware.opal.msglog: Error: [Errno 13] Permission denied: '/sys/firmware/opal/msglog' ApportVersion: 2.20.11-0ubuntu60 Architecture: ppc64el CasperMD5CheckResult: pass CurrentDesktop: Unity:Unity7:ubuntu Date: Mon Mar 22 14:48:39 2021 InstallationDate: Installed on 2021-03-22 (0 days ago) InstallationMedia: Ubuntu-Server 21.04 "Hirsute Hippo" - Alpha ppc64el (20210321) KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND ProcKernelCmdLine: root=UUID=f3d03315-0944-4a02-9c87-09c00eba9fa1 ro ProcLoadAvg: 1.20 0.73 0.46 1/1054 6071 ProcSwaps: Filename TypeSizeUsed Priority /swap.img file 8388544 0 -2 ProcVersion: Linux version 5.11.0-11-generic (buildd@bos02-ppc64el-002) (gcc (Ubuntu 10.2.1-20ubuntu1) 10.2.1 20210220, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #12-Ubuntu SMP Mon Mar 1 19:26:20 UTC 2021 SourcePackage: qemu UpgradeStatus: No upgrade log present (probably fresh install) VarLogDump_list: total 0 acpidump: cpu_cores: Number of cores present = 8 cpu_coreson: Number of cores online = 8 cpu_smt: SMT=4 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920784/+subscriptions
[Bug 1920784] Re: qemu-system-ppc64le fails with kvm acceleration
Thx Laurent, I took the hirsute master-next source and cherry-picked the patch and it applied cleanly. Now I kicked off a kernel build of this patched kernel in the following PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1920784 (however, the builds will take some time to complete) If it can be proofed that this patched kernel fixes the problem, I can go ahead and work on a patch submission for hirsute/21.04. (kernel freeze is April 8th) ** Changed in: ubuntu-power-systems Status: New => Confirmed ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Frank Heimes (fheimes) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920784 Title: qemu-system-ppc64le fails with kvm acceleration Status in QEMU: New Status in The Ubuntu-power-systems project: Confirmed Status in glibc package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Confirmed Bug description: (Suspected glibc issue!) qemu-system-ppc64(le) fails when invoked with kvm acceleration with error "illegal instruction" > qemu-system-ppc64(le) -M pseries,accel=kvm Illegal instruction (core dumped) In dmesg: Facility 'SCV' unavailable (12), exception at 0x7624f8134c0c, MSR=9280f033 Version-Release number of selected component (if applicable): qemu 5.2.0 Linux kernel 5.11 glibc 2.33 all latest updates as of submitting the bug report How reproducible: Always Steps to Reproduce: 1. Run qemu with kvm acceleration Actual results: Illegal instruction Expected results: Normal VM execution Additional info: The machine is a Raptor Talos II Lite with a Sforza V1 8-core, but was also observed on a Raptor Blackbird with the same processor. This was also observed on Fedora 34 beta, which uses glibc 2.33 Also tested on ArchPOWER (unofficial port of Arch Linux for ppc64le) with glibc 2.33 Fedora 33 and Ubuntu 20.10, both using glibc 2.32 do not have this issue, and downgrading the Linux kernel from 5.11 to 5.4 LTS on ArchPOWER solved the problem. Kernel 5.9 and 5.10 have the same issue when combined with glibc2.33 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: qemu-system 1:5.2+dfsg-6ubuntu2 ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 Uname: Linux 5.11.0-11-generic ppc64le .sys.firmware.opal.msglog: Error: [Errno 13] Permission denied: '/sys/firmware/opal/msglog' ApportVersion: 2.20.11-0ubuntu60 Architecture: ppc64el CasperMD5CheckResult: pass CurrentDesktop: Unity:Unity7:ubuntu Date: Mon Mar 22 14:48:39 2021 InstallationDate: Installed on 2021-03-22 (0 days ago) InstallationMedia: Ubuntu-Server 21.04 "Hirsute Hippo" - Alpha ppc64el (20210321) KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND ProcKernelCmdLine: root=UUID=f3d03315-0944-4a02-9c87-09c00eba9fa1 ro ProcLoadAvg: 1.20 0.73 0.46 1/1054 6071 ProcSwaps: Filename TypeSizeUsed Priority /swap.img file 8388544 0 -2 ProcVersion: Linux version 5.11.0-11-generic (buildd@bos02-ppc64el-002) (gcc (Ubuntu 10.2.1-20ubuntu1) 10.2.1 20210220, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #12-Ubuntu SMP Mon Mar 1 19:26:20 UTC 2021 SourcePackage: qemu UpgradeStatus: No upgrade log present (probably fresh install) VarLogDump_list: total 0 acpidump: cpu_cores: Number of cores present = 8 cpu_coreson: Number of cores online = 8 cpu_smt: SMT=4 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920784/+subscriptions
[Bug 1920784] Re: qemu-system-ppc64le fails with kvm acceleration
** Also affects: ubuntu-power-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920784 Title: qemu-system-ppc64le fails with kvm acceleration Status in QEMU: New Status in The Ubuntu-power-systems project: New Status in glibc package in Ubuntu: New Status in qemu package in Ubuntu: Confirmed Bug description: (Suspected glibc issue!) qemu-system-ppc64(le) fails when invoked with kvm acceleration with error "illegal instruction" > qemu-system-ppc64(le) -M pseries,accel=kvm Illegal instruction (core dumped) In dmesg: Facility 'SCV' unavailable (12), exception at 0x7624f8134c0c, MSR=9280f033 Version-Release number of selected component (if applicable): qemu 5.2.0 Linux kernel 5.11 glibc 2.33 all latest updates as of submitting the bug report How reproducible: Always Steps to Reproduce: 1. Run qemu with kvm acceleration Actual results: Illegal instruction Expected results: Normal VM execution Additional info: The machine is a Raptor Talos II Lite with a Sforza V1 8-core, but was also observed on a Raptor Blackbird with the same processor. This was also observed on Fedora 34 beta, which uses glibc 2.33 Also tested on ArchPOWER (unofficial port of Arch Linux for ppc64le) with glibc 2.33 Fedora 33 and Ubuntu 20.10, both using glibc 2.32 do not have this issue, and downgrading the Linux kernel from 5.11 to 5.4 LTS on ArchPOWER solved the problem. Kernel 5.9 and 5.10 have the same issue when combined with glibc2.33 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: qemu-system 1:5.2+dfsg-6ubuntu2 ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 Uname: Linux 5.11.0-11-generic ppc64le .sys.firmware.opal.msglog: Error: [Errno 13] Permission denied: '/sys/firmware/opal/msglog' ApportVersion: 2.20.11-0ubuntu60 Architecture: ppc64el CasperMD5CheckResult: pass CurrentDesktop: Unity:Unity7:ubuntu Date: Mon Mar 22 14:48:39 2021 InstallationDate: Installed on 2021-03-22 (0 days ago) InstallationMedia: Ubuntu-Server 21.04 "Hirsute Hippo" - Alpha ppc64el (20210321) KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND ProcKernelCmdLine: root=UUID=f3d03315-0944-4a02-9c87-09c00eba9fa1 ro ProcLoadAvg: 1.20 0.73 0.46 1/1054 6071 ProcSwaps: Filename TypeSizeUsed Priority /swap.img file 8388544 0 -2 ProcVersion: Linux version 5.11.0-11-generic (buildd@bos02-ppc64el-002) (gcc (Ubuntu 10.2.1-20ubuntu1) 10.2.1 20210220, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #12-Ubuntu SMP Mon Mar 1 19:26:20 UTC 2021 SourcePackage: qemu UpgradeStatus: No upgrade log present (probably fresh install) VarLogDump_list: total 0 acpidump: cpu_cores: Number of cores present = 8 cpu_coreson: Number of cores online = 8 cpu_smt: SMT=4 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920784/+subscriptions
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
Maybe this will 'automagically' get fixed and change if MAAS got rebased on LXD. LXD 4.2 comes with KVM support for s390x and the MAAS version that is going to be based on LXD is (iirc) 2.9? -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
I still think that #29 could be a viable fix for this. -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
In between I found the time to setup an env. build upon older releases:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename: bionic
$ dpkg -l | grep -i qemu
ii qemu-block-extra:s390x1:2.11+dfsg-1ubuntu7
s390xextra block backend modules for qemu-system and qemu-utils
ii qemu-kvm 1:2.11+dfsg-1ubuntu7
s390xQEMU Full virtualization on x86 hardware
ii qemu-system-common1:2.11+dfsg-1ubuntu7
s390xQEMU full system emulation binaries (common files)
ii qemu-system-s390x 1:2.11+dfsg-1ubuntu7
s390xQEMU full system emulation binaries (s390x)
ii qemu-utils1:2.11+dfsg-1ubuntu7
s390xQEMU utilities
$ apt-cache policy maas
maas:
Installed: 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1
Candidate: 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1
Version table:
*** 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1 500
500 http://ppa.launchpad.net/maas-maintainers/testing/ubuntu
bionic/main s390x Packages
100 /var/lib/dpkg/status
2.4.2-7034-g2f5deb8b8-0ubuntu1 500
500 http://us.ports.ubuntu.com/ubuntu-ports bionic-updates/main s390x
Packages
500 http://ports.ubuntu.com/ubuntu-ports bionic-updates/main s390x
Packages
500 http://aus.ports.ubuntu.com/ubuntu-ports bionic-updates/main s390x
Packages
2.4.0~beta2-6865-gec43e47e6-0ubuntu1 500
500 http://us.ports.ubuntu.com/ubuntu-ports bionic/main s390x Packages
500 http://ports.ubuntu.com/ubuntu-ports bionic/main s390x Packages
In this environment MAAS is not able to Commission ("Failed commissioning").
Trying to start the vm manually with virsh ends up with:
$ virsh start vm1 --console
Domain vm1 started
Connected to domain vm1
Escape character is ^]
done
Using IPv4 address: 192.168.122.102
Requesting file "boots390x.bin" via TFTP from 192.168.122.1
Receiving data: 0 KBytesfile not found: boots390x.bin
Failed to load OS from network
So that is expecting, since the qemu packages version 1:2.11+dfsg-
1ubuntu7 were initially used - the GA version, that's not known to work
- the needed patch came later.
The first qemu packages that should be good are the ones with version
1:2.11+dfsg-1ubuntu7.7.
But (after discussing with cpaelzer) the qemu packages didn't really changed
since 1:2.11+dfsg-1ubuntu7.7, I thought that I now upgrade to the latest ones
(1:2.11+dfsg-1ubuntu7.22):
$ sudo apt install qemu-block-extra qemu-kvm qemu-system-common
qemu-system-s390x qemu-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
debootstrap
Recommended packages:
sharutils
The following packages will be upgraded:
qemu-block-extra qemu-kvm qemu-system-common qemu-system-s390x qemu-utils
5 upgraded, 0 newly installed, 0 to remove and 167 not upgraded.
Need to get 3,249 kB of archives.
After this operation, 32.8 kB of additional disk space will be used.
Get:1 http://us.ports.ubuntu.com/ubuntu-ports bionic-proposed/main s390x
qemu-utils s390x 1:2.11+dfsg-1ubuntu7.22 [811 kB]
Get:2 http://us.ports.ubuntu.com/ubuntu-ports bionic-proposed/main s390x
qemu-system-common s390x 1:2.11+dfsg-1ubuntu7.22 [671 kB]
Get:3 http://us.ports.ubuntu.com/ubuntu-ports bionic-proposed/main s390x
qemu-block-extra s390x 1:2.11+dfsg-1ubuntu7.22 [37.3 kB]
Get:4 http://us.ports.ubuntu.com/ubuntu-ports bionic-proposed/main s390x
qemu-kvm s390x 1:2.11+dfsg-1ubuntu7.22 [12.5 kB]
Get:5 http://us.ports.ubuntu.com/ubuntu-ports bionic-proposed/main s390x
qemu-system-s390x s390x 1:2.11+dfsg-1ubuntu7.22 [1,717 kB]
Fetched 3,249 kB in 0s (8,360 kB/s)
(Reading database ... 67530 files and directories currently installed.)
Preparing to unpack .../qemu-utils_1%3a2.11+dfsg-1ubuntu7.22_s390x.deb ...
Unpacking qemu-utils (1:2.11+dfsg-1ubuntu7.22) over (1:2.11+dfsg-1ubuntu7) ...
Preparing to unpack .../qemu-system-common_1%3a2.11+dfsg-1ubuntu7.22_s390x.deb .
..
Unpacking qemu-system-common (1:2.11+dfsg-1ubuntu7.22) over (1:2.11+dfsg-1ubuntu
7) ...
Preparing to unpack .../qemu-block-extra_1%3a2.11+dfsg-1ubuntu7.22_s390x.deb ...
Unpacking qemu-block-extra:s390x (1:2.11+dfsg-1ubuntu7.22) over (1:2.11+dfsg-1ub
untu7) ...
Preparing to unpack .../qemu-kvm_1%3a2.11+dfsg-1ubuntu7.22_s390x.deb ...
Unpacking qemu-kvm (1:2.11+dfsg-1ubuntu7.22) over (1:2.11+dfsg-1ubuntu7) ...
Preparing to unpack .../qemu-system-s390x_1%3a2.11+dfsg-1ubuntu7.22_s390x.deb ..
.
Unpacking qemu-system-s390x (1:2.11+dfsg-1ubuntu7.22) over (1:2.11+dfsg-1ubuntu7
) ...
Setting up qemu-block-extra:s390x (1:2.11+dfsg-1ubuntu7.22) ...
Setting up qemu-utils (1:2.11+dfsg-1ubuntu7.22) ...
Processing triggers for man-db (2.8.3-2) ...
Setting up qemu-system-common (1:2.11+dfsg-1ubuntu7.22) ...
Setting up
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
@Lee, do you think that the boot log from comment #18 looks fine? https://bugs.launchpad.net/ubuntu-z-systems/+bug/1859656/+attachment/5323507/+files/boot_console.txt What would be the usual next step for MAAS KVM on s390x if the above is successful (me not really knowing the exact internal flow)? Is it then netbooting again and redirecting to the disk (same on all platforms)? -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
I doubled check today again with sfeole and he confirmed that it worked for him as well (and not only for me) when he just started using MAAS KVM on s390x and had his initial setup... Anyway, I'm now sure on how much effort we should spent on recreating the old situation (I may try some old qemu/libvirt version - in case they are still available and in the archive -- maybe MAAS pulls in further packages that need to be back-dated, too ?!), but I think in parallel we should check if this can be solve on the latest MAAS versions, to get the kt testing unblocked. Is there an option to make it work - like with MAAS changing the xml config? I think that an upstream solution for LP 1736511 will just take way to long ... -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
It took some time (due to travel), but I was now able to do a setup based on the old 2.6.0 version [2.6.0 (7803-g6fc5f26eb- 0ubuntu1~18.04.1)] for testing. And with the combination: $ apt-cache policy maas maas: Installed: 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1 Candidate: 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1 Version table: *** 2.6.0-7803-g6fc5f26eb-0ubuntu1~18.04.1 500 500 http://ppa.launchpad.net/maas-maintainers/testing/ubuntu bionic/main s390x Packages 100 /var/lib/dpkg/status 2.4.2-7034-g2f5deb8b8-0ubuntu1 500 500 http://us.ports.ubuntu.com/ubuntu-ports bionic-updates/main s390x Packages 2.4.0~beta2-6865-gec43e47e6-0ubuntu1 500 500 http://us.ports.ubuntu.com/ubuntu-ports bionic/main s390x Packages and: $ apt-cache policy qemu qemu: Installed: (none) Candidate: 1:2.11+dfsg-1ubuntu7.21 Version table: 1:2.11+dfsg-1ubuntu7.21 500 500 http://us.ports.ubuntu.com/ubuntu-ports bionic-updates/universe s390x Packages 1:2.11+dfsg-1ubuntu7.20 500 500 http://ports.ubuntu.com/ubuntu-ports bionic-security/universe s390x Packages 1:2.11+dfsg-1ubuntu7 500 500 http://us.ports.ubuntu.com/ubuntu-ports bionic/universe s390x Packages the system seems to successful commissions, similar to the latest maas 2.6.2 version (see above). But then the VM ends again in state Ready / off. virsh shows the VM as shutoff: ubuntu@s1lp11:~$ sudo -H -u maas bash -c 'virsh -c qemu+ssh://ubuntu@192.168.122.1/system list --all' ubuntu@192.168.122.1's password: IdName State - vm1shut off The os element looks like this - with the two entries: hvm A manual start (with the help of virsh, console enabled) shows that it network boots (see attachment). Removing the network entry and booting didn't work - looks like no OS deployed on disk yet. To sum it up - also not working on this 2.6.0 env. that I've just created. ** Attachment added: "boot_console.txt" https://bugs.launchpad.net/ubuntu-z-systems/+bug/1859656/+attachment/5323507/+files/boot_console.txt -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
The general issue with multiple boot elements on s390x was indeed already identified back in 2017, and a ticket was opened and reverse mirrored to IBM (so it should never have worked that way): LP 1736511 (and btw. RH ticket is referenced there as well) -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
I took the time and recreated a MAAS setup (latest stable 2.2) on s390x and it looks like this: - I could start a deployment and ran through the states: - Power On, Commissioning (Performing PXE boot) - Power On, Commissioning (Gathering Information) - Power On, Ready - Power Off, Ready (I may have have missed some states in between.) - Power Off, Ready is the final state at that point and on the console it's: $ virsh list --all IdName State - vm1shut off - xml VM definition is: $ virsh dumpxml vm1 vm1 0f7d1d61-9368-4bfe-8c65-c709e90e8780 1048576 1048576 1 hvm destroy restart destroy /usr/bin/kvm 6addbfeb-ff2c-4350-b34d-11a56ea34f1d So it largely looks like assumed (after initially reading the bug), PXE itself seems to work, but the boot issue it due to: That confirms the situation (on s390x and MAAS 2.6.2)m but it still raises the question why it seem to have worked with 2.6.0? -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
** Tags added: s390x -- 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
[Bug 1859656] Re: [2.6] Unable to reboot s390x KVM machine after initial deploy
** Changed in: maas Status: Incomplete => New -- 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
[Bug 1852781] Re: qemu s390x on focal - applications breaking
** Tags added: qemu-20.04 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1852781 Title: qemu s390x on focal - applications breaking Status in QEMU: Incomplete Status in Ubuntu on IBM z Systems: Incomplete Bug description: Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering random breakage, for example: sudo apt-get update && sudo apt-get dist-upgrade ... ... Unpacking debianutils (4.9) over (4.8.6.3) ... Setting up debianutils (4.9) ... Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 43. (Reading database ... 83640 files and directories currently installed.) Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ... Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ... Setting up bash (5.0-5ubuntu1) ... [12124.788618] User process fault: interruption code 0007 ilc:3 in bash[2aa3d78+149000] dpkg: error processing package bash (--configure): installed bash package post-installation script subprocess was killed by signal (Floating point exception), core du mped Errors were encountered while processing: bash E: Sub-process /usr/bin/dpkg returned an error code (1) And now bash is completely broken: cking@eoan-s390x:~$ bash [12676.204389] User process fault: interruption code 0007 ilc:3 in bash[2aa1478+149000] Floating point exception (core dumped) The upgrade works OK on a s390x, so I'm assuming it's something to do with the qemu emulation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1852781/+subscriptions
[Bug 1852781] Re: qemu s390x on focal - applications breaking
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1852781 Title: qemu s390x on focal - applications breaking Status in QEMU: Incomplete Status in Ubuntu on IBM z Systems: Incomplete Bug description: Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering random breakage, for example: sudo apt-get update && sudo apt-get dist-upgrade ... ... Unpacking debianutils (4.9) over (4.8.6.3) ... Setting up debianutils (4.9) ... Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 43. (Reading database ... 83640 files and directories currently installed.) Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ... Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ... Setting up bash (5.0-5ubuntu1) ... [12124.788618] User process fault: interruption code 0007 ilc:3 in bash[2aa3d78+149000] dpkg: error processing package bash (--configure): installed bash package post-installation script subprocess was killed by signal (Floating point exception), core du mped Errors were encountered while processing: bash E: Sub-process /usr/bin/dpkg returned an error code (1) And now bash is completely broken: cking@eoan-s390x:~$ bash [12676.204389] User process fault: interruption code 0007 ilc:3 in bash[2aa1478+149000] Floating point exception (core dumped) The upgrade works OK on a s390x, so I'm assuming it's something to do with the qemu emulation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1852781/+subscriptions
[Bug 1852781] Re: qemu s390x on focal - applications breaking
** Tags added: s390x -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1852781 Title: qemu s390x on focal - applications breaking Status in QEMU: Incomplete Bug description: Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering random breakage, for example: sudo apt-get update && sudo apt-get dist-upgrade ... ... Unpacking debianutils (4.9) over (4.8.6.3) ... Setting up debianutils (4.9) ... Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 43. (Reading database ... 83640 files and directories currently installed.) Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ... Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ... Setting up bash (5.0-5ubuntu1) ... [12124.788618] User process fault: interruption code 0007 ilc:3 in bash[2aa3d78+149000] dpkg: error processing package bash (--configure): installed bash package post-installation script subprocess was killed by signal (Floating point exception), core du mped Errors were encountered while processing: bash E: Sub-process /usr/bin/dpkg returned an error code (1) And now bash is completely broken: cking@eoan-s390x:~$ bash [12676.204389] User process fault: interruption code 0007 ilc:3 in bash[2aa1478+149000] Floating point exception (core dumped) The upgrade works OK on a s390x, so I'm assuming it's something to do with the qemu emulation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1852781/+subscriptions
[Bug 1842774] Re: Enhanced Hardware Support - Finalize Naming
** Information type changed from Private to Public -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1842774 Title: Enhanced Hardware Support - Finalize Naming Status in QEMU: Incomplete Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Disco: In Progress Bug description: SRU Justification: == [Impact] * Add / activate support for IBM z15 and LinuxONE III systems [Fix] * a0e2251132995b962281aa80ab54a9288f9e0b6b a0e2251 "s390: add support for IBM z15 machines" [Test Case] * check and verify cpuinfo - regression testing is possible by Canonical/me * functional testing is currently only doable by IBM [Regression Potential] * There is regression potential with having new code in and the flags added/active * but the code changes are pretty straight forward, just add config, cases and defs * and are not used on existing systems, just on the new generation that is not yet out in the field [Other Info] * SRU of LP 1842916 merged with (this) LP 1842774 __ This feature request will provide the final naming of the next machine To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1842774/+subscriptions
[Bug 1842916] Re: [18.04 FEAT] Enhanced Hardware Support - Finalize Naming
*** This bug is a duplicate of bug 1842774 *** https://bugs.launchpad.net/bugs/1842774 ** Information type changed from Private to Public -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1842916 Title: [18.04 FEAT] Enhanced Hardware Support - Finalize Naming Status in QEMU: Incomplete Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: New Bug description: This feature request will provide the final naming of the next machine To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1842916/+subscriptions
[Qemu-devel] [Bug 1801674] Re: Ubuntu16.04 LTS - PCI Pass Through in Ubuntu KVM 16.04.x must use QEMU with DDW support from PPA
** Also affects: qemu Importance: Undecided Status: New ** No longer affects: qemu ** Also affects: ubuntu-power-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1801674 Title: Ubuntu16.04 LTS - PCI Pass Through in Ubuntu KVM 16.04.x must use QEMU with DDW support from PPA Status in The Ubuntu-power-systems project: New Status in qemu package in Ubuntu: New Bug description: == Comment: #0 - Siraj M. Ismail - 2016-10-05 11:35:38 == ---Problem Description--- Customer running PCI pass through with 16.04.1 KVM and with the stock QEMU packages will hit a DI if they do not update to the QEMU packages with DDW support. The packages are in PPA for customers to download, and test has verified the fix. The details are in Bugzilla 144123. ---uname output--- Ubuntu 16.04.1 with 4.4.0 Kernel Machine Type = 8247-22L ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Run guest with adapters assigned via PCI PT, The guest will start having DI issues as soon as I/O started on the Pass Through adapter. Contact Information = sir...@us.ibm.com ---Patches Installed--- QEMU was updated from 2.5 version to 2.6.1 with patches for DDW support, can be found at PPA location : https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw Userspace tool common name: QEMU Documentation version: N/A The userspace tool has the following bit modes: N/A Userspace rpm: N/A Userspace tool obtained from project website: na *Additional Instructions for sir...@us.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. -Attach ltrace and strace of userspace application. == Comment: #5 - Leonardo Augusto Guimaraes Garcia - 2017-04-25 16:23:57 == I would rephrase to: --- Under KVM recommendations PCI passthrough recommendations If you are running PCI passthrough with 16.04.x KVM and with the stock QEMU package, update to the QEMU package that have DDW support. If you do not update the package, you will hit data integrity issues as soon as I/O is started on the adapter. The package is available at: https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw --- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1801674/+subscriptions
[Qemu-devel] [Bug 1779162] Re: qemu versions 2.10 and 2.11 have error during migration of larger guests
** Also affects: qemu
Importance: Undecided
Status: New
** No longer affects: qemu
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Importance: Undecided => Critical
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1779162
Title:
qemu versions 2.10 and 2.11 have error during migration of larger
guests
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu on IBM z Systems:
New
Status in qemu package in Ubuntu:
Fix Released
Status in qemu source package in Artful:
Won't Fix
Bug description:
== Comment: #0 - Christian Borntraeger - 2018-06-28 06:39:27 ==
Migration fails with larger guests (e.g. 10GB) on a z system prints an error
message in the log
see /var/log/libvirt/qemu/...
[...]
qemu-system-s390x: KVM_S390_SET_CMMA_BITS failed: Bad address
This messes up guest state for the CMMA values (guest data corruption)
This is fixed with
commit 46fa893355e0bd88f3c59b886f0d75cbd5f0bbbe
Author: Claudio Imbrenda
AuthorDate: Thu Jan 18 18:51:44 2018 +0100
Commit: Cornelia Huck
CommitDate: Mon Jan 22 11:04:52 2018 +0100
s390x: fix storage attributes migration for non-small guests
Fix storage attribute migration so that it does not fail for guests
with more than a few GB of RAM.
With such guests, the index in the buffer would go out of bounds,
usually by large amounts, thus receiving -EFAULT from the kernel.
Migration itself would be successful, but storage attributes would then
not be migrated completely.
This patch fixes the out of bounds access, and thus migration of all
storage attributes when the guest have large amounts of memory.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Claudio Imbrenda
Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device")
Message-Id:
<1516297904-18188-1-git-send-email-imbre...@linux.vnet.ibm.com>
Reviewed-by: Christian Borntraeger
Signed-off-by: Cornelia Huck
This fix is part of 2.11.1 so the qemu in bionic is fine.
The qemu in artful, as well as the qemu in the cloud archives for 16.04 need
this fix, so we have
affected qemus in 17.10 and 16.04.
Regarding 16.04:
The bug only triggers for host kernels >= 4.13 - in other words when you
combine HWE kernel with the qemu from the cloud archive.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1779162/+subscriptions
