MAC address needs to be unique and unchanged during entire netboot process

[Frank Heimes]

Currently the MAC address is not solely used to id the machine or system.
It is at the moment used to id the interface that the MAC represents.
(At a very early state in the process the MAC address is missing or only available from inside the partition.)

The minimum PXE boot requirements need to be satisfied in general.
The boot loader is part of the firmware and not loaded from the server.
So that means the firmware needs to provide the MAC address.
But the MAC address is not available at that time, so it's not available upfront.

MaaS is using the same MAC address for the initial DHCP request as for the network boot.
Hence an initially known MAC address is required that needs to be static and doesn't change (on subsequent boots for that instance).

There might be an IBM internal ticket already open for this - please check.

Furthermore the firmware needs to requests files like this:
pxelinux.cfg/01-88-99-aa-bb-cc-dd
pxelinux.cfg/default
And BOOTIF support is required:
See 'petitboot doesn't handle ipappend in pxelinux.cfg'
https://bugs.launchpad.net/tasty-taco/+bug/1322307
for reference.

[Heinz-Werner Seeck (heinz-werner-seeck)]

Changed Target Milestone to 19.04 to postpone in the future, but still keeping this request.
This function will be made available with kernel 4.21...

The initial git commit can be found here
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=b144b99fff69a5bc0d34c8e168bedb88c68ca23d

on net-next which will be integrated into kernel 4.21 later

[Frank Heimes (fheimes)]

looks like:
  Subject: s390/qeth: sanitize strings in debug messages
  Git-commit: e19e5be8b4cafa8b3f8b0cd1b1dfe20fa0145b83
is a pre-req.

[Frank Heimes (fheimes)]

Dear kernel team, please check whether the patch in #1 can be picked-up or not and ideally provide a test kernel (ppa) as testbed for the MAAS team - thx.

[Joseph Salisbury (jsalisbury)]

I built a test kernel with commit b144b99fff69a5bc0d34c8e168bedb88c68ca23d. Commit 4fda33547676eb144 was also required as a prereq. The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1646805

Can you test this kernel and see if it resolves this bug?

Note about installing test kernels:
• If the test kernel is prior to 4.15(Bionic) you need to install the linux-image and linux-image-extra .deb packages.
• If the test kernel is 4.15(Bionic) or newer, you need to install the linux-modules, linux-modules-extra and linux-image-unsigned .deb packages.

Thanks in advance!

[bugproxy (bugproxy)]

*** Bug 173541 has been marked as a duplicate of this bug. ***
this function will be made available with kernel 4.21...
Git-commti will follow

[Frank Heimes (fheimes)]

I did at least 'some' testing on z13/classic-mode - even if the interesting test will be on a z14/DPM machine.
With shutdown, reboots, LPAR re-activations I didn't saw a changing MAC.
But when booting a different OS in the same LPAR from a different disk.
The MAC address while installing and later in the installed system is the interesting part.

A concern I have is that I now get swamped by reoccurring console messages like these (or in syslog or dmesg):
[ 2931.475956] BUG: non-zero pgtables_bytes on freeing mm: -16384
[ 2931.477268] BUG: non-zero pgtables_bytes on freeing mm: -16384
[ 2931.488432] BUG: non-zero pgtables_bytes on freeing mm: -16384
[ 2931.496322] BUG: non-zero pgtables_bytes on freeing mm: -16384 ...
I think that should be fixed in between: https://lore.kernel.org/patchwork/patch/921554/

[Joseph Salisbury (jsalisbury)]

The commit posted in comment #6 has been in mainline since 4.16-rc5, so it is already in Cosmic, Disco and the test kernel I posted. The commit is:
61e18270f604 ("s390: Fix runtime warning about negative pgtables_bytes")

So maybe there are other commit(s) needed to fix those messages. Did the test kernel fix the original issue? If so, maybe I can build a linux-next kernel for you to see if a fix for the console messages is available.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-12-05 07:56 EDT-------

------- Comment From <email address hidden> 2018-03-20 05:26 EDT-------

------- Comment From <email address hidden> 2018-11-28 11:03 EDT-------

------- Comment From <email address hidden> 2018-11-30 05:42 EDT-------

------- Comment From <email address hidden> 2018-11-30 07:41 EDT-------

[Frank Heimes (fheimes)]

@IBM: If you try out the test kernel mentioned in comment #5, can you please also check if you see the messages mentioned in comment #6.

[bugproxy (bugproxy)]

This problem should be revisited again after usage of kernel 4.21 .

[Frank Heimes (fheimes)]

Changing to incomplete until disco is rebased on (target kernel) 4.21.

[Frank Heimes (fheimes)]

Since kernel 5.0 landed in disco-proposed I'm changing the status to Fix Committed.

[Frank Heimes (fheimes)]

Confirming that commit "s390/qeth: sanitize strings in debug messages" landed in disco-proposed "Ubuntu-5.0.0-7.8" (as e19e5be).

[Frank Heimes (fheimes)]

Kernel 5.0 landed in disco's release pocket today, hence changing status to Fix Released.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-12-12 05:40 EDT-------

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-03-15 06:25 EDT-------
IBM Bugzilla status -> closed, Fix Released for disco

[Lee Trager (ltrager)]

I tested this today using 5.0.0-8-generic and between reboots I am still getting different MAC addresses on Z13.

[Frank Heimes (fheimes)]

@ltraeger, the patch above, that's part of disco, only works in combination with a z14 (and again a pretty recent firmware level). It doesn't change the situation on z13 or z13s.
So z14 (or z14 ZR1) is a prerequisite.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-04-04 05:48 EDT-------
Just to make sure: This bugzilla does not apply to Network under DPM neither on z13 nor on z14 machines.

[Frank Heimes (fheimes)]

Hi Jochen, not sure if I got that right - so let me rephrase according to our needs:

Does that mean - and can you conform - that this unique MAC address patch for PXE boot applies to a z14 in DPM mode with a certain level (tbd) of firmware code?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-04-05 05:06 EDT-------
Hi Frank, sorry to say, but this patch does not apply to IBMZ Firmware at all.

[Frank Heimes (fheimes)]

Hi, well Firmware is a broad term - let me split it up into two cases:
1) boot <installer> from CD or FTP server (e.g. 'Load from Removeable Media and Server' task),
   then install to disk and reboot from that disk - possible in classic HMC mode and DPM
2) boot <installer> from network server (PXE-like), then install to disk and reboot from that disk
   afaik DPM mode only

Obviously both requires firmware support - but probably different components.

The MAC address should not change (in the above examples) between the 1st boot (e.g. installer) and the 2nd (re-)boot (e.g. a post-install restart of the system from disk).

Having MAAS in mind we particularly require the 2nd case (network-booting an LPAR in DPM, installing to disk and restarting from that disk and always having the same unique MAC address).

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-04-10 05:45 EDT-------
Requires Firmware update on top - this effort is ongoing and will be tracked by a seperate LP-Bugziila

[Frank Heimes (fheimes)]

FW part is tracked in LP 1824117