rEFInd reboots instead of loading windows

[Gordon Taylor]

on Friday i upgraded Fog to 1.5.0 from i think 1.5.0 RC12 and since then the Intel NUCs i have that are UEFI boot have now started rebooting instead of loading windows after rEFInd. i don’t know if its all my UEFI clients yet as i’ve disabled the Network booting on the main LAN whilst i troubleshoot it.

I have tried from the backups that appear in the home/user folder replacing a few things, I’ve replaced /var/www/html/fog/service/ipxe both refind.conf and refind.efi
i’ve also tried using the tftp.previous instead of tftp encase it was iPXE
but it doesn’t make a difference.

a couple of NUCs that are experiancing this D54250WYK and NUC5i5RYK

[Wayne Workman]

@gordon-taylor Check the apache error logs on your fog server from the times when you know reboots have happened, please share anything interesting from that time period here in a code block.

[Gordon Taylor]

ok there isn’t anything in the apache log (/var/log/apache2/error.log) unless i change it to debug then there is lots but nothing that looks bad

[Mon Mar 19 15:58:22.168627 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of <RequireAny>: granted
[Mon Mar 19 15:58:22.283609 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of Require all granted: granted
[Mon Mar 19 15:58:22.283653 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of <RequireAny>: granted
[Mon Mar 19 15:58:22.439171 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of Require all granted: granted
[Mon Mar 19 15:58:22.439192 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of <RequireAny>: granted
[Mon Mar 19 15:58:22.486550 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of Require all granted: granted
[Mon Mar 19 15:58:22.486570 2018] [authz_core:debug] [pid 45559] mod_authz_core.c(809): [client 192.168.4.31:54649] AH01626: authorization result of <RequireAny>: granted

some of the workstations after rebooting once then get stuck with the windows boot splash screen and saying Perpairing Automatic Repair at the bottom… almost like its maybe booting the recovery partition… but its not doing anything no disk activity just stuck untill rebooted…

the only os I’ve tried so far is Win10 1709 i think i might have a uefi 1607 or 1703 image i can try see if it happens across different host oses…

[Gordon Taylor]

ok i did have a 1703 image but it does similar now it reboots then drops through to automatic repair blue screen in this case (but then its a sealed sysprep image - rather than a image that has been through the whole process) - if i pull the lan out to let it finish the windows setup then the behaviour is the same as 1709 - reboot then next time sat on preparing automatic repair splash screen.

i also have slightly different behaviour from NUC6i5SYK which doesn’t reboot but just sits with the windows logo on the screen and doesn’t boot up (no disk activity) again saying preparing automatic repair

i think there is a message from rEFInd but it flashes to quickly is there a way to interactively watch that step by step by editing refind.conf?

of course if you pull the LAN cable out so it doesn’t network boot they all boot fine.

[Wayne Workman]

@developers has the way partitions are handled changed between 1.5 RC12 and 1.5 release?

[Tom Elliott]

@wayne-workman no

[Wayne Workman]

@gordon-taylor So to summarize my understanding (and correct me if I’m wrong), you seem to be having two problems.

First problem:

the Intel NUCs i have that are UEFI boot have now started rebooting instead of loading windows after rEFInd.

Second problem:

it does similar now it reboots then drops through to automatic repair blue screen in this case

Which one is the real problem? Is there actually something wrong with rEFInd or do you think it’s image related? Or are you having both of these problems?

[Tom Elliott]

@gordon-taylor please try editing the /var/www/fog/service/ipxe/refind.conf file and set the scan_delay to 0. I’ve heard of this seeming to be a fix for this type of problem.

[Gordon Taylor]

@tom-elliott Thanks that does seem to have done the trick

[Gordon Taylor]

@wayne-workman it was really just the first but the scan_delay line seemed to fix it… but whats odd is i know there was a 5 second delay before i upgraded fog cause id see it say so on the workstations… and they booted fine until after the upgrade.

[Tom Elliott]

@gordon-taylor The binary might have changes (refind.efi) though we don’t know what changed (we don’t write the refind program stuff.)

I’ve made scan_delay = 0 the default when 1.5.1 releases.