Topics created by DBCountMan

@sebastian-roth 1.5.9. What is also strange about how FOG behaves across subnets is the USB boot method. I’ve explained in another post about how booting from USB on the same subnet and/or same switch stack on my floor will not prompt me to enter the tftp server but booting from a completely different vlan or subnet physically outside of our own network will prompt for it. See this line in the ipxescript:

:setserv echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

I tried changing it to and this time it configures net0 then does nothing and the PC returned to it’s own (Dell) boot menu:

:setserv set next-server 10.x.x.x && goto netboot || goto serserv

I know this is off OP but it seems related to different subnet behavior in FOG.

@brakcounty said in Can a FOG Server setup as a Storage Node serve tftp files?:

I could always do a mysqldump export and import from the primary fog server to the secondary right?

Sure thing!

I read everything written here and thought about this: If earlier such manipulations were possible, is there a chance that Windows still did not provide for something. Is it possible to hack the system and change the memory size for updating? How is this even possible? I used to contact raid data recovery to recover the data I lost during the system update process and thought that even if they can retear the data, is it impossible to change the amount of memory used by this data?

@george1421 The USB ipxe boot method works perfectly, from a USB drive. The idea is to somehow make that ipxe process boot BEFORE Windows on the hard drive itself instead of the usb drive, and have a countdown to boot from first hardrive. This way I can set a deploy or capture task remotely and it would work. As for specifying the IP address, I already did. Ipxe sees the FOG server on the same vlan, but on a different vlan ipxe asks for the FOG server address.

@brakcounty I don’t have access to my production fog server at the moment, but I’m wondering if the history table keeps track of “deploy image” imaging…

This bit probably won’t help you retrospectively, but in my environment we don’t register the target computers with FOG, we use the “Deploy image” route. We do use MDT to build our golden image though. In MDT we have a task sequence that creates a registry key with the build date the golden image is created because we typically rebuild our golden image once a quarter. With a PS query we can query AD and the target computers to find out the unique build date of all of the deployed images. In a way we could back into the number you are seeking.

So the question for you is… is there something unique that would identify the target computer as being deployed by FOG? Some unique software or registry setting that would say this image was built by our golden image deployment environment?

From a FOG perspective, once you deploy an image via the “Deploy image” iPXE menu FOG forgets the target computer ever existed. The question in my mind is of the history table keeps any lingering memories of the target computer’s mac address or such.

@brakcounty That is defined in the web ui. That is the default user account you login as the admin. If you create another user account on your fog server you can use that for the iPXE menu instead of fog

@junkhacker I built an ipxe image using the fog’s kernels and files and made them into a vISO then mounted it to my vm. Boot from it, then normally it would load ipxe and eventually the fog menu. since I updated vbox it stopped working. yeah I’ll have to play with it.

Got it. Script works. Thanks!

Wait nevermind I figured it out. I enabled the “Hide Menu” option under Fog Configuration>iPXE General Configuration>Menu Hide/No Menu settings. Pressing ESC after entering the FOG tftp server IP shows the login menu. Perfect!

@brakcounty said in Imaging from large drive to small drive:

I am assuming that this would have to be done for each image.

Correct.

@george1421 I thought I did but I was wrong. I started reading these instructions down at the bottom under “Older Instructions” https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media#USB_Boot_UEFI_client_into_FOG_menu_.28harder_way.29

But the files and folders don’t match up with what I got. Do I still need to copy the contents of /tftpboot/ to the root of the USB? Where do I start?

@sebastian-roth
I figured such. The usb method on my offline imaging switch is redundant since pxe works fine on that. Just would have been nice to be able to image remotely booting via USB, kind of like Acronis+mapping to an SMB share that stores the images. If only my network team would enable tftp/pxe on their dhcp servers. We have it only on our hq subnet but it is being used by SCCM, and SCCM takes a very, very long time to image a PC. We only use it to get a base Windows 10 image and work on it from there, then capture/upload our custom dept images to the FOG server.

@tom-elliott
Ok thought so thanks.

Success! Dropped the files into /var/www and used set web-path to ${fog-ip}. In case anyone else has this issue this is my iPXE menu item parameters:
set tftp-path tftp://${fog-ip}/os
set web-path http://${fog-ip}
set pe-path ${web-path}/pm11_winpe
kernel ${tftp-path}/wimboot gui
imgfetch --name BCD ${pe-path}/BCD BCD
imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi
imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr
imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim
boot || goto MENU

@brakcounty Please read through this topic: https://forums.fogproject.org/topic/9624/control-access-plugin

Understand this is not like full access control as FOG wasn’t implemented like that and a plugin cannot simply fix this. But it might still suite your needs.

Note: This plugin code does not get much attention because the original developer does not seem to find the time right now. So if you find an issue we might not find the time to help and fix this.

@brakcounty said in Quick question about the tftp/ftp credentials:

The web ui login username is still fog and a password I set.

That is correct. Those are two different things. The web UI user has nothing to do with the fogproject service account (Linux).

@brakcounty While I can imagine an upgrade to break things in rare cases I would not think this would happen for a service like ISC-DHCP which has been around for so many years. But hey, you never know. Everything is possible.

@brakcounty Over all the details about GRUB I lost sight on what this topic is all about… The USB method uses GRUB as boot loader because it can be installed into MBR on the USB to be used to boot legacy machines. As I said before, the alternative USB boot method is not part of the official FOG stuff and has not had enough attention to be fully integrated yet. Not because it’s impossible to do but because we have way to many things on the list.

Now that you use UEFI only in your setup you could skip GRUB altogether and directly boot using iPXE from the hard drive’s UEFI boot partition and should be able to use FOG exactly the way you would if it does PXE boot. For that you just grab one of the iPXE .efi binaries from your FOG server (e.g. /tftpboot/ipxe.efi) and but that on your disk’s EFI boot partition as \BOOT\EFI\BOOTX64.EFI (case doesn’t matter here as Windows will ignor it). When booting the iPXE binary will run its embedded script to get an IP from DHCP and chainload to the FOG boot menu.

@brakcounty To get some more information, can you please schedule a debug deploy task (same as you would do a normal deploy task but just before you hit the last button in the web UI there is a check box for debug). Boot up the client as usual and let it boot up. Then you need to hit ENTER twice to get to the shell. Now type fog and ENTER again to start and step through all the process till you hit the error. It will throw you back to the shell. Now type:

sgdisk -gl /images/Win10Standard_GPT_EFI/d1.mbr /dev/sda

It surely will fail. Take a picture of the screen and post that here.

you da man!