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

@george1421 said in iPXE iso vs iPXE FOG:

Something isn’t working as we know it should.

I’m going to try and find a second PC with the same motherboard to test with but currently, they are all in service.

@tom-elliott said in Dev branch 1.5.9.79 Installing package: php-gettext.............................Failed! has to use -X switch to get it to work.:

in my testing language translation worked properly using the common provided version

Then it’s all fine. Good that we don’t need that extra package anymore!

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

Yep. The only thing I can figure is that somehow either the DHCP Relay or Arp Proxy in Pfsense is doing something weird, or the DHCP server is not processing my second range definition in its entirety (which is weird because booting into an OS proper, the exchange happens normally and gets the right settings).

Although in the mean time I have had to move along in my research so I moved the DHCP/ Bind DNS to PFsense and have configured it to have the correct options. EFI boot from fog server is working in this new configuration. I am leaving the existing configuration in place on the fog server though to return to this issue (which I think has value to try and solve).

@tom-elliott
@Sebastian-Roth

Thank you all. It is solved now in 1.5.9.78 with HTTPS on.

/var/log/apache2/other_vhosts_access.log

80 "POST /fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 302 599 443 "GET //fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 200 9111 443 "POST /fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 200 9111

/opt/fog/log/fogscheduler.log for Power Management Task

[04-29-21 6:16:25 am] * 1 task found. [04-29-21 6:16:25 am] * 0 scheduled task(s) to run. [04-29-21 6:16:25 am] * 1 power management task(s) to run. [04-29-21 6:16:25 am] * Power Management Task run time: Thu, 29 Apr 2021 06:16:00 +0000 [04-29-21 6:16:25 am] * This is a cron style task that should run at: 1619676960. [04-29-21 6:16:25 am] * Found a wake on lan task that should run. [04-29-21 6:16:25 am] | Task sent to fcaa-https

/opt/fog/log/fogscheduler.log for Scheduled Task:

[04-29-21 6:22:26 am] * 1 task found. [04-29-21 6:22:26 am] * 1 scheduled task(s) to run. [04-29-21 6:22:26 am] * 0 power management task(s) to run. [04-29-21 6:22:26 am] * Scheduled Task run time: Thu, 29 Apr 2021 06:22:00 +0000 [04-29-21 6:22:26 am] * This is a cron style task that should run at: 1619677320 [04-29-21 6:22:26 am] * Found a scheduled task that should run. [04-29-21 6:22:26 am] - Is a host based task. [04-29-21 6:22:26 am] - Unicaset task found! [04-29-21 6:22:26 am] - Host fcaa-https [04-29-21 6:22:26 am] - Task started for host fcaa-https!

Thank you again! Now our school can wake-up on Schedule

Peter

@wayne-workman said in FOG Project call for engagement:

For the exact OSs graph, only the top 20 are shown. I can change it to show more, but the graph bars will start getting really thin.

Ah, good to know. I think the top 20 will do.

@krishna Using a random screenshot and not explain it costed you two days by pointing to the wrong direction. The clearer your information is the more we are able to help you.

OK, so this is a normal single master FOG node setup and we can rule out routing because FOG server and PXE booting clients are all in the same subnet?

So you have the firewall disabled in the FOG server?

Where clients ever able to PXE boot to the menu? If yes, when did it work last and what changed since then?

About the access.log - I just figured that Ubuntu moved to a different name at some point. Please run tail -f /var/log/apache2/*.log while you PXE boot one client to see if it shows up in the log.

@sebastian-roth try this https://drive.google.com/file/d/1I_LFCwT0INMzg8vHbbi60KSqvYHtNDKN/view?usp=sharing

@aloniada Interesting. I have not tried it myself as I don’t use live OS booting. Just trying to help with what I find on the web. I would imagine the parameter can go pretty much anywhere in the imgargs line.

When you moved it to different positions, did you always get the exact same error message. I can’t think of why iPXE would grab that out of the imgargs line…

@wayne-workman Yes thank you, video answer alot.

@sebastian-roth Ahh, I didn’t see that either. Okay, so in DHCP I changed the router to 192.168.22.1 and range starting IP to .20

In fogsettings, I changed both routeraddress and plain router from 192.168.22.11 to 22.1

The test client gets online just fine now.

Thank you again, Sebastian!

@gothikserpent Well I’m glad you have a workaround but really the issue is what your dhcp server is telling your client computer on the networking side. As I said in chat I don’t know how a computer placed on that subnet can communicate with any other subnet.

In the case of dnsmasq and isc-dhcp server running on fog. They are configured to dynamically switch the boot file name based on the pxe booting computer’s mode. If the pxe booting computer is in bios mode both dnsmasq and isc-dhcp will send undionly.kpxe boot file, if the pxe booting computer is in uefi, both will send ipxe.efi. In the case of these two services they are able to adapt to the format of the pxe booting computer.

@rotoi Are you still running fog 1.3.3? More specifically you updated the kernel to something more modern, but have you touched the init.xz file? FOG 1.3.3 doesn’t (shouldn’t fully) support NVMe drives. The NVMe protocol wasn’t created until much later than FOG 1.3.3. Its akin to trying to install Windows 95 on an 11th gen laptop. It would kind of work, but not really well.

@fred06 You need to use an imaging Task. You selected “Debug” task, which was not what @george1421 was requesting.

Host -> Tasks -> Deploy -> Check the box for Schedule as Debug

@sebastian-roth The kernel update works now and image capture is successful.

I’ll start a new topic on the networking issue.

Thanks Sebastian!

@jbandy said in SSL Issue srvpublic.crt:

... "GET /fog/management/other/ssl/srvpublic.crt HTTP/1.1" 302 631 "-"

What we see in all those access log line is status code 302. So really, each and every request is not being answered directly but redirected.

Maybe this is something special Ubuntu is doing to push SSL/HTTPS forward? I am not sure. To try and see where this is coming from we need to start digging through the apache configs. First post the contents of the file /etc/apache2/sites-available/001-fog.conf here in the forums.

How do you change the url it’s using to communicate?

Edit C:\Program Files (x86)\FOG\settings.json on the client machine. Then restart the service called “FOGService” or the computer.

@sebastian-roth
Thank you for the appreciation!

Also maybe I just overlooked something, maybe edited wrong host, as I had multiple tabs and didn’t keep track of it. Otherwise I don’t see any other reason for it not working on the first try.

@tom-elliott unicast fonctionne bien mais multicast non cela ne fonctionne pas en multicast j’ai toujours la même erreur comme tout à l’heure

@adamhyla89 said in 11th Gen Intel Kernel:

it states cannot open ` /var/www/fog/service/bzImage’ (no such file or directory)

Better copy & paste the commands to not miss anything. So again: file /var/www/html/fog/service/ipxe/bzImage* /var/www/fog/service/ipxe/bzImage*

The install on the VM is only command line, no GUI for Ubuntu.

There is no GUI (for Ubuntu) needed as you can access the FOG web UI from another computer. I guess you have used it already because how would you manage FOG or even get past the schema update when you don’t access the FOG web UI.

@rodluz you can try this, https://forums.fogproject.org/topic/6463/expose-fog-host-and-image-properties-to-post-install-scripts?_=1620751811503 and make a review of host, image and hostinventory items…