** Description changed: + [Impact] - [Impact] + * When reading boot and boot-menu information from a block device (like a + passed through dasd) the bootloader can stumble over some data + structures due to mistakes in the code. - * When reading boot and boot-menu information from a block device (like a - passed through dasd) the bootloader can stumble over some data - structures due to mistakes in the code. - - * The fix is to improve the bootloader code to no more fail in those - situations. The fixes are upstream for a while, small and well - reviewable + * The fix is to improve the bootloader code to no more fail in those + situations. The fixes are upstream for a while, small and well + reviewable [Test Plan] - * The bad-case triggers when boot menu entries are in a given form. There - is this fix applied here to be able to handle those, but there are also - fixes to src:s390-tools to have zipl not write those hard-to-handle - entries. Due to that only zipl versions 2.12/2.13 (in the KVM guest) - should cause issues, and also then only in some combinations of - zipl.conf entries. - The best known case to reliable trigger it can feel a bit cubersome for - a Ubuntu user as it includes usage of a suse installation media - SLE-15-SP2-Full-s390x-GM-Media1.iso that happens to - bring the combinatino triggering this. - Based on the guest code, focal guests would be affected as well, but we - haven't found (nor searched) which zipl.conf we'd need to recreate it - there. - IBM will do the tests as they have doen when finding this issues as - they have the suse ISOs triggering this reliably. + * The bad-case triggers when boot menu entries are in a given form. There + is this fix applied here to be able to handle those, but there are also + fixes to src:s390-tools to have zipl not write those hard-to-handle + entries. Due to that only zipl versions 2.12/2.13 (in the KVM guest) + should cause issues, and also then only in some combinations of + zipl.conf entries - finally it also could depend on the build toolchain + of the guest. + The best known case to reliable trigger it can feel a bit cubersome for + a Ubuntu user as it includes usage of a suse installation media + SLE-15-SP2-Full-s390x-GM-Media1.iso that happens to + bring the combinatino triggering this. + Based on the guest code, focal guests would be affected as well, but we + haven't found (nor searched) which zipl.conf we'd need to recreate it + there. + IBM will do the tests as they have doen when finding this issues as + they have the suse ISOs triggering this reliably. [Where problems could occur] - * Issues would be s390x only and bootup-only which already is a very - narrow field one can easily look for in coming bug reports. - In that area the thing one can think of is e.g. special bootloader - configs (many entries, long entries, ...) that might now fail to be - handled correctly. + * Issues would be s390x only and bootup-only which already is a very + narrow field one can easily look for in coming bug reports. + In that area the thing one can think of is e.g. special bootloader + configs (many entries, long entries, ...) that might now fail to be + handled correctly. [Other Info] - - * Suse iso can be downloaded (behind license - free trial - wall) from - https://www.suse.com/download/sles/ + * Suse iso can be downloaded (behind license - free trial - wall) from + https://www.suse.com/download/sles/ ---- - ---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/xxxxxx.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 <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/disk/by-path/ccw-0.0.af6a'/> <target dev='vda' bus='virtio'/> <boot order='1' loadparm='1'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0xaf6a'/> </disk> 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
** Description changed: [Impact] * When reading boot and boot-menu information from a block device (like a passed through dasd) the bootloader can stumble over some data structures due to mistakes in the code. * The fix is to improve the bootloader code to no more fail in those situations. The fixes are upstream for a while, small and well reviewable [Test Plan] * The bad-case triggers when boot menu entries are in a given form. There is this fix applied here to be able to handle those, but there are also fixes to src:s390-tools to have zipl not write those hard-to-handle entries. Due to that only zipl versions 2.12/2.13 (in the KVM guest) should cause issues, and also then only in some combinations of - zipl.conf entries - finally it also could depend on the build toolchain - of the guest. + zipl.conf entries - finally it also could depend on the build toolchain + of the guest. The best known case to reliable trigger it can feel a bit cubersome for a Ubuntu user as it includes usage of a suse installation media SLE-15-SP2-Full-s390x-GM-Media1.iso that happens to bring the combinatino triggering this. Based on the guest code, focal guests would be affected as well, but we haven't found (nor searched) which zipl.conf we'd need to recreate it there. IBM will do the tests as they have doen when finding this issues as they have the suse ISOs triggering this reliably. + See below for a ste by step test from the initial report. [Where problems could occur] * Issues would be s390x only and bootup-only which already is a very narrow field one can easily look for in coming bug reports. In that area the thing one can think of is e.g. special bootloader configs (many entries, long entries, ...) that might now fail to be handled correctly. [Other Info] * Suse iso can be downloaded (behind license - free trial - wall) from https://www.suse.com/download/sles/ ---- ---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/xxxxxx.iso + $ virt-install --name secguest2 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.af6a --cdrom /var/lib/libvirt/images/SLE-15-SP2-Full-s390x-GM-Media1.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 <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/disk/by-path/ccw-0.0.af6a'/> <target dev='vda' bus='virtio'/> <boot order='1' loadparm='1'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0xaf6a'/> </disk> 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921468 Title: [UBUNTU 20.04] KVM guest fails to find zipl boot menu index To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1921468/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
