UEFI issues booting into FAI sysinfo on Dell PowerEdge

[Steffen Grunewald]

Hello,

I've been using FAI for years now, and could always avoid UEFI - until last
week when a coworker asked me to "quickly" run a sysinfo for one of his new
machines.
Of course, it comes with UEFI activated.
After finding how to distinguish between BIOS and UEFI PXE requests, and
setting up the DHCP/TFTP server accordingly, it was only "yet another step"
to find and add ldlinux.e64 to get the machine booting.
It requests the kernel, and loads it.
It requests the initrd, and hangs doing so.
/var/log/daemon shows both requests and nothing more after them.

There's a warning
"core_udb_sendto: stalling on configure with no mapping"
further up the boot screen, but I'm not sure it'd be related.

The corresponding pxelinux.cfg file was created once, worked in legacy mode.

Unfortunately, UEFI-related FAI documentation is very sparse, and I may have
overlooked something?
Machine is a Dell one (if this makes a difference), PowerEdge R840.

Fortunately, the machines were able to boot in legacy mode, so the goal was
reached to a major extent (I couldn't test EFI detection though, not run
"efibootmgr -v" within one of the class scripts).


Any suggestions what to try next?

Thanks,
Steffen

[Thomas Lange]

Post by Steffen Grunewald
After finding how to distinguish between BIOS and UEFI PXE requests, and
setting up the DHCP/TFTP server accordingly, it was only "yet another step"
to find and add ldlinux.e64 to get the machine booting.

I use syslinux.efi in the dhcpd.conf for UEFI machines. I have
syslinux.efi and ldlinux.e64 in my tftp directory. Then I can use the
same syntax in the pxelinux.cfg files as before.

Post by Steffen Grunewald
/var/log/daemon shows both requests and nothing more after them.

I had problems with a broken UEFI Bios on a Thinkpad. Upgrading the
BIOS fixed the issue for me.
I would try another machine using UEFI.

[Steffen Grunewald]

Post by Thomas Lange

Post by Steffen Grunewald
After finding how to distinguish between BIOS and UEFI PXE requests, and
setting up the DHCP/TFTP server accordingly, it was only "yet another step"
to find and add ldlinux.e64 to get the machine booting.

I use syslinux.efi in the dhcpd.conf for UEFI machines. I have

I'm following the instructions from SYSLINUX for automatic handling, with minor
modifications I stole from somewhere else:

if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000" {
filename "pxelinux.0";
# needs ldlinux.c32
}
if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006" {
filename "syslinux32.efi";
# needs ldlinux.e32
}
if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007" {
filename "syslinux64.efi";
# needs ldlinux.e64
}
if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009" {
filename "syslinux64.efi";
}

Seems to work for 64-bit UEFI. (It's somewhat confusing that an x86_64 EFI file
would also work on an aarch64 machine, btw., but I have only one of those.)

Post by Thomas Lange
syslinux.efi and ldlinux.e64 in my tftp directory. Then I can use the

Indeed I had been missing ldlinux.e64 initially, but quickly learned about my
mistake from /var/log/daemon.log. syslinux64.efi has been copied from the syslinux
64-bit modules tree, and renamed accordingly.

Post by Thomas Lange
same syntax in the pxelinux.cfg files as before.

Thank you for confirming that no modification is necessary!

Post by Thomas Lange

Post by Steffen Grunewald
/var/log/daemon shows both requests and nothing more after them.

I had problems with a broken UEFI Bios on a Thinkpad. Upgrading the
BIOS fixed the issue for me.
I would try another machine using UEFI.

It turned out that I was a little bit too impatient. Apparently, there's a
long period of "virtually nothing happening", but when I came back from typing
the email, the sysinfo run had finished (there had been a problem with the log
upload, but that'd been caused by my stupidity only - pity I don't have any
results).
I remember that the "legacy" sysinfo run also took a long while to get started,
so it might be hardware-specific.
I'll try another UEFI machine soon, and have added support for 32-bit UEFI for
that reason.

Thanks for the heads-up.

- Steffen

[Thomas Lange]

Post by Steffen Grunewald
I remember that the "legacy" sysinfo run also took a long while to get started,
so it might be hardware-specific.

If the boot/startup process of FAI takes a long time, it's maybe this issue:
https://github.com/faiproject/fai/commit/42abe35ed4d5a8c6f63e3bd334f4ab7339e

Without this fix, rsyslogd may need a long time to start is some situations.

[Steffen Grunewald]

Post by Thomas Lange

Post by Steffen Grunewald
I remember that the "legacy" sysinfo run also took a long while to get started,
so it might be hardware-specific.

https://github.com/faiproject/fai/commit/42abe35ed4d5a8c6f63e3bd334f4ab7339e
Without this fix, rsyslogd may need a long time to start is some situations.

Interesting, but I don't see this on other machines - and my FAI version has this
fix already incorporated (5.7 from the koeln repository).
I guess the delay is caused by the large initrd (30 MB).
I'm lucky not to be bitten by the watchdog then...

- S

[Rémy Dernat]

Hi,

I suggest you to retrieve the version of SYSLINUX 6.04; look here for more
informations :
https://groups.google.com/a/lbl.gov/forum/#!msg/warewulf/klTLgX-L4nw/IJZo3-jgAAAJ

BTW, sometimes an update of the firmware on the client give great results.

Best regards,
Rémy.

Le lun. 3 sept. 2018 à 14:27, Steffen Grunewald <

Post by Steffen Grunewald
Hello,
I've been using FAI for years now, and could always avoid UEFI - until last
week when a coworker asked me to "quickly" run a sysinfo for one of his new
machines.
Of course, it comes with UEFI activated.
After finding how to distinguish between BIOS and UEFI PXE requests, and
setting up the DHCP/TFTP server accordingly, it was only "yet another step"
to find and add ldlinux.e64 to get the machine booting.
It requests the kernel, and loads it.
It requests the initrd, and hangs doing so.
/var/log/daemon shows both requests and nothing more after them.
There's a warning
"core_udb_sendto: stalling on configure with no mapping"
further up the boot screen, but I'm not sure it'd be related.
The corresponding pxelinux.cfg file was created once, worked in legacy mode.
Unfortunately, UEFI-related FAI documentation is very sparse, and I may have
overlooked something?
Machine is a Dell one (if this makes a difference), PowerEdge R840.
Fortunately, the machines were able to boot in legacy mode, so the goal was
reached to a major extent (I couldn't test EFI detection though, not run
"efibootmgr -v" within one of the class scripts).
Any suggestions what to try next?
Thanks,
Steffen
--
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am MÃŒhlenberg 1 * D-14476 Potsdam-Golm * Germany
~~~
Fon: [phone]
Mail: steffen.grunewald(at)aei.mpg.de
~~~

[Steffen Grunewald]

Post by Rémy Dernat
Hi,
I suggest you to retrieve the version of SYSLINUX 6.04; look here for more
https://groups.google.com/a/lbl.gov/forum/#!msg/warewulf/klTLgX-L4nw/IJZo3-jgAAAJ

I'm stuck with 6.03 right now.
(That thread is yet another place suggesting to save memory by going for legacy boot!)

Post by Rémy Dernat
BTW, sometimes an update of the firmware on the client give great results.

The machines are brand-new... I doubt that there's a BIOS update yet, and of course
if there was it'd be nice to apply it over the network...

Thanks,
S

[Thomas Lange]

Post by Rémy Dernat
I suggest you to retrieve the version of SYSLINUX 6.04; look here for more
https://groups.google.com/a/lbl.gov/forum/#!msg/warewulf/klTLgX-L4nw/IJZo3-jgAAAJ

Now I rembember that not the BIOS update fixed my Thinkpad problem,
but using a newer syslinux.efi from syslinux 6.04 was the proper fix.

[Steffen Grunewald]

Post by Thomas Lange

Post by Rémy Dernat
I suggest you to retrieve the version of SYSLINUX 6.04; look here for more
https://groups.google.com/a/lbl.gov/forum/#!msg/warewulf/klTLgX-L4nw/IJZo3-jgAAAJ

Now I rembember that not the BIOS update fixed my Thinkpad problem,
but using a newer syslinux.efi from syslinux 6.04 was the proper fix.

Will try that next. (For whatever reason there was no update of syslinux
in Debian for years... not even an backport. Stretch is growing old already.)

Thanks, S

[Steffen Grunewald]

Post by Steffen Grunewald

Post by Thomas Lange

Post by Rémy Dernat
I suggest you to retrieve the version of SYSLINUX 6.04; look here for more
https://groups.google.com/a/lbl.gov/forum/#!msg/warewulf/klTLgX-L4nw/IJZo3-jgAAAJ

Now I rembember that not the BIOS update fixed my Thinkpad problem,
but using a newer syslinux.efi from syslinux 6.04 was the proper fix.

Will try that next. (For whatever reason there was no update of syslinux
in Debian for years... not even an backport. Stretch is growing old already.)

I owe you a report - a success report, that is.
Using the files from syslinux-{common,efi}_6.04~git (as recommended by Thomas,
already on July 11 - I must have missed that during my holidays), the boot delay
almost vanished. No issues booting the Dell machine, and I also succeeded with
an AMD Epyc one.
For the latter, I found that the UEFI mode results in 7 *more* available memory
pages than the LEGACY one (unless my counting algorithm is faulty).
Not too big a difference, and given that I had to flip seven switches to go UEFI
(boot mode, and 6 PCI-E OPROM modes), I'm still hesitant to enforce UEFI, but
at least now I know that UEFI-only hardware won't be a showstopper anymore.
(Got to think about adding a /boot/efi partition to all relevant disk_configs...)

Thanks for all your suggestions.
Now back to the preparations for the new setup (delivery will be in November,
but I've got some hardware to test before)...

- Steffen