@Sebastian-Roth you put me on the track!

The bios was configured in legacy bios first, I switched to uefi first and it works!

Thank you!

@julio said in démarrer une machine via le réseau:

@george1421 désolé george pour le dérangement, j’ai trouvé le problème à ma solution tout seul ne prend pas en compte mes messages et mes images stp. merci bien

C’est bien aussi de donner la solution au problème. Cela peut servir à d’autres personnes. Merci.

@sebastian-roth That solved the issue for me. Thanks!

@kyl Could just be a PATH issue then. Try /bin/touch instead of touch on your next test.

@Generalcanada Not exactly sure but maybe this post might help you: https://forums.fogproject.org/post/143080

@OmegaXis Strange error. Have never seen this before.

@tom-elliott salut tom et ici ca veut dire quoi et comment je pourrais resoudre cela??? merci bien

@george1421 said in dnsmasq won't start automatically. [SOLVED]:

@fog_newb Well there are really two commands you need to use.

Enable the service to start every reboot systemctl enable dnsmasq To start the service now systemctl start dnsmasq

These are two distinct actions and one doesn’t depend on the other.

@george1421

Thanks. I have used both of those commands before trying to get it to autostart on boot. I haven’t used them since running sudo systemctl enable dnsmasq , which was the one that got dnsmasq starting on boot for me. Perhaps since I used those commands prior it is all good?

I went through my bash history and saw I almost used sudo systemctl enable dnsmasq I had the syntax messed up though. I used sudo systemctl dnsmasq enable

I am really starting to like Linux. I digress, I am mostly a casual so I doubt I will ever have it on my daily driver but I am thinking about trying it on a laptop. I don’t know though, sometimes, I just like to point and click. 🙂

@jcyrus_rti said in Unable to locate image store:

Did I do something out of sequence or something? Why would it create the directory with the mac address name instead of the unique name I listed in the directory?

When everything works as expected the capture goes to the MAC address named directory in /images/dev first. Then when the client sends the final ok to the FOG server it’s moved to /images and re-named. If that did not happen it’s likely the final step has failed. So I suggest you pay close attention to the last messages on the PC/VM’s screen when you capture next time.

Yes, that solved it. Thanks for the quick work, @Sebastian-Roth!
How do I mark a topic as Solved? Or is that a moderator-only task?

@gerrit-anderson said in Centos 7 UUID not updated during imaging - will not boot:

From what I can tell, FOG is handling the UUID’s correctly…

Would say so too from what we discovered so far. It’s interesting you can capture/deploy from/to VM<->VM and machine<->machine but not “across”.

For further debugging I suggest to dig into the dracut emergency shell/mode more. First run ls -al /dev/disk/by-uuid/ on the dracut command prompt and post a picture of that here. As well you might also follow the instrcutions printed, run journalctl and look through the log for hints on why it fails booting. Also take a look at the file /run/initramfs/rdsosreport.txt mentioned. Feel free to share the file here and I’ll take a look as well.

Edit:
Searching the web I found this: https://unix.stackexchange.com/questions/183859/initramfs-uuid-problems-after-cloning

Sounds like the initramfs might be generated differently on your VM and bare metal install. Both are missing a driver for the other one. If that turns out to be true you need to find out which one is missing and manually regenerate initramfs with dracut e.g. on your VM before capturing the image to be deployed to hardware.

@Sebastian-Roth It did containing

04/13/2021 11:58:30 Installer Settings successfully saved in /opt/fog-service/settings.json 04/13/2021 11:58:30 Middleware::Communication Download: http://fog-pxe-srv.XXX.de/fog/management/other/ca.cert.der

@mstabrin Good to hear the BTRFS resize code is working for you! Thanks again for your work on this.

For a long time FOG would not move partitions if they were recognized as “fixed” because moving e.g. a recovery partition in the old MBR days would render it useless because of static sector addressing in boot loaders and such. Now as we all move towards UEFI and GPT partition layouts we have updated this logic to handle “fixed” partitions as fixed in size but not fixed in position anymore. For more details read this topic: https://forums.fogproject.org/topic/15025/move-partitions-on-gpt-layouts-need-people-to-test

I did a test with Linux partition layout having SWAP at the end and it was able to shrink it down and deploy to a smaller size disk: https://forums.fogproject.org/post/141373

To make a long story short, download the latest inits from our webserver (64 bit, 32 bit) and you should have this feature included as well as your BTRFS resize.

@sebastian-roth It sure is! 😸
But I love how flexible FOG is with its postinit and postdownload scripts and the API functionality.
I can really create everything I need, really things as complex as this problem here, by simple using the FOS binaries as building blocks.

I have to say that FOG is indeed an amazing product!

Yes, it works.
Thanks a lot.
Adrien17

@kek Just a quick update as I got to work allowing the fog-client to use a simple local CA certificate file instead of the mono keystore stuff. Would you be interested to test?

@robertsaron You missunderstand FOG to be a backup tool. While it can be used to take a backup it’s definitely not what it was made for in the first place and other tools are a way better choice.

@rogerpenn Why would you want to install FOG 1.4.4? It’s years old and we don’t fix installer issues in older versions. Just use current 1.5.9 and it will install just fine.

@itachi_19 There is something going on here because both conditions can’t happen tcpdump sees nothing but dhcpd responds to a client request.

Are you running tcpdump as root or sudoing to it? If you don’t have elevated rights I can understand why tcpdump would not see (because tcpdump can’t connect to the raw socket).

Yes, both are VMs on a Virtualbox, and their network is set to NAT.

Well that would keep the witness computer from seeing this communication. With NAT enabled that still doesn’t explain where the tftp://10.0.2.4/Windows@2010.pxe “Windows 10.pxe” file name is coming from. As they say, the culprit has to be in the house (virtualbox).

@george1421 Yep, thanks, that’s exactly the approach I have in mind for my centralised systems. 👍