Unable to boot properly after Radix SmartRecovery installed

[WillingMost7]

I have been using Radix SmartRecovery (It’s a protection application that does not let you make any saves on the computer, e.g: you saved a text file on desktop, after the restart it will be deleted.) on windows 10 with Grub_First_HDD Boot Exit settings on Fog.
Apparently it stopped working at some point (my guess at the recent windows update, but the corporation forces updates due to security reasons).

With “Boot Exit” set at ‘grub_first_hdd’, Radix does it recovery phase but does not load windows afterwards (PCs have M.2 if it matters).
With “Boot Exit” set at ‘grub_first_found_windows’ Radix doesn’t go into action but windows does shows up.
(Windows installed in legacy if matters).

It seems like I need to merge the two somehow. I’m lost, please help.
Thanks in advance!

[george1421]

@willingmost7 Since you are using grub, I assume your computer is in bios mode. Doesn’t SANBOOT work as expected? The grub for dos implementation in FOG is a hold over from long ago.

Might you need to reinstall SmartRecovery again to resetup windows since the windows upgrade basically reinstalled windows all over again. It might have broken the chain in booting.

This is not specifically a FOG thing because from what I see grub is working as expected. The grub_first_hdd is booting the hard drive from sector 0 block 0 where SmartRecovery lives. But SmartRecovery is not chaining to windows after it does its recovery. The grub_first_found_windows, is looking at all of the partitions to find the windows partition and then booting into windows (bypassing the sector 0 block 0 startup code). I can understand why its working as you outlined, its just not as you need.

Is your version of SmartRecovery compatible with the version of Windows you just upgraded to?

[WillingMost7]

@george1421 Thanks a ton for your good will to help me! I really appreciate!!!

Doesn’t SANBOOT work as expected? The grub for dos implementation in FOG is a hold over from long ago.

Sadly no. Actually this is the worst option for me there as it is not even posting (As I said, With “Boot Exit” set at ‘grub_first_hdd’, Radix does it recovery phase but does not load windows afterwards.
With “Boot Exit” set at ‘grub_first_found_windows’ Radix doesn’t go into action but windows does shows up).
I think it might worked with windows 7, but it was too long ago so don’t relay on that.

Might you need to reinstall SmartRecovery again to resetup windows since the windows upgrade basically reinstalled windows all over again. It might have broken the chain in booting.

I tried to install it on a fresh install of windows 10.

But SmartRecovery is not chaining to windows after it does its recovery.

Something I noticed today is that when not connected to the fog server it’s booting smoothly. It loads first the SmartRecovery and than goes into windows as supposed, once conneted to fog it is only half working.
So how do I chain it? (Although it’s weird cause it seems like it is chained, just something with the GRUB is messing it up.)

Is your version of SmartRecovery compatible with the version of Windows you just upgraded to?

I’m able to install it on the windows, but they do have a newer version of this (which also doesn’t work well).

[WillingMost7]

There’s a file named “bootmenu.class.php” in /var/www/fog/lib/fog, in it there’s the following code:

self::$_exitTypes = array(
    'sanboot' => $sanboot,
    'grub' => $grub['basic'],
    'grub_first_hdd' => $grub['basic'],
    'grub_first_cdrom' => $grub['1cd'],
    'grub_first_found_windows' => $grub['1fw'],
    'refind_efi' => $refind,
    'exit' => 'exit',
);

Now as I said before when selecting grub_first_hdd it does recovery phase but does not load windows afterwards and when selecting grub_first_found_windows it skips recovery phase but windows loads.

If I chage the code that way (change is in the $grub['XXX']:

    'grub_first_hdd' => $grub['1fw'],
    'grub_first_cdrom' => $grub['1cd'],
    'grub_first_found_windows' => $grub['basic'],

The exact same thing is happening but the opposite, meaning now grub_first_found_windows it does recovery phase but does not load windows afterwards and when selecting grub_first_hdd it skips recovery phase but windows loads.

[WillingMost7]

I read on other thread that the fix was done by changing the boot file to ipxe.kpxe.

I followed a guide on GitHub to change the boot file (under Configuring DHCP section), but it does not seem to work. I will try all the boot files there.

Thanks again for all your help, just sharing my progress

[WillingMost7]

@willingmost7 said in Unable to boot properly after Radix SmartRecovery installed:

I followed a guide on GitHub to change the boot file (under Configuring DHCP section), but it does not seem to work. I will try all the boot files there.

I had to use sudo ln -sf to force the symbolic connetion.

[george1421]

@willingmost7 For the dnsmasq configuration: I’m not going to knock others tutorial on github, but that dnsmasq configuration is a bit lacking (such as booting using uefi firmware). Look over the config file in this tutorial: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server This config works for both bios and uefi if you are using dnsmasq.

[WillingMost7]

@george1421 I have managed to change the boot file but also followed your guide you posted, anyhow it didn’t make any change cause it is still not chaining to windows after the restore phase.

I have found another Reboot to Restore software named DeepFreeze and it manages to do the job well unlike Reboot to Restore Rx and Radix, wonder what is different.

[george1421]

@willingmost7 Understand this issue is outside of the scope of FOG and imaging.

Now how most of these things work is that they are installed after windows is installed. These restore programs take over the booting process before windows loads. So they inject their startup code between the firmware (bios or uefi) and windows. In your case if you are using grub, grub4dos (its executable name) only supports bios based computers. The ‘grub_first_hdd’ setting basically chains from grub executable to device 0x80 (first hard drive in the system) and loads the boot blocks from there. The boot blocks is where these restore programs gets called. The setting 'grub_first_found_windows’ actually looks at each hard drive 0x80 - 0x84 for a windows directory and then boots windows without loading the boot blocks. I don’t know why chaining to the boot blocks of the disk doesn’t call your restore program, then your restore program calls windows. This problem has nothing to do with pxe booting or whatever, it exists solely with grub4dos and chaining into your recover program. If you were using sanboot then that is an iPXE function (the program that builds the FOG iPXE menu).

[WillingMost7]

@george1421 said in Unable to boot properly after Radix SmartRecovery installed:

I’m not going to knock others tutorial on github

This is also shown in FOG’s wiki.

@george1421 said in Unable to boot properly after Radix SmartRecovery installed:

If you were using sanboot then that is an iPXE function (the program that builds the FOG iPXE menu).

Unfortunately sanboot isn’t working at all, even without the software. The weird thing is that Radix works with windows 7.

@george1421 said in Unable to boot properly after Radix SmartRecovery installed:

0x80 (first hard drive in the system)

Maybe cause these PCs have M.2?

[george1421]

@willingmost7 said in Unable to boot properly after Radix SmartRecovery installed:

The weird thing is that Radix works with windows 7

So is it certified for the version of windows 10 you are using? Well it works when fog is not in the picture.

While this isn’t an answer: In my organization we don’t have/allow to pxe boot through the iPXE menu, but instead I make the imaging tech sit in front of the computer and boot the computer with the F12 boot menu (dell) to pick the network boot menu. This does a few things for us:

1. Under normal booting the fog server is not involved with the computer starting up.
2. You don’t accidentally reimage the CEO’s computer when an imaging tech picks the wrong computer to rebuild and auto imaging is enabled.
3. The technician knows exactly what computer he/she is working on (because they sit in front of it to hit the F12->Network boot menu).

The down side to this is if you want to image a classroom full of computers you need to go to each computer and pick network booting. You can’t just issue the remiage command to a group of computers and the computers just do it.

[WillingMost7]

@george1421 said in Unable to boot properly after Radix SmartRecovery installed:

So is it certified for the version of windows 10 you are using?

Yes indeed.

@george1421 said in Unable to boot properly after Radix SmartRecovery installed:

Well it works when fog is not in the picture

Thus I thought that FOG is the problem here. Everything I tried here had a different effect but none actually help me understand how to solve this.
Also someone managed to solve this by changing the boot file, I discovered that the exit-type of the boot types causes the effect, so it seems to me only logical that it has to be the FOG server.

Thanks a lot for all your time and effort.

[WillingMost7]

Here is the fix:
Try every boot file until you find the right one for you.

This is what I did as I ran out of options and it turned out to be good. Follow this tutorial: https://wiki.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server under DNSMASQ settings for iPXE