@punch07 to view the /tftpboot use the command line terminal window. Now I do have to say that different distros have the directory in different locations like /var/lib/tftpboot.

Hi,
For my own, i:

mount the other storage into a FOG-STORAGE mountpoint, I make a IMAGES directory into it I rsync/copy recursively all /images content into /FOG-STOR/IMAGES i make a symlink /images -> /FOG-STOR/IMAGES
And i do also the same thing for SNAPINS

Finaly i add lines into /etc/exports to point to the storage (/FOG-STOR/IMAGES/)

I don’t lnow if it’s the best way but it runs very well.
Regards

@george1421 Thanks for the insight!

I’ve tried adding Dell’s WinPE driver package to the driver store but it doesn’t seem to have helped either. Whether it’s just the wrong drivers for the specific machine, i’m not sure yet.

I’ll give it another go once we get some more Dell stock in - but thank you for the help in the meantime 🙂

@Jim-Holcomb So unfortunately i’m not readily available for a remote assist due to work requirements and duties so I apologize.

@Jim-Holcomb said in [BUG] iPXE Boot Loop & Menu Failure After FOG 1.5.10.1660 Upgrade:

After upgrading to the latest FOG version, my PXE boot environment is broken. What used to work flawlessly is now a disaster. PXE clients either hang, enter a loop, or display autoexec.ipxe not found. Sometimes pressing ESC brings up a green DOS-style login prompt, then fails to chainload. Sometimes they hang on “Booting…” indefinitely.

So this “autoexec.ipxe not found” always shows. This is not an issue. It’s simply saying there’s no file called autoexec.ipxe on your /tftpboot folder. It’s NOT whatever was causing ipxe boot issues. I’m guessing this PXE boot environment was broken due to whatever was changed?

As to the selective hard drive. I’m not sure I understand what is wrong here. YOu watched it write ONLY to the /dev/nvme drive but somehow it wrote to both the sda and the nvme? Something doesn’t sound right there. Single Disk resizable and Multiple Partition Single disk shoudl only write to a single drive and be done. Do you have video of this process writing to both? I only ask because seeing this in action will help me understand where the code is flawed. To my knowledge, however, it seems more likely that at some point before you wrote to the NVME it had accidentally written to the SDA drive, then you try to figure out how to have it write to the NVME. Then, finally, it was able to write to the NVME, but now it LOOKS like it wrote to both because the SDA drive was never cleared out?

And yes, d1.mbr is absolutely correct. That’s how it initializes the disk.

@Jias94 Hey no worries, I’ve created that error a few times myself so I had a good idea where to look. I’m glad you have it sorted out and can get back to imaging.

@hariskar It looks like your root partition ‘/’ has 1.8T or 1800GB of space. The command I would have run is df -h to give you usage. but assuming that debian is less that 50GB you should have plenty of space to capture a modern computer with 50GB of data. Use single disk resizable to use zstd to compress that 50GB of data down even smaller.

What error message are you getting? A screen shot of the error might help set the context of the error.

@george1421 This worked! Thank you so much for your help!

@Eazis I created an experimental kernel that includes the drivers to fix this issue. Would you be willing to test it and let us know how it goes?

@pierre-baylet Bonjour, j’ai eu la meme erreur lors de la mise à jour en 1.5.10. J’ai aussi un storage node déporté sur un NAS Synology. J’avais une erreur après la capture, avec un “Update database failed”.
Il faut que tu refasses les permissions sur ton dossier images/dev sur ton FTP.

Pour mon syno j’ai fait la manip suivante :
depuis mon fog en ssh :
sudo mount -t nfs @IPNAS:/volume1/images /mnt
chown -R root:users /mnt/dev
chmod g+s /mnt/dev

@Clebboii Thank you for your comments. I’m following up on your responses below.

It looks like MAC Passthrough is only a thing on Latitude, Precision, and XPS laptops. We utilize Latitudes. We do disable Secure Boot when trying to go into PXE boot. We’re going to try to set up a USB with WinPE to disable bitlocker. What confuses me is that the XPS had bitlocker get triggered when secure boot was off but still made it through PXE. It makes me think Bitlocker isn’t the issue here. The Dell USB-C to Ethernet does not support our Dell Inspirons. We tried an Anker USB-C hub with Ethernet and a usb-Ethernet TP-Link adapter on the Inspirons which didn’t give us the option to PXE boot. 66 and 67 weren’t set up when it worked on the ThinkPads or XPS. We set it up on our Firewall not our Router. It also worked after enabling. Going to look into this once our ThinkPad returns from being issued out as a loaner laptop.