[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pxe booting qemu



On 23 Sep 2019 at 13:26, john doe wrote:
...
> > If the kernel in the netboot image gets out of sync with the kernel module packages,
> > then the modules won't load and the install will fail,
> > the usual symptoms are that messages about "missing symbols" appear
> > in the ctrl-alt-f4 console.
> >
> > To fix this, update the kernel and initrd on the netboot server.
> >
> 
> By doing 'apt-get update && apt-get upgrade'?
> In other words, I can't provide PXE booting for Stretch hosts when the
> PXE server is on Buster.
> 
No, that's not the way to do it.

When PXE-booting a Linux, e.g. a Debian Netinstall,
your pxelinux.cfg/default will contain something like:

label stretch64
  kernel stretch64/linux
  append initrd=stretch64/initrd.gz priority=low  --

Note that the two files, called "linux" (= the kernel) and initrd.gz, 
get served from some directory known to the TFTP server.
The classic name for that directory appears to be /tftpboot,
but even that is not set in stone, and the rest of the paths
(the directory structure) is definitely your own choice.
I.e. those are NOT the files living in /boot/ under your server's own 
filesystem root mount point. 

I get these two files for DHCP+TFTP Netboot / Debian Netinstall from:

http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/curren
t/images/netboot/debian-installer/amd64/

If you notice, that your PXE-booting installer cannot find disk 
drives, that's because the modules package (downloaded from the 
Debian repo) is newer, not matching your installer kernel anymore 
= installer kernel has turned stale = you need to re-download the 
"linux" and "initrd.gz" files from the link above. 
Note that installer kernels are different from the "runtime, 
production" kernels that ultimately get installed on the target 
system, even speaking about the same Debian version.
Again the kernel and initrd that get served by TFTP for "PXE-booting" 
have nothing to do with the operating system on your server, you 
could just as well use some Windows-based DHCP+TFTP solution.
Not sure if the venerable jounin tftpd would work for instance:
http://tftpd32.jounin.net/tftpd32_download.html
(How would you want to "apt-get install linux-kernel" on that? :-)

This last spring in one case I needed to install the Ubuntu Disco 
Dingo. I used this method, and guess what: the initrd image in the 
Ubuntu repo was corrupt :-) So I ended up downloading the netinstall 
CD image (ISO) and booting that. That worked. I don't recall anymore
if I just booted the whole CD, or if I extracted its kernel and 
initrd and used those for direct PXE-boot. Either way, most of the 
packages got downloaded off the internet = I did not install the 
whole system from the local CD.

BTW I now have a fairly vanilla Debian 9 PXE-booting in the network
with NFSroot, mounted read-only by default (with overlayfs on top),
alternatively mounted read-write... booting into text mode or X.
That's four combinations, selectable by kernel cmdline arguments.
With autologin at the console and in X (XFCE).
Except for overlayfs, the rest went surprisingly smooth/seamless.
I'm planning to publish a howto of sorts (my notes that I collected
while driving along). Right at the moment I'm trying to run qemu 
on top of that, to facilitate some "OS deployment jobs"...

> > Oh, and by the way: If you try to pxeboot via UEFI, many 
> > tutorials etc. are plain wrong: You don't use pxelinux.0 in that 
> > case at all! You'll be loading bootnetx64.efi which then will 
> > load grubnetx64.efi. 

Michael, thanks for that teaser, and for all the links.
NetBooting in UEFI mode is working its way up my ToDo list.
The first thing I'm wondering about: is there a way for me to 
distinguish, at a DHCP server, between legacy and UEFI clients?
Because I'd need to serve a different boot file option (or boot 
server option, or both) to each of those groups of DHCP clients...
Unless that works, I'll have to stay with the "legacy PXE" booting.
Well I should probably start by RTFM and a bit of sniffing.

Frank Rysanek


Reply to: