@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

@RocksAndRolls I’m guessing, possibly, somebody changed the ftp path for the image location from /images to /home/fogproject/ftp?

@DzOnizuka No you’d have to change your OS /etc/fstab to use the device names over the UUID’s.

Otherwise what you’re capturing is an FSTAB of the “golden” machine, then putting it on a different machine, who’s UUIDs are not the same thing.

@DzOnizuka I dont think it’s grub specifically but rather the fstab.

Debian, and Ubuntu, tend to set the /etc/fstab to use the drive’s UUID to indicate which drive to load the OS from. I’ll bet if your drive layouts are consistent at least (like for like) if your replace the uuid and point specifically at the device name (/dev/sda1, /dev/sdb2 etc…) things would work perfectly fine.

@danieln using using expansion variables wouldn’t work because the user doing the expansion of %userprofile% from a snap in is system.

Those types of snap ins work just fine when directed appropriately because there is no user interaction. I suspect the 3rd party tool simulates the interaction via elevated credentials but those interactions will not work from the system user. I know it’s a pain, but that is one limitation of windows and system user. System user has full reign on the OS. It should be able to do these things. However, security wise, it’s a black hole in that any application or service that would run as the system user after being installed by an elevated permission, would also have full reign. So to prevent complete destruction of the OS and experience Microsoft has made it impossible to have the system user directly interact with other users profiles. I see both sides of it. There simply isn’t a way around this currently that I’m aware of.

@danieln the act of “pinning” I believe requires user interaction. I also suspect, possibly, the office 365 is awaiting user interaction. Once the task starts, look at the task manager. My suspicion is you’ll see office installer is running. But it never completes which is why you don’t see it finishing the task on the server.