nope, was not aware!

perfect i guess. Although to keep a std you could move it down and call it protect…
job done and easier to identity tick box.

Yep you are correct.

not sure how I missed it. I searched for my hostname in the reg with no matches.
It was 64 and i didn’t look under the Wow6432Node folder.

Oh well, thanks

Please note that it’s been said that the DisplayManager has been built back into the client.

https://forums.fogproject.org/topic/8383/svn-5949-screenres-manager/8?loggedin

@Joe-Schmitt said in Host Screen Resolution:

@networkguy 0.10.0+ removed DisplayManager from the client. As @Sebastian-Roth pointed at, its a very “Windows only” thing and never received much use compared to how much effort went into maintaining it. @Tom-Elliott, perhaps we can add some kind of “warning” next to display manager stating it isn’t present in 0.10.0+ ?

Obviously if there is enough support for it, we can add back display manager, but we won’t be porting it to OSX or Linux.

i’ve got to version 1.5.0.16

using: git checkout working-1.5.1

that right?

are they all in a clean shutdown state before starting?
do they already have an OS?

I got this fixed.
i think they fixed it without me but i had an open ticket and was talking iPXE and swapping files and all sorts.

Anyway new firmware 1.21 now working.

I have just found this issue, Anyone have a fix?

are they all in a clean shutdown state before starting?
do they already have an OS?

Just came across the same issue, did you fix it?

@george1421
I have downloaded various versions on ipxe.efi and i get a change of play but nothing that moves on.
I did try snp.efi but as you suggested, this didn’t work.
I have also opened a ticket with Lenovo but don’t expect that to bear any fruit.

what do i try next?

We have a fleet of ThinkPads Yoga 13 (G1-G4)
These have been working perfectly (imaging) but now after a recent BIOS update devices are getting to a black screen with “iPXE initialising Devices…”

1st i just want to check i should be playing with option 067 to fix this (at least test)
currently using ipxe.efi

and advice on getting these devices imaging again would be amazing.
(i’m going to start looking for a new version of the above)

BIOS version = R23ET35W (1.20)
ControllerV = R27HT29W (1.17)
Model = 21FJ001YUK

have you looked into:
Response Error multiple hosts returned for list of mac addresses

in the host search box you can put the mac address to lookup the host (or many hosts)

There should be only one per MAC access (careful when imaging from docks or usb NICS) Fog does protect against this action but you never know.

you’re right, you can’t use the RAID. this is already off.
I can image the machines, The point is that is doesn’t flow. it needs another reboot so just a little harder to leave them to it. (got quite a few to do )

the 2nd is indeed windows but i was wondering if the FOG agent reboot isn’t a full reboot of some kind (what’s the command used by agent) shutdown -r ??
it’s last task would have been joining the domain.

It feels like a FastBoot thing the more i think about it, just didn’t get time to test. If FOG inventory is “fastbooting” it might be skipping where it then boot back into the PXE to continue the deployment

And windows might apply the auto login details from the unattend.xml but not get a full reboot, more like waking from a hibernate (caused by they way FOG agent reboots the system after joining the domain)

Managed to get these machines deploying with the latest kernel (Thank you).
(UEFI, Windows 11)

The strange thing about these machines are two fold.

1. When I 1st register the device in in fog from the boot menu, at the end when asked it you want to FOG now, you say YES but it seems to pop out of the process and continue to load the local HDD with now a broken OS due to changes in the RAID settings. If we reboot and then boot from PXE, it starts and deploys the image

2. We have a process after the deployment that auto signs in a domain user to finish some tasks and then we shutdown. On these machines the auto login doesn’t work until we reboot it one more time. This is not a new process, been doing it for 7+ Years and other new machines work as normal.

One note was when we reboot it then installs a few GPO applications, this is normal but normally after it’s logged in once bla bla. When we reboot to start this process we don’t see the BIOS and it’s quick.

This leads me to think that FastBoot in the BIOS might be the issue. I’m putting this up in case anyone else has any ideas. I can’t test until Monday, i will update but any ideas welcome.

Thanks, thanks, thanks.

depending on the task if i recall correctly there is a folder in the TFTP or near by that has a file created with the MAC address as the tile name for that job.

(Just saying )

Correct me if I’m wrong please.