@user419 How did you turn on https protocol in FOG? It almost appears that ipxe did not get recompiled with the same certificate that apache is using for the web server.

@george1421 thank you very much for your help, I’ll try to edit the refind file.

@jshancock1 Is this a new install of FOG? It almost sounds like is not being sent to the target computer causing the unable to boot messages. While they are different messages they are about the same topic.

From the fog server linux comsole prompt what is the output of this command? file /var/www/html/fog/service/ipxe/bzImage

@ggiesen said in FOG Client with CA-issued TLS certificate:

The SnapIn client appears to be trying to talk to the web server using HTTP and on the IP address rather than the FQDN. Any way to fix this?

Unfortunately this is a known issue discussed on github: https://github.com/FOGProject/fogproject/issues/371

I worked around this temporarily by adding the following to /etc/httpd/conf.d/fog.conf:
…

Well done! Overall you’ve made quick progress on making this work!

@george1421 thanks for the answer 😄

@lcis said in Trying to access /images on deploy-debug:

For curiosity, why couldn’t I mount $storage ?

While debugging your post install script, use debugPause to put a break point in your code. Put an echo statement in just before the debugPause to say “Stop me here”. So when you are debug executing your deployment, when you get to “Stop me here” press ctrl-C to exit the fog script. Now run the set command and confirm where $storage is pointing to.

Also side note, I always set $variable using ${variable} so the bash interpeter really knows what I want as a variable.

When you hit the ctrl-c that should be the exact state of the machine. The /images directory on the FOS target computer should already be mapped to the FOG server /images directory at this point (during the execution of the postinstallscript)

Hi,

Same problem as Scoude here with Fog 1.5.9 on Debian 10.
I “defraged” (it’s a ssd), desactivated Fastboot, hibernate off, chkdsk…
Nothing fixed the problem.

Any idea ?

Thanks

@londonfog I can most assuredly tell you that no one using FOG has done this before.

The challenge is getting both iPXE and the FOS Linux kernel to use the serial console port (even at that I don’t know if the SOL redirect will work correctly).

The first step is that you will need to rebuild iPXE using the built in tools in the fog server. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe I would run through this process the first time as is just to get a base line compile setup.

Then you will want to hack a config file to enable the serial console in iPXE as outlined here: https://ipxe.org/console

As an example here is the fog supplied console.h file https://github.com/FOGProject/fogproject/blob/171d63724131c396029992730660497d48410842/src/ipxe/src/config/console.h#L37 note that you will need to turn on the serial console in the console.h in the build path for iPXE. You will need to do it for both the bios and uefi config files.

You will probably want to add the following lines right under enabling the serial console.

#define COMCONSOLE COM2 #define COMSPEED 9600 #define COMDATA 8 #define COMPARITY 0 #define COMSTOP 1

You will need to make the changes correctly for your SOL configuration.

Then rebuild iPXE a second time. This time move the built files to the /tftpboot directory.

Now for bzImage (fos linux kernel), it looks like you just need to add this to the global kernel args settings console=ttyS2,9600

@ram There are so many questions because your post lacks details.

Is this a new FOG install? What did you configure in your main dhcp server for options 66 and 67? Is your pxe booting client a bios or uefi computer? If you select the boot manager on the target computer (typ F10 or F12) can you select pxe boot? If yes what error message do you get?

@baptistepds Well then we do find that sometimes there is no hope because of a hardware conflict between ipxe and the firmware. We do have one last method to boot bzImage directly fro a usb flash drive. You will lose multicasting and “Deploy image” functions because iPXE isn’t there, but you will still be able to unicast an image onto this computer.

Read through the tutorial completely so you understand the caveats and also look at the forum chat for some additional hints: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

@george1421
Hey I did a sysprep.
I had to to reboot one time and shutdown one more time. And it works.

Thanks

@rocksoft said in Can fogproject be used to deploy bios/uefi servers like a deployment server ?:

Can fogproject be used to deploy bios/uefi servers like a deployment server ?

The quick answer is yes.

FOG supports both bios and uefi based computers. You need to send a bios based boot loader (undionly.kpxe) to a bios target computer, and snp.efi or ipxe.efi to a uefi based computer.

So if you have your own dhcp server that supports dynamic boot loaders (like a linux dhcp server) you can configure those settings. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1 or if you have an external dhcp server on a router or L3 switch you can use dnsmasq to provide dynamic dhcp boot loader info https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

And finally if you have no dhcp server, when you install FOG you can tell FOG to install a preconfigured dhcp server to provide dynamic pxe boot info.

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