Topics created by brakcounty

@brakcounty Well done!!

Where I also see value in this is if someone wanted to hard drive boot into iPXE then from iPXE into the hard drive or FOG without using PXE booting. Instead of a usb drive, everything could happen off the efi partition on the local hard drive. It would not solve the secure boot part of it, but its an option.

Also lets say someone wanted to setup a preboot menu (such as for dual booting) using refind. Your idea could be tweaked slightly to boot into refind menu manager and then pick to boot windows, linux or something else from the refind menu. There are a number of options this method opens up. Again, well done!

@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.

@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!

@brakcounty said in Any updates on the non-resizable Windows recovery partition issue?:

So I should only download from github what I already have instead of all of the inits right?

You only need init.xz and init_32.xz! Download those two files from github, rename the original ones on your FOG server and put the new ones into place.

Also I don’t know why those two bzimage files are in the group “fogproject” instead of www-data.

That happens when you update the kernel through the web UI. It’s not an issue. Still works just fine.

@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.