Hey guys we just ran into this same exact problem. We found that if you disable DMA Protection in the BIOS it will PXE boot no problem. Just wanted to leave this out there for you to try.

@george1421 Understood.

For us it’s just extra steps we try to eliminate. We are a pretty large school district with over 65K students and 10K employees and a lot of machines. We have more then once had to re-image an entire campus because a virus outbreak and being able to push an image to a school and just telling them to reboot has saved us a lot of time in the past. Thankfully this hasn’t been an issue in a long time. Maybe times are changing and UEFI is going to force our hand…

I just received this exact same model laptop and I’m having the same problem. I’m using the onboard NIC with the ipxe.efi loader. The onboard NIC is an Intel 1219-V

Here is what I’ve done so far:

• Updated the ipxe.efi manually.
• Updated the BIOS to the latest version.

Using ipxe.efi it gets stuck “iPXE initalising devices…”, however if I set the snp.efi it boots successfully.

We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

Hey guys,
I think the answer to this is no, however I need to make certain. Under a vanilla install of FOG (Ubuntu), as the title says, is log4s installed/utilized? Should we be concerned about our FOG server running this exploit.

FWIW - We don’t see any trace of it on our server.

@george1421 Understood.

For us it’s just extra steps we try to eliminate. We are a pretty large school district with over 65K students and 10K employees and a lot of machines. We have more then once had to re-image an entire campus because a virus outbreak and being able to push an image to a school and just telling them to reboot has saved us a lot of time in the past. Thankfully this hasn’t been an issue in a long time. Maybe times are changing and UEFI is going to force our hand…

@rankinc FWIW the only thing we did was, disabled secure boot, disabled DMA protection, changed the UEFI boot order to nic first (I also disabled all the other options) and it started working.

We were facing the exact same problem in the screenshots above. We are using ipxe.efi

EDIT: My machine also hangs at “rEFind - Initializing” after the image has been deployed, but we are just going back into the BIOS and setting the HDD as the first boot device after the image has been pushed. I don’t know where to begin troubleshooting this part of the process. Legacy BIOS was so much easier…

Hey guys we just ran into this same exact problem. We found that if you disable DMA Protection in the BIOS it will PXE boot no problem. Just wanted to leave this out there for you to try.

Wow you guys are a great help. We were looking at folder permissions that whole time when it was the share permissions.

So we should be mounting to a sub directory in images/dev…

Export list for 172.31.16.155:
/images/dev *
/images     *

Not sure why it isn’t working.

1. We created a new directory within our /images folder on the fog server called userbackup.
2. We set permissions with chmod 777 on this folder.
3. Booting a host with a deploy debug task.
4. From the host we tried the following

mkdir /userbackup
mount -o nolock,proto=tcp,rw "1.2.3.4:/images/userbackup" /userbackup
touch /userbackup/test.txt
"This is a read-only file system"

Are we missing something in our mount statement?

@Sebastian-Roth We are actually trying that right now, however we are struggling to mount it with write access. It keeps giving us “Read-only file system” when we try something like touch /imagesinit/userbackup/text.txt.

@george1421 - I hate to impose binaries into the inits if no one else has a use for them. I’m just trying to figure out a way to do this without adding additional mechanics to our current process.