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.
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?
Are you saying that you get tot he windows welcome, create a user screen / login to Microsoft account screen?
I often record this with a phone then you can pick out the error in that micro flash of text.
I think most of the time picking a different X.pxe file resolves this for me.
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)