PiServer not issuing DHCP address to a Pi4

[jonwitts]

I have received my class set of Pi4s and was starting to set them up (in the knowledge that I will probably be running them on SD Cards to start with), however when I connect them to the same DHCP network as my PiServer they do not get issued an IP Address...

Looking at it I think that the Pi4s have new MAC Address range... All of my connected Pi3s start b8:27:eb yet the Pi4 I am testing with starts dc:a6:32....

Have Raspberry Pi been allocated another MAC address range? If so, is it possible to get PiServer to at least serve DHCP requests to clients in this range too?

Thanks :-D

[ghollingworth]

Yes that's correct we now have a new OUI

[maxnet]

Note that besides the MAC filter, only devices that are actually trying to boot from the network (have "PXEClient" in the DHCP packet) are shown.

[jonwitts]

Note that besides the MAC filter, only devices that are actually trying to boot from the network (have "PXEClient" in the DHCP packet) are shown.

Does that mean that they will not be given a DHCP address (if the filter were expanded to allow the new OUI) or just that they would not show up in the PiServer GUI?

[maxnet]

Does that mean that they will not be given a DHCP address (if the filter were expanded to allow the
new OUI) or just that they would not show up in the PiServer GUI?

I am only talking about the GUI.
The "add hosts" window in the GUI, only shows devices that have the right OUI, are sending DHCP packets containing PXEClient right now and are not already in the system.

If you add the hosts manually to the /var/lib/piserver/hosts.json, no restrictions apply.
Run "sudo piserver --update-ip" afterwards, to regenerate the right dnsmasq configuration file from the data in the json.
Will also issue a DHCP lease to devices listed there that are not network booting.
You do may also need to create the right symlinks in the "tftproot" folder, if adding hosts manually. (or edit the Pi -> operating system mapping in the GUI afterwards for each of the hosts you added).

[maxnet]

BTW I do was assuming that you do want to use the Pi 4 with Piserver.
As in:

• add Buster to the system
• put the contents of /var/lib/piserver/os/name-of-os/boot on a SD card that you put in the Pi 4.
  Booting the kernel from SD card, and getting the rest over NFS.

If that was not your intention, and you want independent Pi using SD cards, that do need a DHCP lease, just alter the dnsmasq configuration.
By default we configure it to only respond to the exact MAC addresses of clients on the list.
But if you are 100% certain you are the only DHCP server in the network/VLAN, and there will not be any conflicts, you can change the configuration to hand out leases to everyone.
Changes you make in /etc/dnsmasq.d/piserver will be overwritten by piserver, but you do can edit /etc/dnsmasq.conf

Can give non-piserver hosts an IP out of a different range ("dhcp-range=[start-ip],[end-ip],[netmask]")
Or just tag everyone to the piserver group there, so that they get an IP out of the range configured in Piserver with a command like: "tag-if=set:piserver"

[jonwitts]

BTW I do was assuming that you do want to use the Pi 4 with Piserver.
As in:

* add Buster to the system

* put the contents of /var/lib/piserver/os/name-of-os/boot on a SD card that you put in the Pi 4.
  Booting the kernel from SD card, and getting the rest over NFS.

If that was not your intention, and you want independent Pi using SD cards, that do need a DHCP lease, just alter the dnsmasq configuration.

Absolutely; my end goal is to be able to use the Pi 4 with PiServer - I thought that even with /boot on and SD Card Buster was still not working correctly over NFS... or does this issue: raspberrypi/linux#3067 only effect Pi 3 running Buster?

If it is possible to get the PI 4 booting from SD Card and then everything else running from PiServer then this is where I would love to be ready for September (assuming that the network boot of Pi 4 will not be ready in time)...

Any pointers towards getting this working would be gratefully received! I am more than happy to test things out if that helps others too and will try to document what I do if that would help others too. :-D

[maxnet]

or does this issue: raspberrypi/linux#3067 only effect Pi 3 running Buster?

It only seems to occur with Pi that are being PXE booted.
When firmware+kernel are on SD card, it does work on a Pi 3, even when the root file system is on NFS.

So I am guessing there is either a bug in the firmware part that is responsible for PXE booting, that leaves the firmware in such state that things go wrong when the firmware part that is responsible for camera wants to do its thing.
Or there is a bug in the camera part, that only causes real trouble in some conditions. (can be that when PXE booted kernel is loaded at different memory address or something like that).
That are just wild guesses though. I don't have access to firmware source, so have no idea what goes behind the scenes there.

[jonwitts]

So if I were to get an SD Card image of Buster how would I go about adding it to PiServer for my Pi 4 clients to boot from? I have seen some talk of a convert.sh script but not sure where that is...

[maxnet]

1. If your Piserver computer is currently running Debian Stretch, you may need to borrow a newer qemu version from a more recent Debian version.

http://ftp.de.debian.org/debian/pool/main/b/binfmt-support/binfmt-support_2.2.0-2_i386.deb
http://ftp.de.debian.org/debian/pool/main/q/qemu/qemu-user-static_3.1+dfsg-8~deb10u1_i386.deb
(install in that order, binfmt first)

@XECDesign
Perhaps the newer qemu version could be added to Stretch x86 repository as well, so people get it automatically when doing "apt-get upgrade"?
(The older version has the "qemu: Unsupported syscall: 383" hang when running some apt-get commands on a buster rootfs)

2. Convert the image

wget https://downloads.raspberrypi.org/raspbian_full/boot.tar.xz
wget https://downloads.raspberrypi.org/raspbian_full/root.tar.xz
sudo /var/lib/piserver/scripts/convert.sh boot.tar.xz root.tar.xz Debian_Buster.tar.xz

3. Import the .tar.xz to Piserver

4. Contents of /var/lib/piserver/os/name-of-os/boot must be put on FAT formatted SD card.
   (Piserver already edited your cmdline.txt to point nfsroot to the Piserver server, so no additional modification should be necessary)

[jonwitts]

Thanks! I will give this a go later today hopefully!

1. If your Piserver computer is currently running Debian Stretch...

Am I able to perform a distribution upgrade to Debian Buster of the PiServer or is this untested? I am still working on testing servers at the minute as I need to rebuild my production PiServer for a couple of reasons...

1. I want to integrate it with Active Directory - my biggest time loss in lesson last year was students forgetting their password for the Raspberry Pi Server...
2. I did not build it with a large enough HDD so I want to reconfigure with a separate HDD for /home so it becomes easier to expand it in future if I need to...

Should I use the RPi Desktop image and try to update to Buster or just install Buster from Debian and then compile PiServer on that?

[maxnet]

Will leave the answer on what the status is of "Debian Buster with Raspberry Pi desktop for x86" to someone else.
(Don't know myself)

But regarding storage expansion:

I did not build it with a large enough HDD so I want to reconfigure with a separate HDD for /home so it
becomes easier to expand it in future if I need to...

If you want easy expansion, choose LVM partitioning during Debian installation.
That allows you to add ADDITIONAL hard drives later. No need to REPLACE the existing one if you have free sata ports on your server.

[jonwitts]

It's all being built in VMWare so need for SATA ports! Easier to expand a virtual HDD on the SAN and VMWare than it is to bother with LVM! ;-)

[XECDesign]

Perhaps the newer qemu version could be added to Stretch x86 repository as well, so people get it automatically when doing "apt-get upgrade"?

Added to the todo list. Thanks for the heads up.

[maxnet]

Added commit that adds support for the new OUI.

(Still defaults to only showing Pi that are actually netbooting in the "add servers" screen.
If you want it to include non-PXE DHCP requests, and are compiling Piserver yourself, you can remove the line starting "#define DHCPANALYZER_FILTER_STRING" from src/config.h)

[jonwitts]

When attempting the final step here:

1. Convert the image

wget https://downloads.raspberrypi.org/raspbian_full/boot.tar.xz
wget https://downloads.raspberrypi.org/raspbian_full/root.tar.xz
sudo /var/lib/piserver/scripts/convert.sh boot.tar.xz root.tar.xz Debian_Buster.tar.xz

I am told I need to install pxz. Should that be added to the list of dependencies?

[maxnet]

Should that be added to the list of dependencies?

Not sure.
Don't know how common it is that someone convert's his own images.

(and it is possible to compress the image without pxz as well, but pxz has the advantage it can use multiple CPU cores to compress)

[jonwitts]

OK... I have got this up and running on my testing virtual machine and have one of my Pi 4 booting and logging in through PiServer :-D

I am going to get a Buster image updated and tweaked how we need it here in school and then look at getting this set up and running on production. In the end I did not upgrade the PiServer to Buster as this just seemed to create a far too unstable solution. I will write this all up into a blog post to in case others are interested!

One last question... Is it safe to unmount the /boot SD Card once the Pi has booted? If it is I was thinking of writing a Bash script which runs at login and unmounts the SD Card so that it does not show on the desktop of the logged in Pi...

Thanks for all your help on this

[maxnet]

Is it safe to unmount the /boot SD Card once the Pi has booted?

The kernel is loaded from SD card into memory by the Pi firmware, not by Linux itself.
So for booting there is no need at all to have it mounted in the first place.

If it is, it is probably caused by LXDE/gvfs's habit to automatically mount any removable storage available.
Can probably tell it not to by giving the FAT partition of your SD card a special FAT label like "RECOVERY"

[Lukanite]

You also might want to check via df -h to make sure that /boot is pointing to your SD card; for me /boot just points to the server's /boot under the "/" entry, so there's nothing to unmount.

[XECDesign]

Perhaps the newer qemu version could be added to Stretch x86 repository as well, so people get it automatically when doing "apt-get upgrade"?

Small hurdle. Qemu 3.1 requires a newer version of libcacard (smartcard support) than what's in Stretch. So I need to do one of the following:

1. Disable smartcard support, possibly upsetting anybody relying on it.
2. Upgrade libcacard and, if necessary, its reverse dependencies. That may break other packages which are higher up the chain.
3. Just steal the qemu-user-static and binfmt-support debs from buster.

Although the downsides of 1 and 2 are very unlikely, 3 seems like the easiest and has the lowest risk, so if there are no objections, I'll go for that option.

[jonwitts]

Thanks all! :-D

I now have a production PiServer up and running for my Pi 4s. I am going to test it a bit more later this week once I get all of the classroom Pis set up. I have written a blog post up here: https://www.jonwitts.co.uk/archives/1222 about the whole setup process.

Thanks again :-D