@jonathanho92 said in no configuration method succeed dhcp fail please help:

this happen only when multicast we have no problem with unicast

I don’t think this is the case. The bootup for both multicast and unicast are exactly the same at this early stage.

I guess you are using different devices when multicasting?! Use the exact same physical for unicast and I’d be very sure you see the same error.

@dudenamedben What hardware are you booting on?

For your INFO
snponly.efi is to undionly.kpxe
as
ipxe.efi is to ipxe.kpxe

In the only boot loaders, snp and undi use the built in nic firmware drivers to talk to the nic card. Where ipxe. has all of the network card drivers built into the ipxe boot loader. In the early days of uefi the snp drivers were terrible, that is where the FOG developers recommend to use ipxe.efi. The problem is with very new hardware, the iPXE developers might not have included the drivers in the ipxe build just yet, where the snp nic driver will work.

@sebastian-roth Yes, you’re absolutely right! The original had a secondary MAC matching the clone. I deleted it and expect the clone to show up shortly. Thanks for your patience! 🙂

@sebastian-roth yes I believe that was the case. I don’t remember the record count as I already purged data older than 30 days. I set up a SQL event that runs daily.

DELETE from userTracking WHERE utDate < now() - interval 30 DAY;

I can now run the reports

@tom-elliott

The FOG Server was installed not special like 10 others in our enviroment…

Works now after running:
sudo chmod 750 /opt/fog/snapins/ssl/.srvprivate.key

Thanks a lot!

@sebastian-roth So I’m not sure what has changed, as I’ve had to focus on other things, but now it works. I didn’t follow the most recent direction, but I’m booting various boxes via pxe successfully. No idea. …

@george1421 So, I am an idiot.

What was happening here is I deployed the old BIOS image, which blew away the GPT designation, and then when I created and captured the new image, the Windows installer never re-applied the GPT. I manually went in with diskpart, wiped the drive, applied GPT, rebuilt the image, captured, deployed, and voila! It boots now.

Jokes on me for trusting the Windows installer I guess. 😛

Thanks for your input George! It actually helped a lot.

@peet Looking at the error message, I’m going to guess you have a SOHO router or network switch setup as your dhcp server. Many of those devices point to themselves as the pxe boot server and not the fog server. As Sebastian asked, what device is your dhcp server? There are a few ways to work in this type of environment, we just need to know how your network is setup.

I figured it out… I must have screwed up some permissions on the web_root so I removed /var/www/html/fog/ and re-installed fog and all is well…

Thanks!

@FuriousGamer065 There might be a PHP-FPM error log as well.

@sebastian-roth yes, the command only calls the product key. I activate it via the “change key” option in the settings. Enters the called key.

as i wrote “After preparing the image from devices (Lenovo E15 Gen 2, Vostro 3681, Optiplex 3080) and uploading the images to other devices, the license key is copied from the first device from which I recorded the image”.

@sebastian-roth I’m just going to reinstall ubuntu

@george1421 I think I found the root of the issue. I installed it originally with https, but it looks like the cert was not validated. I resintalled without https and it seems to work just fine now. Is there a way to validate the cert with https? The wiki mentions system time can cause an issue, but that was all correct, so my guess is something else may have broke the cert.

@sebastian-roth
Thank you for the guidance. I dismounted the iSCSI share, but I couldn’t run a fsck on it, as it said the “Super block was not readable.” So I decided to just reboot.
I made sure all the NFS services came back on startup, because those occassionally don’t start or crash.

Ran mount, noticed that the /images share mounted differently than before. \dev\SDI intead of \dev\SDJ Screen shot below. However, it is now RW not RO. Just tested as well with capturing an image and it worked.

Thanks!

@lenain Ubuntu 14.04 LTS is no longer in support since April 2019.

Ok I also found the answer to my search question:
https://forums.fogproject.org/topic/10036/api/2
The search syntax is slightly different to the news article.

So here would be an example command for completion:

curl -H 'fog-api-token: TOKEN' -H 'fog-user-token: TOKEN' -X GET http://FOG-PXE-SRV.mpi-dortmund.mpg.de/fog/host | jq '.hosts[] | select(.name == "HOSTNAME") | .name'

Thanks again for letting me do my inner monologue on your platform! 🙂

Best,
Markus

@jj-fullmer said in FOG 1.5.4 API host module settings:

@JJ-Fullmer said in FOG 1.5.4 API host module settings:

@Jamaal Glad you got it figured out, sorry I didn’t see this early as adding it to the host splat that you convert to json adds it to the json data that @Tom-Elliott references here. I will make a note about adding something with setting modules to my module in the future

Look, I made a note https://github.com/darksidemilk/FogApi/issues/1

@Jamaal I also finally did something with this. I hope to at some point develop this a lot further and have dynamic parameters for snapins and groups when adding a host in powershell. But for now there is at least a basic new-foghost function that will create a host with a given name and mac list and enable the modules that you have set as default in your fog server.

This is published in version 2103.2.12
https://www.powershellgallery.com/packages/FogApi/2103.2.12
https://github.com/darksidemilk/FogApi/releases/tag/2103.2.12

@sebastian-roth

I changed the d1.partitions and d1.minimum.partitions and it works.

@rogerpenn said in Can't deploy images due to random incorrect IP address:

I’m wondering where that storage node IP information is stored though, because I grepped my entire file system for that IP figuring it was in some file somewhere and found nothing.

It’s in the database, not in a config file.

@Claw22000 So probably the Cisco SG 200-8 has some kind of upper network layer “security” features that prevent NFS over TCP. Strange but good to know.