Posts made by Tauric

@Tom-Elliott Also my existing images don’t seem to be deploying properly:

is it possible to roll back the update somehow?

@Tom-Elliott Hi Tom, thanks for the reply. It’s on version 1.5.10.34.

There are two VMware machines I update then capture regularly and neither seem to be working since i’ve updated FOG.

I don’t understand enough about disk operation for that bugzilla to make such sense to me haha, both drives are listed as NVME in VMwares settings. Do I disable acpi for the VM then?

I recently updated my FOG server to the newest version, ever since I get some odd errors when capturing and It never seems to complete. Would appreciate some help with this, thanks.

@george1421

Hi George, thanks for the response,

Apologies if I’m doing things wrong here, the log level was set as 4 in the fog settings, changing it to 7 doesnt seem to have done much here. Also for the initrd=init.xz it returns ‘command not found’ unless i’m entering this in the wrong place or something?

As a sidenote, the http transfers are far slower than normal in this parallels environment, I’m testing the Hirens BootCD image I have on the server and its moved the boot.wim 3% in the time I’ve typed this out.

I have found a workaround for this as parallels does let you import .VMX files from VMware, I have to assume its some kernel incompatability or something.

Thanks for the suggestions

I’m running parallels with bridged networking on an intel iMac, i’m attempting to deploy a windows image to it (successful on other machines and VM’s on the same LAN) but i’m getting the following error:

Not sure why this behaves so differently as it shouldn’t be ARM and is EFI like my vmware vm’s, I assume this is an issue with init.xz not being pulled across, but I’m not really sure why

-Tauric

@Tauric

I guess its just something wrong with this specific build of windows, I freshly reinstalled windows and setup the image again, this time it seems to be capturing the correct size

Still not sure what the issue here was, I guess fog was unable to resize the partition?

Hi all,

I have 4 images in my FOG server at the moment, they all show the correct ON CLIENT size aside from one, for some reason it is showing the size of the fixed disk that I captured from (64.01gb)

I doubt this is anything more than a cosmetic issue as images deploy fine and show the correct size after deployment, however I was wondering if there’s any easy fix for this? I tried recapturing but the size didn’t change.

d1.minimum.partitions (below) shows the Microsoft Reserved Partition as 132892160 sectors, which at 512kb per sector in gibibytes is 63.37GB.

d1.minimum.partitions.txt

The deployment looks odd as the total block progress is at a lower percentage than the data block process, it does show the actual space in use on the image as 17.1GB which is correct:

when this partition finishes the total block progress jumps to 100%

Edit: A normal deployment at part 3 for reference:

As far as I can see none of the settings are different between images.

Thanks for any suggestions

@george1421 Just got around to testing dnsmasq today, It worked flawlessly (and took less than 10 minutes lol). Thanks for the help here

@george1421 That makes sense, i’ll mark the thread as solved tomorrow if that works, the process does look pretty simple

I’m unsure as to why the Draytek router is sending the DHCP options like this, but honestly it is a bit old and they aren’t the most reliable in general haha

@george1421 I sent the pcap as is, aside from renaming it, I moved it from the ubuntu machine to an smb share on my windows box before uploading it here, I did notice the unprintable characters but I just assumed that was some issue with how the pcap was captured, I checked in the draytek and the options look fine, 66 is set as an address and the value is 192.168.0.26, not sure what you mean about the trailing character on ipxe.efi for 67.

Cheers for the advice on this, ill probably just go with the dnsmasq as suggested

Thanks for the help
-Tauric

@george1421

Hi George,

Thanks a lot for the quick response here, it appears the tftp GET works with the windows firewall disabled:

tftp -i 192.168.0.26 GET ipxe.efi                           
Transfer successful: 1093120 bytes in 1 second(s), 1093120 bytes/s

So that obviously points to something blocking the ephemeral port of the boxes that are pxe booting, however I’m unsure as to where this would be, the router is a Draytek and has the firewall disabled and UFW is off, unless theres another firewall i’m not aware of in ubuntu?

In the attached PCAP the first two requests (as well as one about halfway down) are informs from IP phones, there are 6 read requests before the PXE process fails.

Draytek (router, dhcp and dns): 0.254
PXE’ing box: 0.33
Ubuntu FOG server: 0.26

PXEoutput.pcap

Thanks again

Hi guys, I recently decided to move from WDS to Fog and have began setting it up today but have ran into some issues with TFTP-HPA

I have a VMWare workstation VM running the latest release of ubuntu (freshly installed today), any TFTP get requests (either manually or from PXE) seem to be timing out.

Running tftp from windows shows

tftp 192.168.0.26 get ipxe.efi
 Connect request failed

with the TCPDump showing:

    192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:05.206384 IP (tos 0x0, ttl 128, id 3541, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:07.212387 IP (tos 0x0, ttl 128, id 3542, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:11.219890 IP (tos 0x0, ttl 128, id 3543, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:19.225284 IP (tos 0x0, ttl 128, id 3549, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:27.229313 IP (tos 0x0, ttl 128, id 3550, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:35.237293 IP (tos 0x0, ttl 128, id 3551, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:43.239364 IP (tos 0x0, ttl 128, id 3552, offset 0, flags [none], proto UDP (17), length 48)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 20, RRQ "ipxe.efi" netascii
    
    16:17:51.245345 IP (tos 0x0, ttl 128, id 3553, offset 0, flags [none], proto UDP (17), length 51)
    
        192.168.0.87.53571 > pcNameHere.tftp: [udp sum ok] TFTP, length 23, ERROR EUNDEF "timeout on receive"

The tftpboot permissions are:

/var/log# ls -l /tftpboot
total 6164
drwxr-xr-x 4 fogproject root    4096 Oct 27 15:14 10secdelay
drwxr-xr-x 2 fogproject root    4096 Oct 27 15:14 arm64-efi
-rw-r--r-- 1 root       root     457 Oct 27 15:14 default.ipxe
drwxr-xr-x 2 fogproject root    4096 Oct 27 15:14 i386-efi
-rw-r-xr-x 1 fogproject root  268288 Oct 27 15:14 intel.efi
-rw-r-xr-x 1 fogproject root  104229 Oct 27 15:14 intel.kkpxe
-rw-r-xr-x 1 fogproject root  104277 Oct 27 15:14 intel.kpxe
-rw-r-xr-x 1 fogproject root  104233 Oct 27 15:14 intel.pxe
-rw-r-xr-x 1 fogproject root 1093120 Oct 27 15:14 ipxe.efi
-rw-r-xr-x 1 fogproject root  907264 Oct 27 15:14 ipxe.iso
-rw-r-xr-x 1 fogproject root  371566 Oct 27 15:14 ipxe.kkpxe
-rw-r-xr-x 1 fogproject root  371614 Oct 27 15:14 ipxe.kpxe
-rw-r-xr-x 1 fogproject root  370994 Oct 27 15:14 ipxe.krn
-rw-r-xr-x 1 fogproject root  370994 Oct 27 15:14 ipxe.lkrn
-rw-r-xr-x 1 fogproject root  371834 Oct 27 15:14 ipxe.pxe
-rw-r-xr-x 1 fogproject root  409600 Oct 27 15:14 ipxe.usb
-rw-r-xr-x 1 fogproject root   26140 Oct 27 15:14 memdisk
-rw-r-xr-x 1 fogproject root  299008 Oct 27 15:14 ncm--ecm--axge.efi
-rw-r-xr-x 1 fogproject root  266240 Oct 27 15:14 realtek.efi
-rw-r-xr-x 1 fogproject root  104968 Oct 27 15:14 realtek.kkpxe
-rw-r-xr-x 1 fogproject root  105016 Oct 27 15:14 realtek.kpxe
-rw-r-xr-x 1 fogproject root  104987 Oct 27 15:14 realtek.pxe
-rw-r-xr-x 1 fogproject root  266240 Oct 27 15:14 snp.efi
-rw-r-xr-x 1 fogproject root  266752 Oct 27 15:14 snponly.efi
-rw-r-xr-x 1 fogproject root  103589 Oct 27 15:14 undionly.kkpxe
-rw-r-xr-x 1 fogproject root  103637 Oct 27 15:14 undionly.kpxe
-rw-r-xr-x 1 fogproject root  103666 Oct 27 15:14 undionly.pxe

UFW is disabled (fresh install so it shouldn’t be anyway)

/var/log# sudo ufw status
Status: inactive

tftp-hpa config:

/var/log# cat /etc/default/tftpd-hpa 
# /etc/default/tftpd-hpa
# FOG Modified version
TFTP_USERNAME="root"
TFTP_DIRECTORY="/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="-s"

tftpd-hpa status:

/var/log# sudo systemctl status tftpd-hpa
● tftpd-hpa.service - LSB: HPA's tftp server
     Loaded: loaded (/etc/init.d/tftpd-hpa; generated)
     Active: active (running) since Fri 2023-10-27 15:52:46 BST; 29min ago
       Docs: man:systemd-sysv-generator(8)
    Process: 47694 ExecStart=/etc/init.d/tftpd-hpa start (code=exited, status=0/SUCCESS)
      Tasks: 1 (limit: 4556)
     Memory: 440.0K
        CPU: 72ms
     CGroup: /system.slice/tftpd-hpa.service
             └─47702 /usr/sbin/in.tftpd --listen --user root --address :69 -s /tftpboot

Oct 27 15:52:46 fbs-virtual-machine systemd[1]: Starting LSB: HPA's tftp server...
Oct 27 15:52:46 fbs-virtual-machine tftpd-hpa[47694]:  * Starting HPA's tftpd in.tftpd
Oct 27 15:52:46 fbs-virtual-machine tftpd-hpa[47694]:    ...done.
Oct 27 15:52:46 fbs-virtual-machine systemd[1]: Started LSB: HPA's tftp server.

Thanks for any suggestions

Edit: the VM’s are all bridged networks with their own IP’s which works fine with WDS