@AUTH-IT-Center Hi thanks for the reply.
Yes I’ve read that link, my problem is that I’ve done the password migrations “backwards” - ie I’ve copied the passwords from the database to .fogsettings instead of the other way around as specified on that link.
I think I might have done something stupid…
I have a new server on which I have already installed FOG.
Today I wanted to transfer the database from my old server to the new server and update the version of FOG.
I thought I was being clever… before transferring the database and running the FOG installer, I edited /opt/fog/.fogsettings on my new server and inserted the passwords, copied from the management interface on the old server:
username='fogproject'
password='password from old server'
snmysqluser='fogmaster'
snmysqlpass='password from old server'
Then having run the installer it occurred to me, does the installer update all the necessary services to use these passwords, if FOG is already installed? Or have I broken something - and if so, how do I fix it?
@AUTH-IT-Center Thank you. I didn’t find that article but it has what I need.
Apologies if this has been covered before, I found a few similar topics but this is a ‘what if’ question about something I don’t quite understand.
I’m migrating to a new server which will eventually have the same IP and hostname as my current server, though it does not have those yet - it has a temporary hostname.
I’ve run through the FOG installer and when it asked for a hostname I gave it the hostname of my current server because it said it would use it for certificates. I’m not using HTTPS on my server.
My aim is that I can switch the old server off, change the IP and hostname of the new one to be the same as the old one, and all the FOG clients will be happy and not need any reconfiguring. Is this going to work?
@george1421 This is all very encouraging! I tried kernel debug level 7 but there was no additional information.
@Tom-Elliott
Yes I think that’s correct if I’m correct that getting into FOS would mean the kernel started to boot. What you see there is what happens immediately after I make a selection from the FOG menu. It downloads the kernel and the init. The next thing that appears onscreen is what you see there, and then after a couple of seconds it reboots.
Need a storage for global arm Kernel and Init
Need to associate architecture to appropriate kernel/init.
Yeah. I don’t know how you detect that you need the ARM kernels at that point but atm it thinks it needs to send the x86 kernels. (I’m not actually using any x86 PCs so I haven’t actually broken anything by changing that config 
)
Later we need to get kernel/init actually loading/booting?
Not completely sure I’ve understood that, but with the config hack I’ve done it is definitely downloading the arm_Image and the ARM init, I can see that the filenames are correct just before it gets to the point where it stops.
I tried the most recent 3 builds (including the experimental one) of the ARM kernels and inits but it made no difference.
@george1421
I have mode some progress: Using FOG 1.5.10.1593 on Ubuntu Server 24.04
I was able to find the DHCP boot parameters using wireshark, and I’ve added this to my dhcpd.conf:
class "UEFI-ARM64" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00011";
filename "arm64-efi/snponly.efi";
}
This makes the iPXE part work and I can boot to the FOG menu. I then tried to run a Full Host Registration. The first problem was that FOG is sending it the x86 bzImage and init, so I (temporarily) made this change to the FOG config, having downloaded the ARM kernel and the ARM init using the FOG GUI.
This gets me a little further but now the process stops here for a few seconds, then the laptop reboots. Same hapens if I try the Compatability Checker.
So currently the summary is that FOG is sending the x86 bzImage and init, and when I hack it to send the ARM ones, those don’t work.
I don’t remember which version of the ARM inits and kernels I tried, so I’ll try a few more and if I get any further I’ll post back.
@george1421 Great. Let me know what you need and how to get it and I’ll do that as soon as I’m able to.
@george1421 Thanks for the info. I’m going to be purchasing one of these Lenovos so I will try and assist if I can.
A search didn’t reveal anything about this which makes me suspect I’m missing something obvious but…
Does FOG support Windows on ARM? Eg Lenovo now make a range of Thinkpads with a Qualcomm Snapdragon CPU and many other manufacturers are bringing similar models out.
I noticed there are ARM kernels on the kernel download page. Is all I need to do to install those and everything will just work?
@Tom-Elliott Apologies, I don’t know what went wrong there but somehow I got an incomplete version of your changes. git is a confusing beast to me :). I’ve now checked again that I’m running dev-branch and I can confirm that all the warnings have gone.
Thanks again.
@Tom-Elliott The change on dev-branch has fixed one of the warnings but not both. I’m still getting
[proxy_fcgi:error] [pid 5049] [client 127.0.0.1:59748] AH01071: Got error '
PHP message:
PHP Warning: Undefined property: stdClass::$name in /var/www/fog/lib/router/route.class.php on line 629'
Swapping lines 629 and 630 fixed that warning for me. Thanks.
@Tom-Elliott said in API Error with PHP 8.1:
You decide to change the hostname to abc… Which thing should we do, delete the existing abc host, delete the existing host? Instead we error out.
Oh that’s a very good point, I had not considered that.
The issue I’m seeing is essentially that it fails when I’m trying to set ‘name’ to the value it already has, so if I have to send ‘name’ I have to change it, which isn’t useful. (eg I try to edit host id 1 and include a name of abc, that fails).
Happy to try pulling dev branch but it’ll take a few days, I’m running the release so I need to switch a few things around.
When I set name to “”, it did set the hostname to “”. I immediately corrected it in the database so I’m afraid I can’t provide the output you’re looking for.
If I set a ‘name’ field to an empty string it deletes the hostname for the host.
If I set a ‘name’ field to the hostname of the host, the check it’s trying to do matches and gives me an ‘Already created’ error.
So it looks like there is no parameter I can set ‘name’ to that doesn’t cause me a problem. I might be misunderstanding the code, but having a check which fails if the host already exists on an endpoint called ‘edit’ seems backwards?
Just upgraded to Ubuntu 22.04 with PHP 8.1 (from 20.04 with PHP 7.4), also updated FOG from 1.5.9 to 1.5.10 - so I’m not sure quite where this error lies, it might be my code.
I have an application that uses the FOG API. I haven’t changed anything in this and it has always worked before the upgrade.
Specifically, when I use the ‘edit’ path to assign an image to a host:
PUT request
URL host/[host ID]/edit
JSON ["imageID": int]
I get the following in the PHP error log:
[proxy_fcgi:error] [pid 1166] [client 127.0.0.1:42750] AH01071: Got error '
PHP message:
PHP Warning: Undefined property: stdClass::$name in /var/www/fog/lib/router/route.class.php on line 623
PHP message:
PHP Warning: Undefined property: stdClass::$name in /var/www/fog/lib/router/route.class.php on line 626'
Looking quickly at the code it seems to be something to do with not having a ‘name’ parameter in the JSON, but Ive never needed that before and I’ve no idea what I would set it to. The request does seem to work, but clearly something is wrong somewhere.
@greg-plamondon Yes, I never enable that nonsense
@george1421 Thank you, that’s a very helpful explanation. I think I will start experimenting with using snp.efi as my default and create specific rules for machines where it does not work.
@sebastian-roth Thanks. In the end I found that even realtek.efi didn’t entirely work. The PC is connected to a KVM and using realtek.efi it will only boot if the active KVM port is the one the PC is connected to. Otherwise it gets stuck in and endless loop of retrieving the file, crashing, and rebooting. ‘snp.efi’ does seem to work but I’d really like to know what the difference is. Do you know if it’s documented anywhere or shall I have to rely on the mailing list? I haven’t found anything on the iPXE website.
This is what I came up with in dhcpd.conf
class "Realtek-64Bit-UEFI" {
match if binary-to-ascii(16,8,":",substring(hardware, 1, 3)) = "1c:69:7a";
filename "snp.efi";
}
I found another possible solution though I’ve no idea why it works. I switched every instance of ‘ipxe.efi’ in my dhcpd.conf to ‘realtek.efi’. This was a complete guess, but now the USB-C ports work.
How can I work our what to use as the string match so that I can ensure that only this Lenovo PC uses realtek.efi?
Also can anybody explain why this made a difference? The main USB controller is an AMD controller. There is a Realtek USB SD Card Reader and a Realtek NIC but I was never having any issues with those.