UEFI local disk chainloading error

[george1421]

@plegrand Ok, so we need to understand why refind is incorrectly selecting the recovery partition.

From a windows computer, can you give us a screen shot of the disk partition layout? You can do this from the Computer Management-> Disk Management plugin. Is your disk layout unique or just what ever windows picks when you install it?

[plegrand]

@george1421

[george1421]

@plegrand Are these from 2 different computers?

In the top picture the partitions go

1. efi,
2. 
3. reserved
4. extra

In the bottom picture

1. efi
2. reserved
3. 
4. extra

[plegrand]

@george1421
No it’s the same computer
The photo come from boot pxe and Information computer fog utility

[plegrand]

@george1421
Do you think i should upgrade FOG to the latest version ?
I’m using fog 1.5.0
Is there some risks to upgrade to 1.5.4 ?
Thanks

[plegrand]

@george1421

[plegrand]

@george1421
Hello,
i found this in the forum:
https://forums.fogproject.org/topic/12115/dell-optiplex-3050-avec-windows-10-uefi/6
Then i made a try by modify the “/var/www/fog/service/ipxe/refind.conf” file

# scanfor internal,hdbios

Now it works :
After the PXE boot menu
It display refind logo
then it display "Pausing before disk scan; please wait…
It display 2 time dell logo
at the third time : It launch windows 10.

Could you explain me why :

• Could you explain me why it works now ?
• It display “Pausing before disk scan; please wait…”, while i disabled it

# scanfor internal,hdbios

• Why it display 3 times the DELL logo ?

Thanks for your help

[plegrand]

@george1421
In fact here is the situation.
The only problem i have is with uefi local boot.
i tried Exit Sanboot REFIND_EFI without success.
Is there a way to solve that?

[george1421]

@plegrand said in UEFI local disk chainloading error:

Is there some risks to upgrade to 1.5.4 ?

Wow sorry I did not see this until now. Let me try to catch up.

1. Yes you should always be on the latest release. Currently its 1.5.4, the developers are working on some fixes to 1.5.4 with the 1.5.5 release but upgrade to 1.5.4 and then I can help you with the fixes to 1.5.4.

2. If you disable options in the refind.conf file it will take what ever the defaults are built into the program. I’m trying to remember, I believe there was an issue with refind 0.11.2 where downgrading refind to 0.11.0 solve the user’s issue, but I can’t seem to remember what the problem was that this is a fix for.

3. Sometimes the uefi firmware needs a little settling time before refind scans for hardware. There is an option in refind.conf to have refind pause for a bit then attempt to detect hardware.

4. For uefi systems your only options are refind and grub the rest are mainly for bios mode computers.

[plegrand]

@george1421
No problem
i saw that there was some problem : Erasing current MBR/GPT tables.
If i follow this everything will work fine :
https://forums.fogproject.org/topic/12370/it-takes-longer-time-more-than-5-minutes-erasing-current-mbr-gpt-tables/15

thanks for your help

[george1421]

@plegrand said in UEFI local disk chainloading error:

i saw that there was some problem : Erasing current MBR/GPT tables.

To fix, you must just download to FOS kernel 4.15.2. The developers found what was causing the issue in a third party application. They are currently working with that third party application to resolve the issue. That fix will be rolled out with FOG 1.5.5 and the linux kernel 4.18.x.

There also is an out of memory condition that is fixed by adding a line to a php-fpm config file. With these two fixes FOG 1.5.4 works pretty well. There is still an issue with multicasting with 1.5.4 that has been fixed for 1.5.5. I believe the developers are trying to track down a FOG image replicator issue at the moment.

[plegrand]

@george1421
Can you explain me how you do that ?
Kernel 4.15.2 and php-fpm config file

[plegrand]

@george1421 Just updated…
local boot uefi works fine
Great !!!

[george1421]

@plegrand For the kernels you can do that via the FOG Configuration->Kernels menus. Just download both the 64 bit and 32 bit kernels.

This step adds a memory setting to the php-fpm www.conf configuration file.

1. Change to the /etc directory from the fog server linux command prompt.
2. Search for www.conf file. It can be in a number of locations depending on what version of php is installed. Use this command.
   find /etc -name www.conf (hopefully you will only find one)
3. Edit that file and comment the line but the default is 32MB change it to 256MB to make it look like this: php_admin_value[memory_limit] = 256M

php_admin_value[memory_limit] = 256M

4. Save and exit your text editor.
5. Reboot the fog server.

[plegrand]

@george1421 Thanks a lot for your help

if you didnt see that :

with the 1.5.4 version the local uefi boot works fine !!!

[plegrand]

@george1421 As i’m behind a proxy i think there is a problem to download kernel from web interface.
But proxy is configured in FOG settings; Proxy Settings

Then i followed this :

cd /var/www/fog/service/ipxe
mv bzImage bzImage.orig
wget https://fogproject.org/kernels/bzImage
mv bzImage32 bzImage32.orig
wget https://fogproject.org/kernels/bzImage32
mv init.xz init.xz.orig
wget https://fogproject.org/inits/init.xz
mv init_32.xz init_32.xz.orig
wget https://fogproject.org/inits/init_32.xz

It’s the latest kernel !!
Is it OK for you?

Thanks a lot again.

[george1421]

@plegrand You actually don’t want to latest kernels at the moment. You wan 4.15.2 not 4.18.x. You can get the kernels from here: https://fogproject.org/kernels/

The process you used is right, you just need to get the correct files. Also you can check the version of the bzImage files by using the command sudo file bzImage That will print out the kernel version of the target file.

[Sebastian Roth]

@plegrand @george1421 If using the latest inits (https://fogproject.org/inits/init.xz) you are fine to use the latest kernels as well. I uploaded fresh fixed inits that fix the slowness issue a few days ago.

[george1421]

@Sebastian-Roth Very nice.
On a side note do those inits also address the intel raid-1 monitor application too? That one was related to a bootroot issue. Disregard, I see you answer the question in that thread too.