@george1421

Do you have any other advice on this? Haven’t had much chance to play around with it lately but hoping to revisit it soon

@mstabrin Yeah, sounds like we found a good working solution for you. Great to hear that it did the trick.

Edit: I did rename the topic so we and others might find it more easily when looking for WOL.

@nofroyo I would not attempt to install FOG directly on your QNAP device. The fog installer assumes it has full control of your device and may make changes that could potentially break the web ui of your QNAP. The other issue you have to consider is that the libraries needed install FOG may not be available because your QNAP doesn’t run a standard linux OS.

Running inside a vm would be a better choice is you MUST run everything on a single device. Performance may no be so great since most NAS devices use low end CPUs because NAS activities don’t require much CPU. If you are only doing image deployment without any FOG Clients in the mix it may be OK to use it on your NAS as a VM. I don’t know if anyone has done this before so you can be the first.

FOG doesn’t really need a lot of CPU, in a way it functions much like a NAS in that the FOG server’s job is moving data between storage and the network adapter. The target computer does all of the real heavy lifting during imaging, I’ve run FOG on a Pi3 and Pi4 without issue. You have to just be mind full that you are dealing with a small but efficient computer.

@jcyrus_rti You are welcome!

Sorry if my answer sounded harsh. Didn’t mean to.

Thank you everyone. I tried again and I was able to successfully register that computer. I did re-try adding the 32bit and 64bit Kernels via the web gui and when I run the above commands on the server I get a return showing the 5.10.12 kernel.

root@fogsrvr:~# file /var/www/html/fog/service/ipxe/bzImage*
/var/www/html/fog/service/ipxe/bzImage: Linux kernel x86 boot ex ecutable bzImage, version 5.10.12 (buildkite-agent@Tollana)…

root@fogsrvr:~# file /var/www/fog/service/ipxe/bzImage*
/var/www/fog/service/ipxe/bzImage: Linux kernel x86 boot executable bzImage, version 5.10.12 (buildkite-agent@Tollana) …

So again thank you for your help.

Yeah, switching to a different iPXE binary can help in some cases too.

Though I want to bring up what I have posted two weeks ago as well: https://forums.fogproject.org/post/141320 (compiling the latest version of iPXE)

@EZY4 You can try using a different iPXE binary like snponly.efi at first. This might work with the A3510. Though on the other hand you can’t be sure if this will work for all your other devices.

Not sure if you can setup a particular DHCP policy based on the MAC address just for those machines to use snponly.efi…

Other than that I suggest you build the iPXE binaries from the latest official code base and see if those work on the A3510. Assuming you have the FOG stuff in /root/fogproject try this:

sudo -i cd /root/fogproject/utils/FOGiPXE/ ./buildipxe.sh cp ../../packages/tftp/ipxe.efi /tftpboot/

Pay attention to the long output when running ./buildipxe.sh as it might fail for whatever reason. If you feel it ends with an error, post the last 20 lines of the output here and we will have a look.

Make sure ipxe.efi is set in your DHCP again, boot up a machine and pay attention to where the preemble tells you the version number iPXE (g…). That should be different to g4bd0 (default on 1.5.9 installs).

So much for me. I didn’t see that the computer was in raid mode and not in AHCI.
The subject is irrelevant.
Sorry for the inconvenience

Solved topic

@rankinc We might have a hint for you which @RobertD posted just an hour ago: https://forums.fogproject.org/post/141591

@george1421
this is the wrong configuration: option 66 was checked.
a big thank you for your patience and the time spent with me

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

@alexnoel2 said in Capturing from a LUKS encrypted drive.:

primary drive is encrypted with LUKS

Am I screwed?

Only on days of the week with the name ending with a y

It has been successfully solved before: https://forums.fogproject.org/topic/13845/error-decrypting-luks-partition-prior-to-capture-imaging

You have the same issue as a windows computer protected with bitlocker. Since FOS Linux can’t read the disk, it clones it as RAW (block by block).

@quazz said in Can't capture an Image on Fog (newbie):

@juntacadaveres Well, it’s pretty clear, boot in recovery mode and fsck -fy it.

The cause of this problem was that my client was a “clone” of another virtual machine… I have detected that using fog with clones of other virtual machines can cause troubles. Thank you, anyway.
By the way, I have used virtualbox.

Hello @sebastian-roth ,

So far I did not encounter any problems imaging and deploying resizable BTRFS images

However, I “only” tested simple examples, i.e., one SSD with EFI, BTRFS, SWAP partitioning.

But no problems with this setup.
However, more complex examples will follow soon and I will come back to you in case I encounter some problems.

@sebastian-roth Thanks!
That worked for me. I would also note that this is Windows 10 1607 Enterprise LTSB.
that could be why the partition is not partition 1?

@kek said in FOG-Client suddenly stopped working:

but they use all a old fixed version of mono, because they are Lubuntu 18.04 LTS OS and the Ubuntu repo has no mono included

That is 5.18.0.240+dfsg-3 as you posted earlier??

@george1421 said in FOG image drive failed. What now?:

@cammykool This image error is related to the php code. Apache off load php (the language the web ui is written in) to php-fpm (dedicated php execution engine). The error you see is apache saying that php-fpm did not answer it was done with the task in time so apache timed out.

There may be some clues to what is at fault in /var/log/php-fpm/error.log tail that and see if it tells you what its not liking. If you set the permissions of 777 on /images nothing should stop it from moving files.

i had my coworker crack away at it. He got them all to delete and we are in good shape! Everything seems to be working and happy!

Hello

Did you find the solution, I have the same problem with 3 VM on proxmox :

1 debian fog server, 1 working windows 10 machine (That I have imaged) 1 test machine for deployment (I have the same problem after deployment)

Thanks for any help

@fogman4 The problem is that neither iPXE or FOS Linux are signed. That is where the problem comes in.

I can PXE boot a signed kernel using GRUB. with the shimx64.efi and grubx64.efi signed. Then grub loading the kernel. But that won’t help with doing anything with FOG.

@cicero said in Can't image:

I don’t want to be a pest but would appreciate if I can reach out to you you have great instructions

You are not. The forum is here to ask questions and people try to help. I would just ask you to not repeat asking more and more questions in the same topic! There is no restriction to open new ones for each question you have and it’s a lot easier for everyone to keep track.