@joseheitor I can think of 2 possible conditions to cause this.

The reboot process leaves the hardware in a strange state where iPXE can’t get an IP address on a warm start. Your network switch and spanning tree (if standard spanning tree) is enabled would cause this. Explanation Default Spanning tree takes 27 seconds to start forwarding network data after a network wink (as if the computer is rebooting). A warm start boots faster than a cold start so by the time iPXE gives up STP has not started forwarding data yet. Where at cold start the computer tests memory and checks hardware that isn’t needed on a warm start. But again this is only a guess as to the reason.

One quick check for spanning tree is to put a dumb (cheap) un managed network switch between the building switch and pxe booting computer, see if that resolves the post imaging reboot. If it does then look into your network switch settings to enable fast-stp, port-fast, or RSTP (whatever your switch vendor calls it).

@george1421 Fantastic! Many thanks.

Thanks for the information.

depending on the task if i recall correctly there is a folder in the TFTP or near by that has a file created with the MAC address as the tile name for that job.

(Just saying 🙂 )

Correct me if I’m wrong please.

@jnelly17 said in Hard Drive not recognized after image is deployed:

HP Elite SFF 800 G9

Turn off the Raid option in storage section, your PC will boot up!

@george1421 I see the set fog-ip variable and set storage-ip variable. Could I set those two variables with IPs of different interfaces? So for example, the interface IP server ipxe will be the “set fog-ip” and the interface IP serving NFS will be the “set storage-ip” var. Would that work?

since you mentioned that you do not want to partition the volume, an alternative approach could involve creating a disk quota at the operating system level. Disk quotas are a feature provided by the operating system (in this case, the Hyper-V host) that allows you to set limits on the amount of disk space a specific user or group can consume.
Set up the network share on the Hyper-V host where you will store the FOG images. Ensure the share is accessible from the FOG VM. Inside the FOG VM, mount the network share to the /images directory, which is where FOG stores the images. You can do this using the mount command or by adding an entry in /etc/fstab for persistent mounting. Configure disk quotas on the Hyper-V host for the user or group associated with the FOG VM. Set the quota limit to the desired amount of disk space you want FOG to use for images.
Keep in mind that disk quotas are managed at the operating system level and are not specific to FOG. Therefore, this method will not provide real-time monitoring of disk usage within the FOG web interface. You will need to monitor the disk space usage separately on the Hyper-V host.

@Evelyn09 said:

Can I use Linux device file name, disk size, and disk serial number?

Yes to all three if you use FOG 1.5.10.

Make sure your Proxmox server is set up with a static IP address on the physical network interface. For the virtual network, ensure that it is set up correctly, and all VMs and LXC containers are attached to this network. Assign static IP addresses to all your servers and clients to avoid conflicts with DHCP. Reserve these IP addresses in your DHCP server configuration (pfSense) to prevent accidental IP allocation conflicts. Ensure that your LXC container (running Ubuntu Server) has the correct network configuration. Use a bridged network interface so that the container can get its IP address directly from the physical network. Double-check that the LXC container’s network settings are consistent with your Proxmox virtual network setup.

@zaboxmaster The history of the report should still show the fact that it was imaged, though the links to the “host” element are done based on the existing of the physical host in the database.

I believe this is known and could be relatively easily fixed by just planting the current device name along with the hostID.

The reason that this isn’t done, however, is that it’d still be relying on a database entry, and there are cases where people deploy an image to a device that isn’t registered. What name do you use for that particular case?

@Sebastian-Roth yeah i have FOG server and now work with it, capture and deploy my favorite OS and images, actually that i say we need boot sergei strelec over FOG in network boot with live type, in fact we used Hiren PE but we need use Sergei, these products are different, Hiren have just 1 wim file but sergei have 4 wim file!
if i use 1 of 4 or combine or merge together it will work and sergei will boot up but the programs not working, it look like the apps wont load, in result do you have any idea?

@alexamore90 Definitely look into using multicast if you want to image many in little time!!

On Linux, ‘mv’ is used to rename files. ‘fogsettings-firstInstall’ is not a folder, it is the new name of the file ‘.fogsettings’, in the FOG wiki they do it so you can keep a backup copy of what you had.

Hello george1421,

Got everything working with the USB client.

Thank you for your help.

Louis.

@george1421 said in Does LDAPS work during iPXE menu login?: mcdvoice

@brakcounty The code support switching to ldaps by adjusting the port number, I suspect that bit won’t work as advertised. I don’t think that element was ever tested. The reason why I say that is to make it work it needs an LDAP certificate installed.

Good one. Thanks for sharing a nice piece of info.

@Sebastian-Roth Unfortunately the USB external drive wasn’t see by FOG, I tried the serial number listed in Windows but it backed up an NVMe drive Please disregard

@lostitguy We you will need to make up your own fog ipxe menu to specifically call the wipe function.

I am not 100% sure I have the stanza right but it should look like this

Menu Item: fog.wipeit
Description: FOG builtin Disk Eraser Tool
Parameters:
kernel tftp://${fog-ip}/bzImage
initrd tftp://${fog-ip}/init.xz
imagargs bzImage initrd=init.xz root=/dev/ram0 rw ramdisk_size=256000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 mode=wipe wipemode=full
imgfetch init.xz
boot ||
goto MENU
Menu Show with: All Hosts

If you ALWAYS want to wipe before a deploy in one step that is also possible but you will need to “hack” the fog deploy script to include the shred command. That is a bit more complicated than creating a fog ipxe menu, but modifying the fog deploy script is not that difficult either. There are just more steps involved.

@buddyaderholt I don’t see how this is directly related. Please remove the link you posted or we will do so unless you can explain the context of how this fits into the picture.