@jeje3346 Technically speaking, anything is possible.
These postdownload scripts are customizable to your hearts content, so yes it’s possible, technically, but as far as getting support for your own scripts, we’ll try, but it’s still all best case.
The FOG Client will do so in a well standardized method but if you don’t want to use that, that’s perfectly fine as well.
We will still attempt to assist as required.
Thank you,
@dejv Please try using snponly.efi instead of ipxe.efi?
What version of fog are you using?
@ZipfelK The images you provide show us the dhcp configuration options but doesn’t really tell us anything or show us anything of what “doesn’t work” about your FOG UEFI PXE?
Is something freezing? Is it permissions? Is it not finding the next-server/bootfile to download?
What isn’t working?
What things have you tried? I see most of your configurations are trying to use ipxe.efi, what about trying UEFI with snp.efi or snponly.efi?
@Erika So if the older BIOS appears to work:
BI0S Version 1.07.05
KBC/EC Version 1.09.10
ME FW Version 18.0.5.2133
Then chances are something that was updated firmware wise is causing the problem rather than the kernel. Unsure what we could do to fix this, though if you’re okay with trying kernels still.
Can you try various kernel versions?
I see you may have tried 6.1.22, what about 6.1.89, whatabout older?
If there’s a version that the new bios version works with, that helps lead us to a point that there is something in the Kernel that isn’t working right. It won’t get us closer to fixing the issue entirely but should help us narrow where in the Kernel there is a problem so we can try to figure it out.
@aurfalien I’m sorry, I am generally working in working-1.6 and even there I was mistaken.
The file you’re looking for is likely /var/www/fog/lib/fog/host.class.php.
It follows similar rules though the line you’d want changed would be at 2199 I think.
Hopefully this helps?
@Erika Can you attempt to use kernel version 6.1.22? 6.1.89 is when we started seeing the pcr 9 value/issue. Some machines seem to just get hung up trying. The message you see isn’t an error in and of itself. Simply the kernel cannot load the next element in the chain. At least that’s my suspicion. I don’t know how to fix this or what’s even causing it direclty yet. Havent’ really had time to go through and figure it all out.
Translate via Google:
Pouvez-vous essayer d’utiliser la version 6.1.22 du noyau ? C’est à partir de la version 6.1.89 que nous avons commencé à voir la valeur/le problème pcr 9. Certaines machines semblent simplement se bloquer en essayant. Le message que vous voyez n’est pas une erreur en soi. Le noyau ne peut tout simplement pas charger l’élément suivant de la chaîne. Du moins, c’est ce que je soupçonne. Je ne sais pas encore comment résoudre ce problème ni même ce qui en est la cause directe. Je n’ai pas vraiment eu le temps de tout examiner et de tout comprendre.
@rogalskij You can install postfix (which will also include its own version of sendmail, so I would recommend removing sendmail first if you installed the native version, then install postfix, it should include postfix variant of sendmail as part of the main install and probably be much faster to install as well.
@Mightmar Ahh , so you’ve hit a problem we see occasionally.
SNP SNPonly files, are effectively using the onboard information to drive network connectivity in the PXE environment. ipxe.efi attempts to match the device to a specific driver (usually for better performance/speed/accuracy of information)
As you might imagine, if the driver isn’t matched or not fully fleshed out, the NIC may not operate or hand off accordingly.
I think you’re right that updating the information wouldn’t have necessarily been required, but also probably wouldn’t hurt anything either (or at least shouldn’t.)
@aurfalien I suspect that you have the hoststatus plugin enabled then? This isn’t a default feature of fog nor is it well flushed out.
The plugin is handling this and effectively always sets to windows when the ping status code is 0. If the ping status code was 111, it’s linux, but These aren’t arbitrary values. If you know it’s all Linux, then you could adjust the hook:
/var/www/fog/lib/plugins/hoststatus/hooks/addhoststatushost.hook.php at around line 96, change the values of “windows” to linux so it would read:
printf($strtoupdate, 'linux', 'linux', 'green', 'Linux');
That said, it’s only good for you as the next update would reset this to what we evaluate it to. There isn’t really a method of knowing for 100% certain its a windows or linux machine, so not really sure how best to approach this.
@yardk Okay, good news, bad news, so good news is the code loading the Arm architecture seems to be working correctly.
Bad news, we haven’t really had much time to troubleshoot against all potential arm devices and I believe this is a semi-known issue that we just haven’t been able to narrow down and/or fix at this point.
If you’re able, can you try loading a 6.1.22 arm kernel or maybe 6.1.89?
I suspect, and it’s just a sneaking suspicion, what you’re seeing is similar to the issue we’re seeing with hyper-v/proxmox and efi loading.
@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.
@yardk No, because we don’t know what’s wrong.
Are you randomly trying kernels and inits? If so is this machine actually an ARM device?
What version of FOG?
What version of Inits? What version of Kernels? What kernel Version?
(Versions are now being somewhat represented as dates of the build, and the kernel version is the actual version of the linux kernel, such as 6.6.22 or 4.1.3, or whatever. 20240305 might represent the version of the init/kernel build rather than the actual kernel version. Confusing I know but trust me it will make sense when you have to seperate things out. For example, it’s possible Kernel version 6.1.89 is in version of kernel 20240305 and 20240802, because we used the same kernel to be built between the 2. Generally not going to be the case I suppose but just wanted to make a note somewhere.)
Basically your very first post doesnt’ really tell us anything about what’s wrong, what you’re attempting, what hardware you’re using, or anything.
@wilsol you’re downgrading the kernel version, not FOG. These versions exist and while generally having the bleeding edge is fine, sometimes the bleeding edge is … well… problematic. Will there be a fix? Most likely, when we know exactly what’s causing and can produce a patch, notify the kernel development team what we find, or disable the offending piece once we know what it is and what (if any) it impacts by being disabled. Until then, using the slightly older version is the workaround/fix.
@gribbler the post download script will run for all deploy tasks. If there’s a specific post download script you’ve written you would have to provide those here so we could attempt to figure out why it worked for this but not that. I have no idea what your scripts look like or what they’re doing.
In your scripts you can do debugPause statements and you’d have to run your task in debug mode to see it on the fly.
@gribbler Only deploy based imaging tasks runs postdownload.
deploy with snapins
deploy without snapins
deploy debug
I think are the only three.
@JYost If your’e asking about the not found autoexec.ipxe that shouldn’t matter as it is just a means to use local files to autoexec ipxe items.
Effectively “autoexec.ipxe… Not found” is not an error message that is preventing booting in and of itself.
I suspect, possibly, that it is where your ipxe is failing to continue, but that seems more like when you compiled you forgot to include the embed script that (once autoexec.ipxe is not found) tells ipxe what to do.
@Mr_____T I don’t know if you’re installing, but the buildipxe.sh script should be able to run through now.
@Mr_____T I’m not sure why you’ve got head. I check stable, dev-branch, and working-1.6 and this file does not have the merge conflict associated to it.
Can you please attempt:
git reset --hard
git pull
If you’ve edited the files, its possible those changes will be lost. Not sure what would’ve changed so please make sure to get a backup of the state if you need to keep those changes.
Thanks