PXE Issue Ubuntu 20.04
-
@rogerbrowntdl Same questions I asked still apply. I’m working towards having you test something but I need to know a bit more about your network layout to know if it will work.
Is the FOG server on the same subnet as the pxe booting target computer?
This is what I’m working towards but I need to know how your network is setup: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
-
@george1421 Yes same subnet/VLAN
DHCP = Watchguard 192.168.15.254 with option 66 set to 192.168.15.251 and 67 set to undionly.kpxe
FOGServer= 192.168.15.251 -
@rogerbrowntdl OK great the tutorial I linked to will work for your situation.
You can use the FOG server to capture the packets. What we want to do is see exactly what the dhcp server is telling the target computer to boot.
You can use the FOG server for this you will get the best quality packet capture because it will capture the broadcasts as well as the tftp queries.
The other option is to load wireshark on a witness computer to listen to the dhcp process only. Use a capture filter of
port 67 or port 68to only capture the dhcp process packets.First get the pcap file then I can tell you where to look for the answer or you can post it on a file share site and I can look at it. Its not hard to understand reviewing the pcap in wireshark (you will need to review the pcap with wireshark even if you captured it with the fog server)
-
@george1421 Hopefully this makes more sense to you than me fella https://1drv.ms/u/s!Aoxev2npVk1SiWpaTnty3O3t5xkG?e=aKd03S
-
@rogerbrowntdl Something happened to that pcap its damaged. Almost like its not complete. So the pcap you created on the fog server was 3.8kb in size? That is what was downloaded.
-
@george1421 I will try run PXE on 2x machines which may give more to go off. The one I sent was the PCAP for a local VM running on the same host that the Ubuntu server is running from. I will run it on a physical machine on that same LAN and get the output
-
@george1421 Done the same commands, it tells me 8packets captured, 8packets received by filter and 0 packets dropped by kernel. This is the PCAP https://1drv.ms/u/s!Aoxev2npVk1SiWzNGWOy_w0bkejb?e=KPl8z5
-
@rogerbrowntdl OK I see the problem. Your dhcp server is not passing out the IP address of the FOG server.
Open up the pcap in wireshark. When you load it into wire shark there should be 3 main sections in the body of the program. At the top you will see the 8 packets it captured. This tells the whole story. The packet flow is Discover (client) Offer (dhcp server) Request (client) ACK/NACK (dhcp server).
Select the Offer packet from 192.168.15.254. In the middle window click on the plus next to Dynamic Host Configuration Protocol line. In the expanded selection at the top there is the eithernet header bit. For the bootp part you need to have the next-server and boot-file-name fields completed. These are both blank so that tells me you don’t have the bootp protocol enabled in your dhcp server. If you scroll down a bit to the dhcp section and expand that you should have dhcp options 66 (ip address of fog server) and dhcp options 67 (boot file name)
this one is there. So you need to look at your dhcp server and enable both bootp (sometimes called netboot) and fill out dhcp option 67.There is another option since you are using a firewall for dhcp services, to add flexability to your network you can just install dnsmasq on your fog server. With this configuration dnsmasq will function much like the ProxyDHCP function in WDS. Where dnsmasq will hand out only the pxe boot info and your main dhcp server hands out everything else. It takes about 10 minutes to install on the fog server and will make your pxe booting a bit more dynamic. I’m only offering this as an option if you can’t get your router to hand out the proper dhcp pxe boot settings.
ref: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server -
@george1421 Bingo!!! I’m up, just a couple of additional questions and this topic can be closed. Once i’ve captured my image, if I deploy that to a target machine will it wipe the drive and put my image on? (I want it to do that rather than just adding/appending the image to the drive) - Sounds a stupid Q I know.
Last question is can the storage node be increased past 50gb or is it a case of when that node is full I have to create more?
Cheers for your help so far mate, its been invaluable
-
@rogerbrowntdl said in PXE Issue Ubuntu 20.04:
I deploy that to a target machine will it wipe the drive and put my image on?
Yes when you go to write the data the partition table is replaced on the target computer with the captured image partition table. Then the data is over written.
can the storage node be increased past 50gb
Do you have a storage node or are you referring to the main fog server as a storage node? Either way the answer is kind of it depends. You can either install a new disk/VMDK file that is larger and then move your images to that drive do a little directory remapping (< 5 commands) and then move on with your life. If your root volume was created using LVM you can just add a new disk to the volume group and then let linux manage things. In both of the previous solutions you will no touch the fog configuration because you will do things at the OS level. The last way to do it is to add another disk to the fog server as a second disk, then go into the FOG configuration and create a second storage node configuration. FOG will think there are two storage nodes, then you can decide where to store the image. Its a bit more complicated but the use case might be you have flash storage where you would put the most common images and slower HDD media for infrequently used images.
-
@george1421 Within Hyper-V I gave it a 127gb harddrive, within Fog management the file system info is showing the following:
Total Disk Space 100.04 GiB
Used Disk Space 24.19 GiB
Free Disk Space 75.84 GiBOn the dashboard for Fog storage node it shows
34.68gb free…So 2x things here really, if I expand the VHD within hyper-v by 100gb, will Linux and thus Fog automatically see that and if so, how do I get the Fog storage node to grab that 100gb more space (I’ve got 1TB of physical space to play with on the host so expanding the VHD of linux wont be a problem)
-
@rogerbrowntdl Ok so you went with option of adding a second hard drive/vmdk. This is the preferred path. Because after we are done here if you need to expand your storage you just expand the vmdk and then expand the linux OS.
So to do the next steps I want you to post the output of these two commands
lsblk df -hThis will tell us how you have things connected and sets the stage for the next steps.
-
@george1421 Outputs are as follows. I’ve not expanded the VHD yet
root@tie-fogdeploy-01:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0 2:0 1 4K 0 disk loop0 7:0 0 61.9M 1 loop /snap/core20/1328 loop1 7:1 0 61.9M 1 loop /snap/core20/1405 loop2 7:2 0 55.5M 1 loop /snap/core18/2344 loop3 7:3 0 67.2M 1 loop /snap/lxd/21835 loop4 7:4 0 67.8M 1 loop /snap/lxd/22753 loop5 7:5 0 43.6M 1 loop /snap/snapd/15177 loop7 7:7 0 11M 1 loop /snap/nmap/2608 loop8 7:8 0 44.7M 1 loop /snap/snapd/15314 sda 8:0 0 127G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 1.5G 0 part /boot └─sda3 8:3 0 125.5G 0 part └─ubuntu--vg-ubuntu--lv 253:0 0 62.8G 0 lvm / sr0 11:0 1 1024M 0 romroot@tie-fogdeploy-01:~# df -h Filesystem Size Used Avail Use% Mounted on udev 16G 0 16G 0% /dev tmpfs 3.1G 1.1M 3.1G 1% /run /dev/mapper/ubuntu--vg-ubuntu--lv 62G 24G 35G 41% / tmpfs 16G 0 16G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/loop1 62M 62M 0 100% /snap/core20/1405 /dev/loop0 62M 62M 0 100% /snap/core20/1328 /dev/loop3 68M 68M 0 100% /snap/lxd/21835 /dev/loop2 56M 56M 0 100% /snap/core18/2344 /dev/loop4 68M 68M 0 100% /snap/lxd/22753 /dev/loop5 44M 44M 0 100% /snap/snapd/15177 /dev/loop7 11M 11M 0 100% /snap/nmap/2608 /dev/sda2 1.5G 109M 1.3G 8% /boot tmpfs 3.1G 0 3.1G 0% /run/user/0 /dev/loop8 45M 45M 0 100% /snap/snapd/15314 root@tie-fogdeploy-01:~# -
@rogerbrowntdl Ok this changes the picture a bit your partition 3 on the first disk is 125GB but its only has a 62GB root partition.
So you are at a crossroads. You can go and extend the logical volume to fill the 125GB partition. and be stuck in this design at 125GB (with this design) image directory.
Or restart your design with 1 50GB vhd and install ubuntu, then before installing FOG create a second vhd of what ever size you think you will need for the images, lets say 100GB. You would then use fdisk to create a partition then format it as xfs or ext4 format. And finally you would create an images directory and then mount /dev/sdb1 to /images. Then install FOG. FOG will not know the actual images disk is not on the OS disk. There will be no chance of you accidentally filling up the root partition and breaking ubuntu. The now nice bit comes, if you find out you need more than 100GB you just expand the vhd then expand the disk partition and OS size to what ever size you need. You will not touch the root partition (think C drive in windows) when expanding your storage.
There are still a number of options you can do, it just looks like ubuntu installer left you in a strange place to start from.
-
@george1421 at the present setup we are quite small so shouldnt need over 100gb, however for future proofing if I extend the VHD on hyper-v to say 500gb how do I extend the partition to claim that extra space? (from what you’re saying it’s the root partition that both fog and ubuntu are running off - this makes sense as I added no second disk for images) Once i’ve done that will the images directory/fog storage node auto detect that and adjust accordingly or will I have to do extra commands on Ubuntu for it to see it?
-
@rogerbrowntdl said in PXE Issue Ubuntu 20.04:
for future proofing if I extend the VHD on hyper-v to say 500gb
Unfortunately that was one of the options I didn’t feel would add value. I must have done a bad job of explaining the situation. My suggestion was to live in the walled garden that has been created for you until you grow out of it or rebuild from the ground up.
The ubuntu/OS disk only should consume about 30GB of space. I would suggest that you make it 50 GB for updates and whatnot. This is before you even load fog on it. Your Ubuntu install uses something called LVM (logical volume manager), which is a good thing, but in this instance it gets in the way.
Your current situation is that the ubuntu install has created 3 partitions on that current vhd. You have boot, swap, and then partition 3 where the root file system is (think windows c drive). On that 3rd partition is a LVM volume. That lvm volume is using 62GB of the 125GB volume… <thinking>
Edit: OK this may be the solution here to salvage what has been created for you.
On your /dev/sda3 (third partition on the first hard drive) it is 125GB in size. The lvm volume group (think of it as a virtual virtual disk) ubuntu–vg and lvm logical volume (think of it as a virtual virtual partition) ubuntu–lv (isn’t abstraction great!!) is only consuming 62GB of that 125GB physical partition.
So the first thing we need to do is backup or snapshot this VM, because the next steps could be destructive.
Goal here is to extend the VLM volume ubuntu–vg to the extent of the physical partition /dev/sda3 (this partition at the end of the disk will allow us something usable in the future.). I’m not sure that the logical volume group needs to be extended, but I think yes. I would try to extend the logical volume first and if it complains then extend the lvm group. I did find a tutorial on how to do this and its use case fits pretty closely with your situation. See ref below.
You should be able to start with the section Modify (extend) the LVM: In this case they reference
/dev/vda1you should use/dev/sda3so your extend command should look something like this (follow along with their tutorial)sudo lvextend -l +100%FREE /dev/ubuntu--vg-ubuntu--lv(get the value from the lvdisplay not trust what I glued together. If all goes well it should extend that 62.8GB LVM to 125GB. You should use thelsblkcommand to confirm this happens. If it works correctly your root file system should grow from 62GB to 125GB after you run theresize2fscommand.If that works then it puts you in an OK place. Because if you need more than 125GB for images then you can extend the VHD file (leaving room after
/dev/sda3. You can extend /dev/sda3 partition and then repeat the same process as above to extend the LVM to the new size of/dev/sda3.While the above is surely possible I don’t know which would take more time, simply spinning up a new fog server as I mentioned before with a 50GB hard drive then before adding FOG add a second vhd and linking it into the /images directory before installing FOG, or just extending the VLM volumes.
-
@george1421 You sir are a fucking LEGEND!!! I’m all set for now. Time to get playing with images and deployments. Thank you so so so sooooo much
