Today we're going to take a look at Netboot.xyz. So netboot.xyz is a PXE boot utility that allows you to boot to the network and select any operating system you want, or even boot utilities to run recovery tools. So instead of booting to a USB drive like you would typically do, you could just boot to the network and then choose any installer for any operating system you want to install. Think of it like plugging your USB drive into the network and being able to boot from that from any machine on your network. This makes installing new operating systems and even distro hopping super easy. You don't have to keep rewriting your USB drive over and over. You just boot to the network and select a different operating system and then evaluate it on that machine. And these machines can be virtual or physical. Another cool thing about NetBoot XYZ is that you can self-host this in your own environment and you can customize it to your liking. If you want to build a custom installer, you can. If you want to host all the ISOs and all of the files so that it doesn't reach out to the internet, you can do that too. You want to build a custom Windows pre-boot environment to install Windows over the network, you can do that too. So that's what we're going to set up today. We're going to set up NetBoot XYZ. We're going to self-host it on our own environment. We're going to do that using a Docker container. We're going to configure DHCP so your machines can boot to the network and boot to NetBoot XYZ. And then we'll boot and configure many different operating systems and utilities. Going into this, I thought that everything was going to be super complex, but it turns out it's pretty easy. And I've figured out all of the hard parts for you. First, you're going to need a machine with Docker installed. You need help setting up Docker? I have a guide on that and I'll link to that in the description below. Then you want to make sure that that machine has a static IP. And that's because we want to make sure that this IP address doesn't change because we're going to be configuring DHCP to point to this IP address when machines boot. Last, you'll need access to your DHCP server. And that's because we're going to configure an option for machines to pixie boot to this IP address. Don't worry, we'll take care of that later. So you want to remote into your Docker machine and once you're there, you want to create a directory. You want to create a directory for your NetBoot XYZ files and folders. This can be named anything you want, but I'm going to name mine NetBoot underscore XYZ. Once you've created it, you want to cd into that directory and you want to make two directories. You want to make an assets directory and you want to make a config directory. Next, we want to create a Docker compose file in this directory. And that's as easy as doing a touch Docker dash compose dot yaml or a nano or your editor of choice and then creating this file. Now your directory should look like this NetBoot XYZ. You should add a folder called assets, a folder called config and then a file called Docker dash compose dot yaml. Now we'll want to edit this Docker compose file and put some contents in it. Now, what contents are we going to put in there? Well, we're going to put the configuration for NetBoot XYZ. Now NetBoot XYZ has an official container from NetBoot XYZ and an unofficial, I guess, container from Linux server dot IO. You can use either one and I'll have configuration for both in my documentation. But we're going to use the one from Linux server dot IO. So if we look at the Linux server dot IO version, it looks like this. It has a service or a stack of one just for NetBoot XYZ. We're listing out the container and the tag of latest that we're naming this container NetBoot XYZ. Then we're given a PUID and a PGID. That's just the ID and group of the user that we're going to run these containers as. And we're going to set a time zone. If your server is in UTC time, which is a great idea, you can set it there with using UTC. Then we're going to set our menu version. Now NetBoot XYZ has different configurations, different menus that you can choose. Pretty cool. You can actually use different versions of menus with different versions of files and assets for the server. So anyways, long story short, you can either pin this to the latest one, which is to something, or you can unset this variable, which will always grab the latest. Now I've been trying with latest. It's been working out fine. That's not to say it will always be fine because latest is non-deterministic, meaning each time you run it, latest means something different or could mean something different. So anyways, we'll unset this and I'll show you here in a second. Then we're going to set some ports. Then we're going to set a subfolder. I don't use this. Then we're going to set some volumes and we're going to set some more ports. And then we're going to tell it to, hey, restart this container unless I stop it myself. Now here's my version of the Docker compose file, almost exactly like what we talked about here. I am commenting out the menu version. So I get the latest version of the menu. Some changes that I made were just paths to the volume. So my path to the volume is going to be relative. So on the outside of the container, I'm mapping to the relative path of config to the inside of the containers config. And the same thing with assets, relative path to the assets folder to the inside WAC assets. And I kept all the rest. I don't know how I have this weird, not equal sign, but we'll get rid of that. So let's copy these contents and let's edit this Docker compose and we'll paste it right in here. Now let's bring the stack up and that's as simple as running Docker compose up-d. If we run Docker compose up-d, it should pull down that image. It should start running the container and it should start netboot xyz. Let's make sure it's running. So let's run Docker ps and yes, we can see that this is up. And then let's run Docker logs netboot xyz just to see that we have some logs and we do have some logs here. We can see the Linux server IO banner right here and it's running. Cool. So now it's running. So how do we get to this? Well, we can get to it on the local port that we exposed right here or right here 3000. So 3000 is the port that's exposed to get to the web app for the configuration for netboot xyz. Now, if I keep saying network boot xyz, I'm sorry. So easy to get it mixed up, but it's netboot xyz. I probably said it a few times wrong already. If you can't remember what your IP address is, you can just run IP space A and then find your IP address right here. So mine's 192.168.10.125. Then once we land on it, we should see something like this. This is super bright and totally need dark mode here. But anyways, what we're seeing here is the website to configure netboot xyz. You could see our web app version, which doesn't really matter to us is 0.69. Our menus version is 2.0.73. So that's the latest version of the menus. Now, remember, I said you could change this using that environment variable, but we set ours to latest. So it's grabbing the latest version, which is 2.073. We could see some system stance, how much memory I'm using, disk buffer usage. But this is all pretty typical stuff and it's running an nginx web server and it's also running a TFTP server. The TFTP server is used to transfer these boot files to the devices when they boot. If we go here into menus, we could see lots of different custom boot menus. So we could see our boot config file. So this is a configuration when the machine boots up. It'll read this to get more information about which environments it's booting, different variables that are set. But you could see we have lots of different pixie boot environments. We have one for Alma, we have one for Arch, one for dban, one for Fedora, one for Gen2, A3OS, pretty cool. All the way down to, we even have Windows, WinBoot and Windows and Windows iPixie. So we can pre-boot a lot of different things and don't worry, I know that this looks really confusing. We don't even have to touch any of this. I mean, we'll touch our config a little bit later just for one small change. But none of this we even have to worry about. This is all set up for us. And if we go into local assets, now this isn't all local assets. On the right is local assets and on the left is remote assets. And these are all of the environments that we can boot from. So if we want to boot from, say, Kali, Linux, we can see that, hey, Kali's here with XFCE and the squash file system. Or we could see Ubuntu should be in here as well, lots of Ubuntu stuff. dban should be in here for DIN's boot nuke to white disks. Lots of things, lots of things. So there are lots of things that we can boot in here. But if you notice, they're all remote on the left, nothing local on the right. Now before I show you the difference between local and remote, I think we should configure a DHCP server. That way we can test this out and make sure it works with all of our remotes. And then if we like, we can toggle on local and try it that way. So now we need to configure PXE boot on a router. We need to tell our routers DHCP, where the TFTP server is, and what file to ask for when it boots. Now as you can see, there are many ways to configure this for different routers. P of Sense, OpenSense, Edge or Vios, OpenWRT, Microsoft DHCP, even Pihole is in here, and Unify. All of them take the same approach, they might just be configured a little bit different. And since I have a Unify device, I'll show you where it is, but feel free to configure this for your own router. But you should watch this just so you kind of get the gist of how it works. Once I'm inside a Unify or my UDMSE, then I'll go to settings, and then I'll go to networks. Now I have VLAN set up, and I'm only going to allow this to work on one VLAN, my main VLAN. And if you have VLANs, you might have to decide if you're going to let this work on all VLANs or just one. But I'm choosing just one in my main VLAN. And then in my DHCP options, I should have a net boot option. Now in my net boot option, I'm going to put the IP address of my Docker server that we just set up. And that's really where the TFTP server is running. Then I'm going to set a file that these devices will request when they boot up. So when a machine boots up and boots to the network and does a PXE boot, DHCP will say, hey, here's your PXE server right here. It's 192.168.10.125, and here's the file to ask for. And so the machine will go out, get that file, and then it'll boot. So there's a little bit of challenges with running a UDM. I found out kind of the hard way. UDM only supports booting from one file, but as I found out, machines can ask for different files based on their architecture. And the DHCP server should be smart enough to offer a file based on their architecture. For instance, this EFI one is when I boot with an EFI device or UEFI device, and I say, hey, I'm a UEFI boot. Give me my boot file. And so this one should be EFI. But then there are legacy machines that just boot to BIOS. And they say, hey, give me my BIOS or my legacy file, and they should offer that. Or it can be an ARM device or a Raspberry Pi and so on and so forth. So if you have a unified device, I'll have documentation on how to do this, and you can find that in the description below. But for the sake of being easy and working on most systems, we're going to set it to the KPXE device. So this is the legacy BIOS PXE device. So I'm going to set that here, and we're going to apply that. And now that should be set. So now our DHCP scope has this option set. Now that that's set, we can boot to the network. Now I'm going to boot to the network on Proxmox, a hypervisor. And I'm going to create a virtual machine to where we can boot to the network to test it out. But it'll work just the same on physical machines. I did it on a couple of my machines on my workbench last night. It worked out great. So anyways, in Proxmox, I'm going to create a test virtual machine. So I'm going to create a virtual machine. Let's just call this NetBooter. Sounds good. Operating system, it really doesn't matter what we set here. ISO image, we're not going to set any here. So let's say, do not use any media because we're going to boot to the network. The guest OS really doesn't matter for us, for testing. For system, this does matter, kind of. So because we're going to be booting to the legacy BIOS, we want to make sure that we're using CBIOS. If we were going to do UEFI, we could choose UEFI here. And then as it booted, it would grab the UEFI pre-boot environment for you to install the rest of your operating system. But for me, since I hard coded my boot image to the legacy BIOS, I'm just going to use the CBIOS. But really, you would choose the BIOS that you were going to use for your virtual machine. Most machines are going to use UEFI. The SCSI controller doesn't matter. TPM doesn't matter unless you're going to do some Windows 11 stuff, or you're going to use an operating system that uses a TPM. Disk doesn't matter here either. CPU doesn't really matter. The new x86-64v2 AES should work fine. That's pretty portable. I'm still in the habit of picking host, and I know that they created that virtual model just so you didn't pick host, but I'm still picking host. Chores, doesn't really matter. I'm just going to give it, I don't know, eight. RAM, doesn't matter either. I'm just going to give it four gigs, 4096. Network doesn't really matter unless you're using VLANs. I'm going to set mine to VLAN 10, which I am. The model does matter, kind of. So those pre-boot images have drivers built into them so that they can boot to the network and grab the rest of the files that they might need, or have network while the operating system is being installed. Most of the time, for I.O. it's going to be fine if you're doing this on virtual machines. I have found, though, that sometimes I need to choose Intel E1000 because things like Windows don't understand what the VRT.io driver is in the pre-boot environment. And yes, you can load drivers later after that, but it'll save you some time if you just choose E1000 on Windows, and then later on switch it back to VRT.io. Anyways, that's a lot about pretty advanced stuff. Let's choose VRT.io, and then let's confirm this. Now, before we boot this, let's do a couple of things. So where's my netbooter? He's getting created. Now, there's a couple other things that you might want to do just for debugging. What I did was I would go into the options, and I would change the boot order to say, hey, we want to boot to network first. Now, this saves me a ton of time from hitting Escape over and over in Proxmox and choosing the boot device. I just found that while I was setting this up, if you move the network device to the first boot device, you won't have to do all that. And I think that's it. So let's go to our console and let's start this machine. And when we hit Start Machine, we should see the machine startup. We should see it boot to our network. We see it going out, pixie booting, configuring that network device. Hey, it found netbootxyz. Now, I'll grab the menu, and it rendered the menu. Awesome. So we have netbootxyz already working. So you can see here, we have choices. We can boot from our local hard drive. We can boot network installs. We can boot live CDs. We can boot BSD, Unix, Fritos, Windows. We can even boot into utilities, like a lot of different utilities. Like break-in, dban, Clonezilla, gparted, a lot of my favorite ones, memtest. They're all here, the usual suspects. Ultimate boot CD. So this is pretty cool. We can boot to the network, go into our utilities, and run a dban on any of our machines that we want on our network. And then we have some other menus here, too. You can change the architecture if you wanted to say, hey, we're 32-bit or we're 64-bit. Ipixie shell, I'm not going to go in there, but that would open a shell into Ipixie. Really, I think that's for development, to be able to debug stuff. We can get information about our network card. You can see right here, you can see, hey, my gateway is this, my Ip address is this, and you can see my DNS servers and my DHCP server. And the next dash server is our server that we spun up in Docker. And then we can do other things. Signature, check, sure. We're going to check signatures. We can see about, and we can do a lot of cool stuff. So let's do something. Should we start easy or start hard? Nah, let's go hard. Let's go hard right off the bat. Let's choose a live CD. And you can see all the live CDs we can boot from. So if you wanted to distro hop and test a lot of things out or test all of these OSes out without even installing them all from a virtual machine boot from the network, you totally could without even downloading them. That's the cool thing. And let's see, I don't know, I see Cali, I see Cady, I see PopOS, I see Peppermint. Let's try PopOS. PopOS Live 2204, sure, Intel AMD. And so now it's pulling down this file from the internet. So it's pulling down some release, I think the SquashFS release of VM Linux. So we can lay down the initial file system. And then it bootstraps that. Now you can see this is downloading at about 60 megabytes per second, so about 500 megabit per second. Now that's pretty fast, but you can see it's still taking up to 20, 30 seconds. I think there's going to be another step here too that's going to take another 20 seconds. So if you really wanted to cache this and speed things up and not limit yourself to only the ones you've cached with a NetBoot XYZ, I recommend using something like LandCache. But if you want everything offline and you want it to be super duper fast, you can absolutely use the offline method for NetBoot XYZ. And I'll show you where that is here in a second. So it looks like we're booting up. Are we going to do it? Yeah, so here we are. We're inside of PopOS. Now that's running in LaunchFirefox. This is pretty sweet. So we've network booted. NetBoot XYZ has offered us the ISO. And now we're running the live version of PopOS inside of our virtual machine. Now again, this could be on a physical machine. It could be anywhere. Here we go. We got PopOS and it's running just fine. So if you wanted to test drive PopOS on something, you could absolutely do it from here. But let's shut this down and let's try something else. So let's boot again, booting to the network. DCP is going to tell us, hey, here's NetBoot XYZ. Then NetBoot XYZ says, hey, here's your file to boot to the BIOS. NetBoot XYZ says, here's your boot menu and here's your file. We boot here. Let's choose something else. Live CD, let's do something totally different. I think K3OS is in here. Let's do it. K3OS, so a distribution of Kubernetes within an operating system or the operating system that contains K3OS from Rancher. We should see it boot up here in a second. And again, this is the live CD, but it should boot up and there we go. So we can log in. It says log in with using Rancher and we're in. And yeah, so that looks good. Okay, let's try one more. Let's try it. Quit shutdown. Who knows how to exit out of K3OS? Worse than them. There we go. Just send a SIG term to it. Okay, so next let's boot again. So one of the utilities I use all the time on a lot of machines is Gparted either for resizing partitions, creating partitions, or just wiping out partitions. Gparted is definitely the way to go. I noticed there's also something else called something I never tried before. RescueZilla caught my eye earlier. And this one also has Gparted on there along with I think CloneZilla. I think this is a combination of CloneZilla plus Gparted and one, which is pretty cool because those are two tools I use a lot. And correct me if I'm wrong if it's not exactly CloneZilla, but kind of looks like it. Here we go. RescueZilla. And this is the RescueZilla interface. So it looks like we can backup, restore, clone drive. So pretty cool. We're not going to use that feature because really I wanted to use Gparted, but I wanted to show you that. So here's Gparted. Here's our disk. You know, if we wanted to create a new partition table and do, you know, whatever, GPT, accept, create a new partition, and apply, add it, apply, okay, and create a partition so we can do all of the things we can normally do on Gparted. So pretty cool. We have all of these tools at our fingertips shut down. So now we're going to pivot really quick from remote assets to local assets. And I talked about it a few times, but we haven't done it yet. So if you remember, we downloaded PopOS and that took about 60 seconds to download the internet. It was about 500 megabits per second. And that's pretty fast, but you might not have 500 megabit download, or you might be in air gapped environments where you don't have internet at all on the VLAN that these are on, or the subnet. So what you can do is download these as local assets. So let's do that. So let's download PopOS. I forget what version we downloaded. I thought it was 2204, and I think it was. So we want to download all three of these files, the squashFS, the intrad and the VM's, VM Linux. We want to download all of those. But let's download those. So we'll pull select it. You should see this little progress bar up here. It shouldn't take long. And once we have all three of those downloaded, you should see them on this side. So now that these are downloaded, we need to do one more thing, and let's change one of our menu configs. So let's look at our boot CFG really quick. And so this is the boot config that all devices use to look up different variables, to know how to configure, you know, the boot environment. The one that we're looking for that we're going to change right here is set live endpoint. So this is actually looking at github.com slash netbootxyz. So instead of pointing it at github, we need to point it to our Docker machine. So what I'm going to do is I'm going to actually copy this here, set this here, and then I'll comment this out so I know what it was before. And so our local IP is not over HTTPS unless you're going to set up certificates. It's actually HTTP, and ours should be 192.168.10.125, and then we'll need the port, which is 8080. So this is saying, hey, our live endpoint now is our Docker machine that we created, and it's not over HTTPS. You can use the cert later if you want. And the port we're going to use is 8080 because that's the one that this website uses when it spins up. So let's save this configuration now, and we should see our live endpoint now is our internal IP. So now let's go into Proxmox again. Let's start up a virtual machine. It's booting to netbootxyz. It gets our menu. And now we should be able to boot from that live CD, and it was pop OS. And once we hit enter, we shouldn't see a progress bar, almost no progress bar at all. Hit pop OS, 2204, AMD Intel, and you can see it just downloaded it that quick. You can't even see a progress bar. Now it's downloading, so you can see it. So 400, yeah, it was going a gigabit. It was so fast. And then it looks like we're booting. And here we are inside of pop OS, and we could do all the same things we could do before. So let's shut this machine down, and I want to show one more thing. So what happens if we boot to one of the OSes that we didn't cache locally? Now remember, our live server config is pointed local and not a GitHub anymore. So what happens? Nothing changed on the menu because that's baked into netbootxyz. Actually, you can customize it yourself, but that didn't change. But what happens if we say want to do a live CD and we want to do Debian and we choose Bookworm Cinnamon? Now you can see here, could not boot no such file in directory. So it's saying that, hey, you don't have this file in your directory. And that's where I was saying like, hey, if you want to speed this up across the network, you might want to use a system-wide caching tool rather than this. But if you want all of these images offline and you want to cache them all yourself, go for it. You can. So let's cache that one just to prove this all the way through. So let's power down, shut down. Won't shut down. Here's the other way of doing it, monitor. I'm going to go to quit. So that should quit that. There it goes. And then so on netbootxyz, we need to look for Debian. Lots of Debian is going on and we want Cinnamon. I think it was Cinnamon. Oh, it was 12. It was Bookworm. So we want Cinnamon, Debian, Cinnamon, squash right here. So let's download this one. All selected. Okay. Now Cinnamon is downloaded. So let's go back into our machine. Let's boot this. Pixibooting, live CDs, Debian, back to 12 Bookworm, Cinnamon. Oh, I downloaded the wrong one. We need Debian 12 live kernel. So let's download that. Let's make sure because I'm not familiar with all of these. That looks right. Default? Let's download default too. I'm not too familiar with which actual images they're downloading and which ones they use. I thought I could tell just by looking. And you might run into this too when you're trying to figure out which image matches to which menu item. Again, why I recommend just using the live or the remote assets from GitHub. Okay, let's try this one more time. Press any key to go back to menu. We'll do that. Live CD, Debian, Bookworm, Cinnamon. There we go. So it's going now. So it's going to boot into Debian. And it looks like Debian's booting. And here we go. Debian, Bookworm with Cinnamon. So pretty awesome. This works great. Now this will work for all different operating systems and all different boot configurations as you can see from the menus. You could actually go through and install server operating systems like Ubuntu Server if you wanted or Debian Server. You can install them too and not just run these live environments like we're doing now. But you could also boot from a Windows environment and set up and install Windows to any machines on your network. I have that set up. I can boot to Windows 11, boot disk and install Windows 11 either on virtual machines or physical machines back there. I'm not going to go into detail on how to do that now, but I will have a fully written blog post that accompanies this video. And you can find that in the description below. So I hope you now see how powerful NetBoot XYZ is and what you can do with it. Well, I learned a ton about pixie booting, DHCP scope options, NetBoot XYZ, and I hope you learned something too. And remember, if you found anything in this video helpful, don't forget to like and subscribe. Thanks for watching.
