Niether 0.10.9 nor 0.11.5 of the refind binaries made a difference (same exact error). Fog works, and the booting network UEFI and into Windows is 100% fine on the Lenovo m93p.

Turns out about 30% of our public machines are without a CSM module. Because of that, and because BIOS boot works, I have decided to fall back to BIOS boot deployment for my org’s public computers. The way my fog installation is now will still allow me to grow with the Lenovo’s without having to fight with it.

Thanks for looking into this with me, I have appreciated the help.

~ P.V.

@george1421
Would scheduling shutdown of the snapin to execute happen on fog or the host?

I liked the auto logoff feature because it let the user continue to use the host until the login was idle for x minutes. Windoes 10 changed machine idle sensitivity, and for us it has become difficult to properly give x minutes before being booted.

I’ll investigate that, thank you.
~ P.V.

This isn’t a bug, just an observation.

I was unable to get the shutdown feature of the fog client working, and I was able to pinpoint that to our unique environment. Do you recall that in Windows Vista , Microsoft had a feature called “SteadyState” and never continued it into newer versions of Windows. My org uses Faronics Deepfreeze (Google “SteadyState alternatives”) that “rolls back” a whole hard drive after a restart - WIndows, dates, logs, last file use, etc.

Anyway, the feature I had hoped to use was the scheduled shutdown command. Yes, the shutdown would work from the server, but only once - right after resetting the encryption data. I believe the cause of that problem remains deepfreeze.

I had actually wanted to request a feature addition: Add to auto log out the option to restart, that is when I realised without solving the above issue there is little point for the request.

Thanks again for a great piece of software! I will continue to use this FOGProject for some time.

~ P.V.

Niether 0.10.9 nor 0.11.5 of the refind binaries made a difference (same exact error). Fog works, and the booting network UEFI and into Windows is 100% fine on the Lenovo m93p.

Turns out about 30% of our public machines are without a CSM module. Because of that, and because BIOS boot works, I have decided to fall back to BIOS boot deployment for my org’s public computers. The way my fog installation is now will still allow me to grow with the Lenovo’s without having to fight with it.

Thanks for looking into this with me, I have appreciated the help.

~ P.V.

@Sebastian-Roth
Sure! I’ll grab a few and test them against my vm, and then against hardware next week. I recall that someone used refind version 10.9. It was the one that worked with older HP Machines, and missed where the internet location for the files were. Thank you for for helping me!

I actually have a pre-“csm” llano apu mainboard (same processor, bios 1005). I was lucky enough to have a backup first (BIOS drive) that I had to restore and used 1.5.8 to do it. I have many boards of this model type that are firmware 1105, only that I have yet to check and verify the presence of a csm).

I also have other similar year Asus (counting 10 ~ year 2012 firmware E35M1-M PRO boards & 6 F2A85-M PRO with 2014 firmware) hardware I could test against, and as long as I make a backup first I could easily restore it with the BIOS booting process.

Are you interested in those results? My Org (a public library) is closed due to covid and currently I am working from home. But I’d have zero trouble setting something up next week for testing. I could even get back to the Lenovo m93p and give comment on that as well.

@george1421

The dir listing you asked for

drwxr-xr-x 2 fogproject www-data     4096 May 28 20:24 .
drwxr-xr-x 3 www-data   www-data     4096 May 27 20:59 ..
-rw-r--r-- 1 fogproject www-data     1966 May 27 20:59 advanced.php
-rw-r--r-- 1 fogproject www-data    21280 May 27 20:59 bg.png
-rw-r--r-- 1 fogproject www-data    16272 May 27 20:59 bgdark.png
-rw-r--r-- 1 fogproject www-data     1139 May 27 20:59 boot.php
-rw-r--r-- 1 fogproject www-data  8438432 May 27 20:59 bzImage
-rw-r--r-- 1 fogproject www-data  7836480 May 27 20:59 bzImage32
-rw-r--r-- 1 fogproject www-data   234697 May 27 20:59 grub.exe
-rw-r--r-- 1 fogproject www-data      592 May 27 20:59 index.php
-rw-r--r-- 1 fogproject www-data 20889900 May 27 20:59 init.xz
-rw-r--r-- 1 fogproject www-data 20317908 May 27 20:59 init_32.xz
-rw-r--r-- 1 fogproject www-data    25340 May 27 20:59 memdisk
-rw-r--r-- 1 fogproject www-data  1839104 May 27 20:59 memtest.bin
-rw-r--r-- 1 fogproject www-data    29875 May 28 20:24 refind.conf
-rw-r--r-- 1 fogproject www-data   262592 May 28 18:51 refind.efi
-rw-r--r-- 1 fogproject www-data   202624 May 27 20:59 refind_aa64.efi
-rw-r--r-- 1 fogproject www-data   201600 May 27 20:59 refind_ia32.efi
-rw-r--r-- 1 fogproject www-data   208776 May 27 20:59 refind_x64.efi
-rw-r--r-- 1 fogproject www-data    29719 May 28 18:35 rfind.conf.orig
-rw-r--r-- 1 fogproject www-data   262592 May 28 18:51 rfind.efi.orig
-rw-r--r-- 1 fogproject www-data   208776 May 27 20:59 rfind_x64.efi.orig
administrator@hvfog-2020:/var/www/fog/service/ipxe$

Yeah, I swapped refind.efi & refind_x64.efi just to see if there was a difference. Unfortunately, the problem remained the same. I also played with deep uefi scanning for older mainboard firmware, and is currently enabled in refind.conf.

@george1421

Again, setting DHCP to refind_x64.efi works booting from network right into windows.

It is when loading iPXE first, seeing the menu, counts down to load the hard drive is when I see this error.

It seems to me that the iPXE.efi handoff to refind_x64.efi is what causes the problem in the hardware cited.

The staging VM loads the menu, counts down, and boots Windows without issue.

@george1421
Yeah, https: I admit, when I upgraded to 1.5.9rc2 I forgot to add the command line switches for https, and re-ran the installer to include encryption (ipxe need the certs recreated)
I did create just the one entry, and I kept the original refind.conf to swap around when needed. It took me a bit because copying the files need the group and owner to go with it, or “file not found” appears during the iPXE load process.

Server hardware or machine hardware?
I am looking to use UEFI because we’ll be replacing our AMD APUs with circa 2015 Lenovo’s soon. While I successfully tested a lenovo m93p on 1.5.8 and deployed an image in early March, I think I removed the network boot ability of that workstation because it loaded right up when I did my check; I did not see the iPXE menu.