I’ve just tried an Insider build from the Dev channel, Secure Boot was not required - though is supported by this hardware (Intel NUC). MS are saying that the requirement is actually a TPM - they’re saying ‘Secure Boot Capable’ because that’s more consumer-friendly than talking about TPMs.

The image type in FOG can be set to Windows 10, and I was able to capture and deploy

@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.

@Tom-Elliott

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.