@Bhav We don’t have any information.

What I’m seeing, however, is that the machine you’re attempting to load is using UEFI booting, but you’re presenting MBR/Legacy PXE systems.

@Laurent The information is stored encrypted in the db + the transfer of information is encrypted between the client and the machine.

The only time the password is clear to any user is when you initially enter it in the field.

@fabritrento That’s not how this works. Just saying lol. 6.1.22 works fast for your situation, but that doesn’t mean there’s truly something wrong with the kernel for everybody. So when the next stable release comes out, you should remember to switch back to 6.1.22 and we’ll work to keep trying to update the kernels and hope that you’ll test them to see if it works for your situation so you don’t have to revert it to 6.1.22.

@NoIPName you didn’t provide a csv. You took a screenshot of an excel of your csv.

That said I suspect there’s an issue on the line of or immediately following the host you aren’t able to import.

I also seem to be seeing the same host name multiple times in your image so that might explain things as well.

Please provide your actual csv.

@Tom-Elliott I just did a test had had to run through this:
https://medium.com/yavar/send-mail-using-postfix-server-bbb08331d39d

Though I also had to setup an application specific password as opposed to the native password as my gmail account is MFA protected. So I also had to set an application specific password.

In the tutorial it has you building a sasl_passwd file instead of using your native gmail password you would enter your 16 character app specific password.

Similarly, while the instructions are being setup specific to debian/ubuntu based system, the basic premis is the same for any linux OS I guess.

Use your package manager, install postfix.
Set up your main.cf as instructed making necessary changes for your environment.
Create your sasl_passwd file
Map the sasl_passwd file to the db that postfix can use
restart postfix and test sending an email.

You should (before restarting postfix) check your file and fix up any issues in your main.cf file. (generally going to just be duplicate entries here or there.

https://myaccount.google.com/apppasswords
enter your gmail password and mfa as requried
create your application and setup name.
store the password it generates. It will likely show up as abcd abcd abcd abcd however the password will be without the spaces. and if your password is actually abcdabcdabcdabcd I won’t know it lol.

I certainly hope it’s not that rudimentary.

@rogalskij I suspect what you’re seeing is that the new FOG Server is unable to ping these devices, though I’m unsure as to why. Normally new devices will get set to “ping reachable” initially.

Edited to add:

However, pinging is not done by loading the page anymore as imagine having to wait for the page to load to figure out if it can or cannot ping the host? We, now, have a NRT methodology which is to say it’s not even remotely close to real time for ping status. Instead it’s ping reachable when the host is initially added, but then after 5 minutes an “actual” ping occurs (or whatever time you’ve defined for the service) and updates this value for the hosts. This allows the UI to run more efficiently and gives a general overview of what’s reachable. Though I’m sure this could use refinement, it’s better than nothing most of the time. However, if it cannot ping the host (and I suspect these are listed by hostname and the fog server likely cannot ping the dns hostnames nicely) it will update to whatever value, in your case that it cannot reach it.

What I think might work to address this would be to add the search domain of your network to your fog server so that it can ping your hostnames directly and that should fix your ping reachability.

For example. if the FQDN of the host is hostname.example.com and you ahve the host as hostname on the fog server you’d need your fog server to be able default it’s search domain for dns pinging to be example.com and then as long as DNS is working properly when it tries to ping hostname it will try against dns to the example.com domain structure.

@rogalskij Can you validate that your fog server CAN send email?

The database options are pretty simple:
(Warning the screenshot is from Working-1.6 version)

You obviously would want the FOG_EMAIL_ACTION (probably called Email Action in 1.5 versions) to be checked, and whatever the Email address you want.

That stated, all this is good and well, but you likely aren’t able to send emails from the server.

https://www.digitalocean.com/community/tutorials/send-email-linux-command-line

This link is an example of how to do so. If the cli method of email sending emails works and the fog server still isn’t it may mean you need php-mail installed? Just my thoughts.

@robertkwild There’s only one “stable” one “major/master” and then the one we’re working toward.

Technically there’s also “nightly” so 4 main versions:

• master branch = 1.5.10 (Currently) - Baseline for stable and current updates of the master.

• stable branch = 1.5.10.1634 (Currently) - This is considered (if you will in linux terms) LTS (we’re wanting 1.6 to come out but in the mean time we still need to keep things up and running of the stuff most people are using.)

• dev-branch branch = 1.5.10.x >= 1634 (currently) - This is where we do updates for issues found/reported/ and hopeful fixes to go into the next release of stable. This is what I would call “nightly” but it’s not quite bleeding edge either as this is just holding fixes for hte 1.5.10 and later versions.

• working-1.6 branch = 1.6. This is what some might consider alpha/beta (all working branches will be intended in this manner at least) in that it is where it’s the fully latest bleeding where we hope and want to get to with fog.

@Eazis It looks, to me, there’s a firmware that we may need to add to the kernel for these nics, but I don’t know what version? I see

rtl8125a-3
rtl8125b-1
rtl8125b-2
rtl8125bp-2
rtl8125d-1
rtl8125d-2

I suppose we could attempt to add all of them, but we don’t know which one applies to your specific device.

@sideone No worries. That just let’s us know in your specific case at least, it’s not booting in UEFI mode at least for NIC devices, so thank you!

@RAThomas I’m concerned that it’s randomly entering debug. If it were all machines, all the time.

That said, when you create the image you can define the task type to also include debug mode.

can you walk us through the exact steps?

If it were all, you’d look at fog settings.

The UI probably shows it as just Kernel Args, or something similary:

The DB side would be:

select * from globalSettings where settingKey = 'FOG_KERNEL_ARGS'\G

Sorry for not having a clean direct answer right away, but working through it is all we can do right?

@RAThomas If you’re comfortable with mysql, I might suggest taking a look at the database:
You’ll have to get your fogmaster password from the /opt/fog/.fogsettings file. snmysqlpass

sudo mysql -u fogmaster fog -p

select hostID,hostName,hostKernelArgs where hostKernelArgs LIKE '%debug%';

This might not be the best way but since I don’t know where the debug will show up in the hostKernelArgs, this is the best method I can give right now.

Most likely, I believe, you’re going to see your hosts with these.

If that doesn’t yeild anything, are the hosts part of a group? in which case the group likely has the kernel arg also, so check with:

select groupID,groupName,groupKernelArgs where groupKernelArgs LIKE '%debug%';

I’m suspecting one if not both of these will yield you back the results to help you fix the affected items?

@RAThomas If the value is empty it shoudl think it’s false, and since it seemed to be random that’s where I got confused. But I’m glad this is working for you.

Thank you!

@dejv 1.5.10 is quite old, though is the master I suppose.

We have bene doing stable branch releases more autonomously with likely newer versions of the kernel.

With that said, however, this appears to be kernel related.

Of course first question just to ensure all is right:

UEFI Secure boot is temporarily disabled correct?

Please attempt to update your kernel to a newer version.

You can do this in the UI from FOG Configuration Page -> Kernel Updater

Find the latest version and try that, and work back if necessary for older versions. I suspect one of these will work better for your needs.

@sideone Please run an update, I just released what I believe should fix this problem.

The reason you’re seeing that in the browser is the url is expecting a mac address being sent in. #!im == “Invalid MAC”