@george1421
If it helps :

# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample # This file was created by FOG #Definition of PXE-specific options # Code 1: Multicast IP Address of bootfile # Code 2: UDP Port that client should monitor for MTFTP Responses # Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests # Code 4: Number of seconds a client must listen for activity before trying # to start a new MTFTP transfer # Code 5: Number of seconds a client must listen before trying to restart # a MTFTP transfer option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; use-host-decl-names on; ddns-update-style interim; ignore client-updates; # Specify subnet of ether device you do NOT want service. # For systems with two or more ethernet devices. # subnet 136.165.0.0 netmask 255.255.0.0 {} subnet 10.1.1.0 netmask 255.255.255.0{ option subnet-mask 255.255.255.0; range dynamic-bootp 10.1.1.10 10.1.1.254; default-lease-time 21600; max-lease-time 43200; #option routers 0.0.0.0 #option domain-name-servers 0.0.0.0 next-server 10.1.1.2; } class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000"; filename "ipxe.kpxe"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002"; filename "i386-efi/snponly.efi"; } class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006"; filename "i386-efi/snponly.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007"; filename "snponly.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008"; filename "snponly.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009"; filename "snponly.efi"; } class "SURFACE-PRO-4" { match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016"; filename "snponly.efi"; } class "Apple-Intel-Netboot" { match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386"; option dhcp-parameter-request-list 1,3,17,43,60; if (option dhcp-message-type = 8) { option vendor-class-identifier "AAPLBSDPC"; if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) { # BSDP List option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:08:69:50:58:45:2d:46:4f:47; filename "snponly.efi"; } } }

@sebastian-roth I didn’t take that second screenshot (in the second post) until after the first one had finished. And I got it while FOG was still imaging partition 3, so you are correct, it hadn’t renamed but that was only because I wanted to get a quick image of the root:root ownership.

Partition 4 is only 1GB so it should not have hung at all.

I wasn’t around to watch the second capture finish, so I’ll have to do it again later this week.

@george1421 Thanks for the help! I updated the kernel, had to do it on the ubuntu server instead of the web ui but it worked and it found the device and installed the image!

@benc If its only one image, it probably easier to recreate the metadata by hand in the new fog server. As long as you remember the path part of the image definition is case sensitive you probably can make an educated guess at the rest of the settings You will see the image size being zero bytes after you manually create the image definition but that is OK since that value is only created on an upload and is only used for display purposes.

@sebastian-roth Thank all of you. The issue has been solved. I did a new installation of the whole system. Before I did an Export of all available PCs to CSV and also the same with images, after the installation I imported everything again and now I have a better performance with a new system on a new hardware.

Thanks for your help

@amjfrankenstein Thanks for your effort on updating the installer for ARCH. Since your last post there were discussions about completely removing support for ARCH I am afraid. Please read through the following posts and issue reports on github:
https://github.com/FOGProject/fogproject/issues/447
https://forums.fogproject.org/topic/15936/os-support-the-numbers-are-in
https://forums.fogproject.org/topic/15591/arch-manjaro-install-database-and-web-fails

@george1421
Here are my files, I’ve upload all the content of my postinitscripts folder:
fog.postinit.txt
fog.patch.customhostname.txt
fog.man.reg.fix.txt
fog.customhostname.txt
fog.auto.reg.txt

@george1421 said in Use serial number as hostname in Fog:

I can see other wanting this feature too. I know I personally missed it since the FOG v0.30 days.

Without you, impossible to implement this feature. Thanks a lot

@obzen said in Partition is too big for the for the disk.:

I thought I followed your instructions correctly by checking the debug option before scheduling the task and iterating through the tasks with ENTER key Is there something I am missing as to how to get the capture of it correctly?

The pictures posted don’t show capture (from the source VM) but actually the deploy (to the target device). Nevermind.

FWIW the system in question is a Dell Wyse 5070 with nvme. It appears that this is so far the problem child, as i have successfully imaged 3 other systems with both spinning disks, ssds and nvme.

Well that’s an interesting detail! So it’s not a general issue but only caused on this particular machine. Looking at the pictures again I noticed it tries to deploy to /dev/mmcblk0. Sounds like the Dell Wyse 5070 has different drives and you need to specify the correct drive in the Host settings.

But first let’s find out what drives it has. So schedule another debug deploy (yes, deploy this time!) task for the Dell_Wyse and boot it up to the shell. Run lsblk to see a list of drives and partitions. Probably you’ll see /dev/nvme0n1 in the list. Put exactly this into the Host setting field Host Primary Disk (FOG web UI -> hosts -> Dell_Wyse). Now in the command shell on your Dell type reboot and let it jump right into the existing deploy (debug) task again. This time start the deploy (command fog) and see if it errors out again.

@Chris-Whiteley I finally had some time to work on the module and created a Start-FogSnapin function that can deploy a single snapin task.

See also https://fogapi.readthedocs.io/en/latest/commands/Start-FogSnapin/

@adriand said in Anything get stuck on bzimage with random %:

I was already using the snponly.efi files and switched to ipxe.efi and it’s now working.

FWIW, with modern UEFI computers snp or snponly should work because these boot loaders use the snp network driver built into the uefi firmware. On older model uefi computer the snp driver was a bit flaky so the preference would be to use ipxe.efi on those models because ipxe.efi has all of the common network drivers. Sometimes is a balancing act to find the best middle ground for the boot loaders. I’m glad you have it worked out.

@francis-r The ipxe.efi/undionly.kpxe manages the FOG boot menu. Once you make a selection then bzImage and init.xz are loaded then its “the kernel” that is in charge. So if you have issues selecting things or entering passwords into the boot menu then its iPXE that needs to be refactored. I know I’ve recompiled ipxe in the past with an alternate keyboard. So its possible. FOG has the programs already installed to recompile ipxe all you need to do is just update the keyboard config file to use something other than US english.

Here are the instructions for recompiling iPXE using FOG: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe you will just need to find and update the config file

@ash said in Cannot find disk on system.:

hard disk can not support pxe boot?

The technical answer is they are not connected. PXE booting uses network adapter. If I understand you correctly the old hard drive is not seen by fos linux but new hard drive is? Is it using same technology? old hard drive == sata and new hard drive == sata? Or nvme and nvme? its very strange taht swapping hard drive with same type and now its found.

@wiraport said in boot windows ISO directly:

Ive already used the method in the past to boot this files.

I think its impossible to do. Maybe an older microsoft OS but 2019 is to big.

But my goal is to help you, help yourself.

sanboot http://${fog-ip}/${fog-webroot}/fog/ISO/17763.737.190906-2324.rs5_release_svc_refresh_SERVER_EVAL_x64FRE_de-de_1.iso

I have not used SANBOOT before but I would think the URL you have defined should be an iqn path, not URL. I don’t know what the right answer is but I’m pretty sure that is not it. But I will also say I have not used sanboot for this purpose before.

Secondly this just looks wrong:

http://${fog-ip}/${fog-webroot}

I think ${fog-webroot} already includes ${fog-ip}

A quick check on this would be to call your fog server with this URL http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

That will give you the text behind the FOG iPXE menu. At the very top of that script within the first few lines ${fog-webroot} is defined. By looking at the code you should be able to tell how its assigned. Also the /fog in the path is redundant because that should be already included in the ${fog-webroot} path.

Also for the url as you have it created, you need to make sure your iso file is located in /var/www/html/fog/ISO directory.

The other limitations I said before still apply. I’m only helping you fix what is wrong with your parameter block.

And finally in this tutorial you will see how to properly setup the memdisk parameter block. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/6

initrd nfs://${fog-ip}:/images/os/mswindows/7Pro-x64/WinPE_amd64.iso chain memdisk iso raw boot || goto MENU

Again this might not be the only way to use memdisk, but I know this method works for bios based computers. I have not tried to use sanboot for this method of booting.

@leviathan Well the easy part, is FOG doesn’t support 22.04 yet. I would stick with ubuntu 20.04 for now. Being on the branch version is the right place to be

You also need to make sure you setup things in the right order.
FOG 1.5.9.115, then update the FOS Linux kernel to 5.15.x series, then recompile ipxe.

Your problem here is when iPXE fails to transfer all of the FOS Linux image (bzImage and init.xz) the problem is either you have an old version of iPXE or you nave network communication issues.

I will try and do it today. I’m getting ready to leave for vacation over the weekend in a couple hours, so it may be on Monday.

@sebastian-roth Thanks!!!

@abulhol Thanks for looking into the error and fixing the issue via the github PR. Merge is done.

@george1421 Thanks for the info.