Ubuntu 22.04 PXE / UEFI netboot DESKTOP installation

Hello,

The web page at
http://archive.ubuntu.com/ubuntu/dists/jammy/main/installer-amd64/current/legacy-images/ suggest I come here to discuss lack of so called legacy-images.

We currently have about 1500 Ubuntu desktop/laptop computers, which need to be installed over the network. We have been using the netboot kernel and initrd from mini.iso to boot our computers to debian-installer which hands off the configuration to puppet at the end of the installation process. The mini.iso is somewhat reasonably sized at about 74MB.

Now we are offered to use a huge image of about 1.4GB instead (ubuntu-22.04-beta-live-server-amd64.iso). Even if we didn’t have to completely rewrite our installation process, this seems insane just because of the huge iso image. Also, it seems that the server install image always installs ubuntu-server metapackage, which we need to purge as the first step.

Are we screwed, or will there be mini.iso for Jammy Jellyfish?
Should we move to Debian instead (and try to deal with their lack on non-free firmware during PXE /UEFI netboot) or does Canonical support organisations with massive amounts of Desktops and Laptops?

7 Likes

Hi,

Same problem here. Because of lake of time, we will migrate on 22.04, but just the time to found other distribe (Debian ?).

I don’t think this installs way is a good idea, like snap too …

1 Like

I’m curious about this as well. It’s not clear or obvious to me exactly what the alternative/new method is for solving this issue? It’s becoming clear that we’ll need to rewrite our OS installation process but if anyone can provide some hints as to what the solution might look like that would allow us to do large scale network based automated installs it would be greatly appreciated.

3 Likes

Does the new autoinstall system not work? It’s aimed at servers but can install a desktop system as well.

https://www.molnar-peter.hu/en/ubuntu-jammy-netinstall-pxe.html

1 Like

I haven’t personally tested that, but the described procedure seems to be a bit troublesome.

First of all, that implies that any new attempt at installing will download the 1.4GB ISO EVERY TIME.

Second of all, is that most server/system administrators already maintain a preseed file for the debian-installer which, more or less, only required minimal maintenance between major releases.

There are a lot of MSPs/data-centers that have preseeds in place already, and we have gotten around every release by just updating bits and pieces. Some companies even have more complex setups that generate the preseed files on the fly.

With the new installer, this has gone up in flames.

4 Likes

So I’ve followed those instructions (mostly) and here’s my experience. The ‘goal’ and measure of success will be:

  • Use an external DHCP server that only serves IP’s to LAN1
  • Admin and Test VM’s in LAN1
  • TFTP/HTTP server in LAN2
  • Generation 1 VM (BIOS) in LAN1 can PXE boot and pull image from TFTP server in LAN2
  • Generation 2 VM (UEFI with Secure boot enabled) in LAN1 can PXE boot and pull image from TFTP server in LAN2

Pretty straight forward. With this setup, I would be able to PoC a workable solution. pfSense supports the network booting options necessary to pass on the next server, default BIOS file (pxelinux.0) and UEFI64bit file (bootx64.efi).

My PoC setup consists of the following:

  • Using MS Hyper-V on Windows 10 Pro to test this all out
  • 3 Virtual Network Switches (One “External Switch” (WAN), two “Private Switches” (LAN1 and LAN2))
  • 5 Virtual Machines
  • 1 Virtual machine with 3 virtual network adapters. Each adapter connected to one of the 3 switches. This Virtual machine is running pfSense and is my FW, DHCP server for LAN1 and router.
  • 1 Virtual machine running Ubuntu Desktop 22.04 on LAN1. This is my (for a lack of a better word) admin system that I am using to validate connectivity, ssh/web browse/etc to all the other components.
  • 1 Virtual Machine running Ubuntu Server 20.04 setup as per the instructions from https://www.molnar-peter.hu/en/ubuntu-jammy-netinstall-pxe.html minus the DHCP config.
  • 1 Virtual Machine setup as a BIOS (Generation 1) system configured to boot from network.
  • 1 Virtual Machine setup as a UEFI (Generation 2) system configured to boot from network.

So here are my results so far:

I’m able to get Generation 1 (BIOS) based systems to network boot, present me with a menu and install the OS. I would say that anyone following these instructions should be met with success for BIOS based systems.

Things kinda fell off the rails when it came to trying to get a Generation 2 (UEFI) system to network boot. I’ve documented my journey over on askubuntu.com ( https://askubuntu.com/questions/1406685/22-04-jammy-pxe-booting-help ) but very long story short, all I get is a GRUB> prompt. My setup isn’t reading the /boot/grub/grub.cfg file and I have no idea why.

In trying to resolve this issue:

  • I’ve since moved the TFTP server from LAN2 to LAN1 removing the pfSense firewall out of the equation.
  • I’ve tried using the EFI files found here: http://archive.ubuntu.com/ubuntu/dists/jammy/main/uefi/grub2-amd64/current/
  • I’ve tried using the EFI files found on both the 20.04 and 22.04 ISO’s
  • I’ve tried moving the EFI files into the /boot/grub directory and updating the DHCP server
  • I’ve tried moving the grub files up into the /boot directory

What I ‘think’ the problem is, if you look at this screenshot https://i.stack.imgur.com/LrQiI.png you can see that my $prefex is set correctly. However last night before I gave up, while at the $GRUB prompt I did an ls comand and while (memdisk) was there, (tftp,172.16.1.3) was not. I don’t know if this is normal/expected but this is where I’m going to focus my efforts today.

Something else that I may try is to enable the DHCP server on the TFTP/HTTP server (and disable it on my pfSense firewall). There is mention of possibly needing to specify option arch code 93 = unsigned integer 16; in the dhcp scope. My understanding is that Option 93 would carry the architecture type (BIOS, UEFI, etc.) and is needed to help the logic of the DHCP if statements to determine which boot file to serve (pxelinux.0 or bootx64.efi).

Sorry for the wall of text but If you have time to take a look and see anything that I might have missed I’d appreciate it.

Cheers!

I’ve made some progress that I thought I should share. I came across this YouTube video (https://www.youtube.com/watch?v=E_OlsA1hF4k&t=0s) where I noted that it was created fairly recently. As I was watching, I noticed that they created/extract their bootx64.efi, grubx64.efi and unicode.pf2 instead of grabbing them off of the ISO. I followed along, created my own files and finally was able to PXEBOOT my UEFI secureboot enabled system.

Here’s the relevant info to create those files:

apt-get download shim.signed -y
dpkg-deb --fsys-tarfile /tmp/shim-signed*deb | tar x ./usr/lib/shim/shimx64.efi.signed -O > bootx64.efi

apt-get download grub-efi-amd64-signed
dpkg-deb --fsys-tarfile /tmp/grub-efi-amd64-signed*deb | tar x ./usr/lib/grub/x86_64-efi-signed/grubnetx64.efi.signed -O > grubx64.efi

apt-get download grub-common
dpkg-deb --fsys-tarfile grub-common*deb | tar x ./usr/share/grub/unicode.pf2 -O > unicode.pf2

I basically moved the EFI files into my /tftp/boot directory and the unicode.pf2 file into my /tftp/boot/fonts/ directory

I’m going to take a breath and document everything up to this point so I can re-create it. Once finished I’ll find a place to post the documentation as it will likely help others.

I have a quick question. Where do you find the /boot/jammy/initrd and /boot/jammy/vmlinuz for your tftp server?

It looks like those may be the only missing links I need to adapt my ipxe PXEboot setup.

Edit: Extract them from the iso. Gotcha. It would have been so much easier if it was available in the archive and I could point directly at them like we used to do with the netboot…

1 Like