@keith75140 Well if you can get linux console access, the fog password should be captured in /opt/fog/.fogsettings
But if you have admin access on this server, just create a new linux user like fogadm and give that sudoer rights. Then start using that account for system administration and leave the fog user alone.
[mod note] Marking as solve. I setup a teamviewer session with the OP and helped him fix this and a few other issues. At this point the OP is imaging as designed now.
I remoted in with teamviewer and helped the OP get things working correctly. We had to ensure that the dhcp server only bound to the imaging lan NIC adapter and not both. We also found a nuance with ubuntu where it only wanted one interface up at a time by default. Once we had both interfaces up, fog installed correctly and like the OP needed it. Solving this case.
I have to ask the question why no dhcp on this network? Is there a technical or regulation requirement for no dhcp? FOG needs dhcp server to send out the needed boot information. That is a requirement.
I found my notes on this. This one is for BIOS mode. I used the nfs protocol instead of tftp. Both will work. You just have to place the files in a different location based on the protocol.
kernel nfs://${fog-ip}:/images/os/mswindows/wimboot gui
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/bootmgr.exe bootmgr.exe
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/bcd bcd
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/boot.sdi boot.sdi
initrd -n boot.wim nfs://${fog-ip}:/images/os/mswindows/10-1607/sources/BOOT.wim boot.wim
imgstat
boot
I have not tested this, but a quick file change and this should work for UEFI. Also for uefi booting, you must send the ipxe.efi iPXE boot kernel. You can not boot into uefi mode from undionly.kpxe boot kernel.
kernel nfs://${fog-ip}:/images/os/mswindows/wimboot gui
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/bootx64.efi bootx64.efi
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/bcd bcd
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/boot.sdi boot.sdi
initrd -n boot.wim nfs://${fog-ip}:/images/os/mswindows/10-1607/sources/BOOT.wim boot.wim
imgstat
boot
Just be aware these instructions will NOT boot "Windows 10 ISO via UEFI" so you can install WIN10 as in the OP's question. The only way I found to boot the win10 ISO so you can install Win10 is by using the link I posted previously.
@fox134 Well lets hope you don’t have an ipxe.exe in there…
The client gets its booting information from (the) dhcp responsible for assigning an ip address to the target computer. So if you want the target computer to use a different boot file then you might update dhcp options 67.
Now with that said, from your OP you say that FOG is giving out the IP addresses on a dedicated imaging network. So if you want to change the boot file, you will need to edit the dhcp config file on your FOG server.
To see what you config file looks like, you can review this example: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1
You will see for arch 7 and 9 it calls out ipxe.efi. You can replace that with maybe snponly.efi or any of the other efi files. Then you must restart your dns server. On ubuntu you would issue the command sudo systemctl restart isc-dhcp-server to restart the service.
@dahrell Sorry I’ve been looking at other issues.
I was able to get a generic USB ethernet adapter to work once FOS was booted. But that won’t help you since it will have another mac address. Using a down level kernel might work, you can assign that kernel to that specific bit of hardware via the host configuration page. I was just looking but I can’t seem to find old FOS kernels in the 4.10 era. I know they exist, I just can’t locate them at the moment. Plus there is no guaranty that they will include the driver for this bit-o-dock. The right solution is for the linux kernel developers to fix the code to support these things.
For you to use a third party network adapter to pxe boot, you may find no joy there either. The UEFI firmware has to have the drive built in to support pxe booting. I don’t suspect that M$ will include any drivers in the uefi firmware other than their own hardware.
Lastly you could always usb boot into FOS using the FOS USB stick. Its not an ideal situation, but it would bypass pxe booting by booting FOS off the usb stick (as I did in my testing). Then all you need to have is a FOS supported usb ethernet adapter to image.
@wayne-workman said in Microsoft Surface Pro 4 (using dock) has Issues with DHCP for Imaging Task:
That’d be the responsible thing to do on Microsoft’s part.
[snark on] But why, there is no profit in that. Fixing linux does not push their crappy windows 10 agenda at all. [snark off]
FWIW: You can get older FOG Project created kernels from this URL: https://fogproject.org/kernels/
slighly off point post, but recording for reference.
MBR 512n
Disk /dev/sda: 17.2 GB, 17179869184 bytes, 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00006e8c
GPT 512n
Disk /dev/sda: 36003.6 GB, 36003637100544 bytes, 70319603712 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 3DAC1844-EDDA-43CD-9334-E0F3515F0AC7
MBR 512e
Disk /dev/sda: 1098.4 GB, 1098437885952 bytes, 2145386496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00000000
4Kn
Disk /dev/sda: 999.0 GB, 998997229568 bytes, 243895808 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 4CD4D7DC-B85C-47B5-A8D0-BCFA2345A58D
I’m sure there is a better way…
fdisk -l /dev/sda|grep -e "Sector size"|awk '{print $4, $7}'
There is
fdisk -l /dev/sda|awk '/Sector size/{print $4, $7}'
OK lets start out with some basics.
@tesparza Well that is why, she no work. Its asking you a question on the hidden screen
@tesparza A suggestion I can give you is this. Use 7-zip to extract that direct-x .exe file. It is a self expanding archive file. Then you will need to change how you deploy it, you will need to deploy it as a fog snap-in pack and not a .exe
@awellis I have some sad news for you. I setup a clean 1.5.0 fog environment and multicasting works “as described on the tin”.
Is your fog server in a virutal environment?
With a quick teamviewer session this issue has been resolved. The issue was just the sequence of install and ensuring eth0 was up before installing FOG.
There is currently a bug in 1.5.0 that is causing this. The problem has been (will be) fixed in 1.5.1. Is this a show stopper for you? FOG 1.5.1 is expected to be released in the next week or so.
@bigsease30 Yeah what you have is wrong. It should look like this:
@gnavarrete I’m only here to provide options. Do what is the best for you and your company. I agree with moving off 14.04 since its past EOL anyway.
@gnavarrete I think you have posted the best path forward. Create a second FOG server, copy the images over and export and import the image meta data and hosts. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
as for the dnsmasq, the link I provided before has a working ltsp.conf file. I’ll repost it here. Just don’t forget to change the <fog_server_ip> to the fog server real IP address.
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi
dhcp-range=<fog_server_ip>,proxy
@towndrunk well I can see two paths for you.
You need to configure the FOS engine to look for raid cards. Remember that FOS is “intended” to be a workstation imaging tool (one to many). Its not “intended” to be a backup tool. You can go this route, with a bit of debugging get it to work. FOS (the customized linux os that caputres and deploys images) does understand and support raid cards as long as if the hardware isn’t so new where there are not linux kernel drivers for the hardware, and you enable the raid function.
Use a third party product like Veeam Backup Agent (free) to make backups of systems. This would create a DR backup as well as on going incremental backups. Its a really nice tool.
If you want to go down the FOG route then you have a little debugging to do. I can guide you down that path to see if its even possible.