How to use s390x pxelinux style network booting from qemu 3.0 in bionic

Bug #1790901 reported by Andres Rodriguez
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Fix Released
High
Unassigned
qemu (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Undecided
Unassigned

Bug Description

[Impact]

 * The netboot capability in qemu 2.11/2.12 are incomplete, they follow
   an uncommon path of prebuilt binaries that bundle kernel/initrd/config
   into one image and that can be booted.
   To fully exploit the new (virtial) HW capability as it was planned for
   18.04 initially we'd need more.

 * In qemu 3.0 the code finalized implementing real "standard" PXE boot
   capabilities. That is of a high demand to now be available back to at
   least 18.04. Not limited to, but for example for solutions like MAAS
   that rely on PXE.

 * This is IMHO checking multiple boxes of the "safe cases" of the SRU
   policy [1]. To some extend it touches:
   1. "affect an application rather than critical infrastructure" by
       modifying only the s390x netboot feature
   2. "For Long Term Support releases we regularly want to enable new
       hardware" while here it is virtual hardware that we want to enable.
   But the closest match of these rules is:
   3. "Long Term Support releases we sometimes want to introduce new
      features". It qualifies for the statements there of being
      unintrusive, tested and not changing other parts.

[Test Case]

 * Follow this blog that we wrote for the old version [2], but requiring
   much less steps.
   Follow steps:
    "Prepare a tftp server" (install and configure tftp)
    "Prepare libvirt network to provide PXE" (tftp and bootp entries)
    "Prepare guest definition" (<boot dev='network'/>)
   Then create a pxlinux.cfg entry matching the ID of the guest (if u
    $ cat /tftpboot/pxelinux.cfg/b785659a-a351-490b-a0b7-d4bf6610419d
      kernel kernel.ubuntu
      initrd initrd.ubuntu
      append testparm1=foo testparm2=bar
   If you don't know the ID you can use MAC, UUID or other things - just
   boot the guest without config and you will see the ID

   Finally boot the guest with a console attached immediately to see PXE
   in action.
    $ virsh start --console <guestname>

 * these should allow someone who is not familiar with the affected
   package to reproduce the bug and verify that the updated package fixes
   the problem.

[Regression Potential]

 * There are three ways to look at that in regard to regression potential.
   1. What should it affect
      It affects the netboot capabilities of qemu for s390x. There are no
      known users of the feature as it is today due to it's current
      limitations. Even with the change it could still boot the squashed
      binary that it can today, although being so "uncomfortable" we
      expect no one to do so.
      There could be cases where former PXE setups using the old technique
      would have to be slightly adapted to work with the new one. But all
      partners and peers related to this expressed that the current one is
      almost unusable and they'd want the new one.
      Therefor this potential regression is minor and worth to take for
      the benefits to make the feature really usable.
   2. What it could affect
      Due to the fact which code changed and what is build from it (only
      s390x ROMs) the one things that might regress in case we missed
      something in backport and tests is the local boot from s390-ccw.img
      We checked multiple times in review and tested it to ensure that
      there should be nothing that breaks/changes in there.
   3. What it should not affect
      Everything else that "could" be built from the modified source
      is not built (as it is split to src:slof), therefore no influence
      there.

[Other Info]

 * I filed no FFE [3] as the rules for an SRU are harder and it qualifies
   for that. Also since without an FFE we'd most likely "just SRU it
   later" IMHO there is no point in an FF-Block on this bug.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
[2]: https://blog.ubuntu.com/2017/12/20/early-experiences-with-pxe-net-boot-of-kvm-vms-on-ubuntu-for-s390x
[3]: https://wiki.ubuntu.com/FreezeExceptionProcess

---

QEMU 3.0 has recently released with support for pxelinux style network booting from s390x.

As part of the MAAS roadmap, we have an item to enable s390x as a supported architecture for deployment of KVM image. Since QEMU now includes that support upstream, we would like an evaluation of whether it would be possible to backport this feature back to Bionic's QEMU to avoid having to create a work around in MAAS that are not supported upstream.

Note that the MAAS team has not tested this feature.

https://wiki.qemu.org/ChangeLog/3.0#s390_firmware

Related branches

description: updated
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
this would not only require a backport that seems hard (plenty of other cleanups/fixes to pc-bios/s390-ccw) but doable eventually with some extra work.
That part of it would be SRUable if we want to spend all the effort as it only fixes/improves the s390x netboot capabilities.

The initial netboot capabilities were only added in the 2.12 version (Cosmic) so we'd also need all the packaging changes.
That includes bringing back SLOF headers of the right version.

And with SLOF we have the biggest issue, for this to actually work we'd have to also bump SLOF quite a lot. Now that is a problem for many potential issues between the binary SLOF and ppc-qemu working against it vs the in-qemu-source SLOF that s390x needs to build the pxelinux.

Together the effort is high and the regression risk even higher, if I'd be SRU team I'd nack it so we might waste all the effort.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I'm checking with the Authors if we could just provide the lates netboot image and use it with the older qemu 2.11 (s390x-netboot as extra pkg in backports maybe).

Frank Heimes (fheimes)
tags: added: s390x
Revision history for this message
Andres Rodriguez (andreserl) wrote : Re: [Bug 1790901] Re: Backporting s390x pxelinux style network booting from qemu 3.0 to bionic

What about getting qemu 3.0 into cosmic?

On Thu, Sep 6, 2018 at 2:41 AM  Christian Ehrhardt  <
<email address hidden>> wrote:

> Hi,
> this would not only require a backport that seems hard (plenty of other
> cleanups/fixes to pc-bios/s390-ccw) but doable eventually with some extra
> work.
> That part of it would be SRUable if we want to spend all the effort as it
> only fixes/improves the s390x netboot capabilities.
>
> The initial netboot capabilities were only added in the 2.12 version
> (Cosmic) so we'd also need all the packaging changes.
> That includes bringing back SLOF headers of the right version.
>
> And with SLOF we have the biggest issue, for this to actually work we'd
> have to also bump SLOF quite a lot. Now that is a problem for many
> potential issues between the binary SLOF and ppc-qemu working against it
> vs the in-qemu-source SLOF that s390x needs to build the pxelinux.
>
> Together the effort is high and the regression risk even higher, if I'd
> be SRU team I'd nack it so we might waste all the effort.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1790901
>
> Title:
> Backporting s390x pxelinux style network booting from qemu 3.0 to
> bionic
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1790901/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=qemu; component=main;
> status=New; importance=Undecided; assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl paelzer
> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
> Launchpad-Bug-Modifier:  Christian Ehrhardt  (paelzer)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Re: Backporting s390x pxelinux style network booting from qemu 3.0 to bionic

There was no obvious obstacle that came to our mind blocking the new netboot image to be used on the older qemu. If working Maas could package that as a helper for s390x until later versions (>=DD) would provide their own one.

Next: I need to give this a try at some point to check if it is working - since that needs quite some setup and I don't get to it like "now" it will take a while.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Re: [Bug 1790901] Re: Backporting s390x pxelinux style network booting from qemu 3.0 to bionic

On Thu, Sep 6, 2018 at 9:01 AM Andres Rodriguez <email address hidden>
wrote:

> What about getting qemu 3.0 into cosmic?
>

Options:
- SRU-ing qemu 3.0 to Bionic - obviously not, not even discussing this
- It will most likely be available via Ubuntu-Cloud-Archive-Stein (based on
DD) later on next cycle.
- 3.0 in a PPA for you with less strict maintenance/service than the
Archive maybe.
- but if we 'd only need the netboot image instead of a full qemu 3.0 that
would be much much easier IMHO

Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Re: Backporting s390x pxelinux style network booting from qemu 3.0 to bionic

Oh you wrote cosmic (probably because the initial request was on bionic), well not too bad to have the answer for both.
Thanks @xnox for spotting my initial misreading of the release.

So for cosmic it would be:
- qemu 3.0 to Cosmic - Well beyond FF, no
- SRU-ing qemu 3.0 to Cosmic - obviously not
- 3.0 in a Cosmic-PPA for you with less strict maintenance/service than the
Archive maybe.
- but if we 'd only need the netboot image instead of a full qemu 3.0 that
would be much much easier IMHO

That overall is about the same I'd think.
But reading "into cosmic" while your initial request was for Bionic - what is the actual target?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I intend to test the new netboot image on the qemu that we have, so knowing if it has to be Bionic (2.11) or can be Cosmic (2.12) makes a difference.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

You are the tftp/pxelinux experts more than I am.
I follow our tftp and libvirt setup as in [1]

But instead of building a complex single purpose pxelinux.0

All the new "code" youneed is actually inside that boot image.
So no need to build huge things, instead replace
  /usr/share/qemu/s390-netboot.img
with the one from upstream
  https://git.qemu.org/?p=qemu.git;a=blob_plain;f=pc-bios/s390-netboot.img;hb=HEAD

This works Bionics Qemu well.

Now I can now just use kernel/initrd and pxeconfig as "usual"
  $ sudo cp /boot/vmlinuz-4.15.0-33-generic /srv/tftp/
  $ sudo cp /boot/initrd.img-4.15.0-33-generic /srv/tftp/

Then I put this in my config for pxelinux:
$ cat pxelinux.cfg/default
label ubuntu
   kernel vmlinuz-4.15.0-33-generic
   initrd initrd.img-4.15.0-33-generic
   append root=/dev/vda1

Starting the guest from that:

$ virsh start netboot --console
Domain netboot started
Connected to domain netboot
Escape character is ^]
  Using MAC address: 52:54:00:1e:b5:2a
  Requesting information via DHCP: done
  Using IPv4 address: 192.168.122.222
  Using TFTP server: 192.168.122.1
  Bootfile name: 'pxelinux.0'
  Receiving data: 0 KBytes
  TFTP error: file not found: pxelinux.0
Trying pxelinux.cfg files...
  Receiving data: 0 KBytes
  TFTP: Received pxelinux.cfg/default (113 bytes)
Loading pxelinux.cfg entry 'ubuntu'
  Receiving data: 4292 KBytes
  TFTP: Received vmlinuz-4.15.0-33-generic (4292 KBytes)
  Receiving data: 16763 KBytes
  TFTP: Received initrd.img-4.15.0-33-generic (16763 KBytes)
Network loading done, starting kernel...

[ 0.425566] Linux version 4.15.0-33-generic (buildd@bos02-s390x-010) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 (Ubuntu 4.15.0-33.36-generic 4.15.18)
[ 0.425572] setup.289988: Linux is running under KVM in 64-bit mode

You know much better than I do how to control the PXE details.
I think this gets you going without massive PPAs/Backport needs at all right?

I will set "invalid" (as no source change is needed) and modify the title a bit to match the solution.

I'll keep my test env up for the sprint so that we can try more if you need.
But actually I think you can start as-is by providing that extra ROM just as you would provide any other updated data file to the target you want to deploy to.

[1]: http://ubuntu-on-big-iron.blogspot.com/2017/12/pxe-netboot-kvm-s390x.html

summary: - Backporting s390x pxelinux style network booting from qemu 3.0 to bionic
+ How to use s390x pxelinux style network booting from qemu 3.0 in bionic
Changed in qemu (Ubuntu):
status: New → Invalid
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI:
remember
  <rom file='/etc/fake/boot.bin'/>
to be able to deploy that extra netboot image without conflict with the base system.

See https://libvirt.org/formatdomain.html#elementsNICSROM

But do not derive too far from the usual paths, or you will need apparmor rules to allow qemu accessing it.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Full Disclosure: I never tried the latter on s390x so far

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Experimental POC in PPA [1], I'd be very glad if that could somehow be shoehorned into MAAS for a test if it would help you.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3441

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

s390x Regression test completed on the PPA
ppc64 Regression test started

Changed in qemu (Ubuntu):
status: Invalid → Triaged
Revision history for this message
Andres Rodriguez (andreserl) wrote :

From the MAAS perspective, we have tested this and confirm that provides what we need.

Changed in qemu (Ubuntu Bionic):
status: New → Triaged
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: New → Triaged
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

We have ack by all associated parties (Maas, security, code review, Tests) that the code/PPA are good, uploading to Cosmic.

Due to Beta Freeze things will hang there for a bit and also I'm out a few days.
I Will check status and prep Bionic when I'm back.

description: updated
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qemu - 1:2.12+dfsg-3ubuntu7

---------------
qemu (1:2.12+dfsg-3ubuntu7) cosmic; urgency=medium

  * Update pxe netboot images for KVM s390x to qemu 3.0 level (LP: #1790901)
    The SLOF source pieces in src:qemu are only used for s390x netboot,
    which are independent ROMs (no linking). All other binaries out of this
    are part of src:slof and independent.
    - d/p/ubuntu/lp-1790901-partial-SLOF-for-s390x-netboot-2.12-to-3.0.patch
    - d/p/ubuntu/lp-1790901-0*: backport s390x pxelinux netboot capabilities
      and related fixes

 -- Christian Ehrhardt <email address hidden> Tue, 25 Sep 2018 13:31:15 +0200

Changed in qemu (Ubuntu Cosmic):
status: Triaged → Fix Released
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Triaged → In Progress
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

ok, after things in Cosmic working and continueing to seem stable for a while lets tackle this for Bionic.

I already added an SRU Template before.
Also all former Bionic SRUs cleared so the queue is free for this update.

There already is a test PPA at: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3441
And I now opened the MP for Bionic's Qemu at: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/356407

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

A full set of regression tests completed on the PPA and the MP got a check for silly mistakes - both are good. Also the Dep8 tests completed on the Bileto ticket and completed all but the known flaky i36 systemd test.

I think we are ready to push this to Bionic.
Uploading it for the review of the SRU Team.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (10.3 KiB)

FYI - I just checked that you can still load the "old style" PXE blob that you have built.

ubuntu@s1lp5:~$ virsh start --console netboot
Domain netboot started
Connected to domain netboot
Escape character is ^]
done
  Using IPv4 address: 192.168.122.222
  Using TFTP server: 192.168.122.1
  Bootfile name: 'pxelinux.0'
  Receiving data: 5882 KBytes
  TFTP: Received pxelinux.0 (5882 KBytes)
Network loading done, starting kernel...

Uncompressing Linux... Ok, booting the kernel.
                                              [ 0.374768] Linux version 4.13.0-16-generic (buildd@z13-010) (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu2)) #19-Ubuntu SMP Wed Oct 11 18:33:05 UTC 2017 (Ubuntu 4.13.0-16.19-generic 4.13.4)
[ 0.374773] setup.289988: Linux is running under KVM in 64-bit mode
[ 0.376495] setup.b050d0: The maximum memory size is 2048MB
[ 0.376536] numa.196305: NUMA mode: plain
[ 0.376608] cpu.33a262: 1 configured CPUs, 0 standby CPUs
[ 0.376703] Write protected kernel read-only data: 11440k
[ 0.394514] Zone ranges:
[ 0.394516] DMA [mem 0x0000000000000000-0x000000007fffffff]
[ 0.394517] Normal empty
[ 0.394518] Movable zone start for each node
[ 0.394519] Early memory node ranges
[ 0.394519] node 0: [mem 0x0000000000000000-0x000000007fffffff]
[ 0.394521] Initmem setup node 0 [mem 0x0000000000000000-0x000000007fffffff]
[ 0.398963] random: fast init done
[ 0.398994] percpu: Embedded 24 pages/cpu @000000007ff9d000 s60416 r8192 d29696 u98304
[ 0.399007] Built 1 zonelists in Node order, mobility grouping on. Total pages: 516096
[ 0.399008] Policy zone: DMA
[ 0.399009] Kernel command line: root=/dev/ram0 ro
[ 0.400269] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.462530] Memory: 2047492K/2097152K available (7692K kernel code, 1054K rwdata, 3744K rodata, 692K init, 784K bss, 49660K reserved, 0K cma-reserved)
[ 0.462609] SLUB: HWalign=256, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.462611] ftrace: allocating 25487 entries in 100 pages
[ 0.471683] Hierarchical RCU implementation.
[ 0.471683] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=2.
[ 0.471684] Tasks RCU enabled.
[ 0.471685] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.473366] NR_IRQS: 3, nr_irqs: 3, preallocated irqs: 3
[ 0.473397] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns
[ 0.473477] console [ttyS1] enabled
[ 0.473538] pid_max: default: 32768 minimum: 301
[ 0.473562] Security Framework initialized
[ 0.473563] Yama: becoming mindful.
[ 0.473582] AppArmor: AppArmor initialized
[ 0.474702] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.475255] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.475275] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.475293] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.475584] Hierarchical SRCU implementation.
[ 0.475823] smp: Bringing up secondary CPUs ...
[ 0.475824] smp: Brought up 1 node, 1 CPU
[ 0.476080] devtmpfs: initialized
[ 0.476173] ev...

Revision history for this message
Robie Basak (racb) wrote :
Download full text (5.1 KiB)

> There could be cases where former PXE setups using the old technique would have to be slightly adapted to work with the new one. But all partners and peers related to this expressed that the current one is almost unusable and they'd want the new one.

I appreciate Christian pointing this out directly rather than having me spend time discovering it during review. The point itself concerned me. After speaking to Christian we concluded (and he tested) that the former method still works without modification. So previous behaviour is preserved, and therefore I don't need to consider whether breaking it is acceptable for SRU (and we don't have to risk that some users exists who is relying on it). To ensure this, please add a test for previous behaviour to SRU verification.

My understanding then is:

Provide a filename, like before, and it is treated as a bundled blob containing what is needed. Provide no filename, or a filename that is not found, and whereas previously boot would have failed, now syslinux's pxelinux emulation is enabled and boot will proceed using the emulation (fetching pxelinux configuration and using that, etc).

Does everyone realise that once this proposed change lands it'll be "locked in", and you won't necessarily be able to revise the interface again, for example changing behaviour in the syslinux pxelinux emulation? Since by the SRU justification itself it'll be useful this time, so any future changes may violate the "intrusive" part of the policy.

Review notes:

This is the effective proposed change to the source tree in Bionic:

 hw/s390x/ipl.c | 18 +-
 hw/s390x/ipl.h | 25 ++-
 pc-bios/s390-ccw/Makefile | 3 +-
 pc-bios/s390-ccw/bootmap.c | 60 +-----
 pc-bios/s390-ccw/bootmap.h | 20 +-
 pc-bios/s390-ccw/iplb.h | 34 ++-
 pc-bios/s390-ccw/jump2ipl.c | 91 ++++++++
 pc-bios/s390-ccw/libc.c | 88 ++++++++
 pc-bios/s390-ccw/libc.h | 37 +++-
 pc-bios/s390-ccw/main.c | 23 +-
 pc-bios/s390-ccw/netboot.mak | 16 +-
 pc-bios/s390-ccw/netmain.c | 384 +++++++++++++++++++++++++--------
 pc-bios/s390-ccw/s390-ccw.h | 4 +
 pc-bios/s390-ccw/sclp.c | 10 +-
 roms/SLOF/lib/libc/include/assert.h | 36 ++++
 roms/SLOF/lib/libc/include/stdio.h | 1 +
 roms/SLOF/lib/libc/stdio/Makefile.inc | 2 +-
 roms/SLOF/lib/libc/stdio/snprintf.c | 28 +++
 roms/SLOF/lib/libc/stdlib/free.c | 4 +-
 roms/SLOF/lib/libc/string/Makefile.inc | 2 +-
 roms/SLOF/lib/libc/string/strrchr.c | 28 +++
 roms/SLOF/lib/libnet/Makefile | 2 +-
 roms/SLOF/lib/libnet/bootp.c | 2 +-
 roms/SLOF/lib/libnet/dhcp.c | 76 +++++--
 roms/SLOF/lib/libnet/dhcpv6.c | 3 +-
 roms/SLOF/lib/libnet/ipv6.c | 2 +-
 roms/SLOF/lib/libnet/libnet.code | 6 +-
 roms/SLOF/lib/libnet/netapps.h | 3 +-
 roms/SLOF/lib/libnet/netload.c | 252 ++++++++++++++--------
 roms/SLOF/lib/libnet/ping.c | 14 +-
 roms/SLOF/lib/libnet/pxelinux.c | 251 +++++++++++++++++++++
 ro...

Read more...

Changed in qemu (Ubuntu Bionic):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-bionic
Revision history for this message
Robie Basak (racb) wrote : Please test proposed package

Hello Andres, or anyone else affected,

Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: In Progress → Fix Committed
Revision history for this message
Andres Rodriguez (andreserl) wrote :

I've tested this with MAAS in a remote s390x system, and confirm it works out of the box. So I'm +1.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (3.4 KiB)

Upgraded to 1:2.11+dfsg-1ubuntu7.7 and found no general issue (subset of the general regression test that we already ran on the identical PPA).

As I was asked to check that the old blob-style PXE still works lets start with my old PXE config as in [1] but with the new qemu from proposed.

The boot looks slightly different at first as the init sequence has a few mor things to say now since it is partially based on slof.
But then it starts the pxelinux.0 blob that I asked dhcp to serve just fine.
It is loaded, booted and then does whatever is in there.
In my case this was the "old style" blob that then does restricted capability PXE from that blob.

Here a log:
$ virsh start --console netboot
Domain netboot started
Connected to domain netboot
Escape character is ^]
done
  Using IPv4 address: 192.168.122.222
  Using TFTP server: 192.168.122.1
  Bootfile name: 'pxelinux.0'
  Receiving data: 5882 KBytes
  TFTP: Received pxelinux.0 (5882 KBytes)
Network loading done, starting kernel...
Uncompressing Linux... Ok, booting the kernel.
[ 0.372458] Linux version 4.13.0-16-generic (buildd@z13-010) (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu2)) #19-Ubuntu SMP Wed Oct 11 18:33:05 UTC 2017 (Ubuntu 4.13.0-16.19-generic 4.13.4)
[...]
[ 0.522168] Write protected read-only-after-init data: 52k
waiting for pxe config from DHCP (max 600 sec)
udhcpc: started, v1.27.1
DHCP response deconfig:
 interface: eth0
udhcpc: sending discover
udhcpc: sending select for 192.168.122.222
udhcpc: lease of 192.168.122.222 obtained, lease time 3600
DHCP response bound:
 interface: eth0 192.168.122.222 255.255.255.0
 router: 192.168.122.1
 domain: 192.168.122.1
 tftp: 192.168.122.1
fetching config pxelinux.cfg/e2aee7f3-cc42-43e9-823f-c1973040984b from 192.168.122.1

Now classic/other PXE would do that without the blob in between and that is the test for the new code.
If it does not find the (or didn't even get specified one) blob it will fall back to the - now available - PXE boot capabilities in the ROM.
Also not bad to see if it woudl e.g. crash if a non existing blob is requested :-)

# make unavailable
$ mv /srv/tftp/pxelinux.0 /srv/tftp/pxelinux.0.notavail

# boot again
$ virsh start --console netboot
Domain netboot started
Connected to domain netboot
Escape character is ^]
done
  Using IPv4 address: 192.168.122.222
  Using TFTP server: 192.168.122.1
  Bootfile name: 'pxelinux.0'
  Receiving data: 0 KBytes
  TFTP error: file not found: pxelinux.0
Trying pxelinux.cfg files...
  Receiving data: 0 KBytes
  TFTP: Received pxelinux.cfg/default (113 bytes)
Loading pxelinux.cfg entry 'ubuntu'
  Receiving data: 4292 KBytes
  TFTP: Received vmlinuz-4.15.0-33-generic (4292 KBytes)
  Receiving data: 16763 KBytes
  TFTP: Received initrd.img-4.15.0-33-generic (16763 KBytes)
Network loading done, starting kernel...

[ 0.433716] Linux version 4.15.0-33-generic (buildd@bos02-s390x-010) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 (Ubuntu 4.15.0-33.36-generic 4.15.18)

This now is directly my "target" configuration out of
$ cat /srv/tftp/pxelinux.cfg/default
label ubuntu
   kernel vmlinuz-4.15.0-33-generic
   initrd initrd.img-4.15.0-3...

Read more...

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Revision history for this message
Frank Heimes (fheimes) wrote :

Verified package from proposed as well with manual kvm/virsh usage and uvt and can also confirm that it worked fine for me. (verification-done already set)

Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
importance: Undecided → High
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.7

---------------
qemu (1:2.11+dfsg-1ubuntu7.7) bionic; urgency=medium

  * Update pxe netboot images for KVM s390x to qemu 3.0 level (LP: #1790901)
    The SLOF source pieces in src:qemu are only used for s390x netboot,
    which are independent ROMs (no linking). All other binaries out of this
    are part of src:slof and independent.
    - d/p/ubuntu/lp-1790901-partial-SLOF-for-s390x-netboot-2.11-to-3.0.patch
    - d/p/ubuntu/lp-1790901-0*: backport s390x pxelinux netboot capabilities
      and related fixes

 -- Christian Ehrhardt <email address hidden> Tue, 25 Sep 2018 13:31:15 +0200

Changed in qemu (Ubuntu Bionic):
status: Fix Committed → Fix Released
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.