FOG doesn’t copy NVRAM from cloned machine to the new machine

[Sebastian Roth]

@marted First I may ask you to read my answer in this topic: https://forums.fogproject.org/topic/13922/dell-optiplex-aio-5270/2

Now let’s go and see what we can do for you. First I suggest you schedule a debug capture task for your master/source host. Boot it up till you get to the shell and run passwd to set a root password and then ip a s to see which IP the client got. Now open s SSH connection from your working PC to this host (using Linux ssh command, Windows Putty or other SSH tool) and login. This is a great way to be able to copy and paste commands and output from and to that host.

At the same time you want to schedule a debug deploy task for one of your hosts that has the booting problem but has been deployed already but not messed with bcdedit or anything yet. If you don’t have one that is deployed but untouched beyond that you can choose any host and just do the deploy in debug mode as it brings you back to a command shell as well. Just run for command to start deployment. Then as well set a password, get the IP and connect via SSH remote to it.

Now you are ready to do the transfer of NVRAM entry manually for testing. Make sure you note commands down so that you can put it all back together into a post deploy script later on.

Start on the master/source host. Run efibootmgr -v to get a full list of NVRAM entries on this host. Copy & paste the output to a text file on your PC. I am fairly sure there will be at least one entry that looks like this:

Boot0000* Windows Boot Manager HD(1,GPT,1bfbc945-8f25-48bd-be06-c2e5f34e3337,0x800,0x145000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS…x…B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}…C…

Pay most attention to the part where it says ... HD(1,GPT,1 .... In this example it means HD1 = disk nr. 1 = /dev/sda in the Linux world. And GPT1 = partition nr. 1. Those numbers and specifiers can be different on your system. If you have trouble understanding it you might just post the full output here so we can take a look. Now on the destination host you can try creating an EFI boot entry like this:

efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\Microsoft\Boot\bootmgfw.efi' --label "Windows"

Make sure you use single quotes for the loader parameter to not have to mask the backslashes.

Now reboot the machine and see if it works. When you have found the correct command you want to read George’s topic on post download scripting.

Note: Beside all that I am really wondering if you keep your hosts to boot through PXE after deployment. In that case it should load iPXE and then exit back to the local hard drive via rEFInd. That usually is able to find the Windows EFI bootloader on disk and will boot into that straight away.

[marted]

@Sebastian-Roth said in FOG doesn’t copy NVRAM from cloned machine to the new machine:
@Sebastian-Roth that’s I love FOG, not only for the great features but for the great support. I’m surprised guys how you always try to help and you love what you do.
Now I see a light in the tunnel after a hard one week of tests.

Now let’s go and see what we can do for you. First I suggest you schedule a debug capture task for your master/source host. Boot it up till you get to the shell and run passwd to set a root password and then ip a s to see which IP the client got. Now open s SSH connection from your working PC to this host (using Linux ssh command, Windows Putty or other SSH tool) and login. This is a great way to be able to copy and paste commands and output from and to that host.

The first thing to do Monday morning when I go back to work. Actually I have already done some tests with efibootmgr in the Linux partition on the source host and I have some idea for the syntax of the command I should run on the new host post script.
for the imaged host it always depends what kind of OS it was used before imaged and if this was windows it figured it out to find the path to .efi file of windows.

Note: Beside all that I am really wondering if you keep your hosts to boot through PXE after deployment. In that case it should load iPXE and then exit back to the local hard drive via rEFInd. That usually is able to find the Windows EFI bootloader on disk and will boot into that straight away.

Actually I have a question for you about rEfind boot loader.
I know it is the default selected for exit from iPXE boot but because probably of the fact we use grub2win before the windows boot loader in the list, rEFInd is not capable to start it and stay on start black screen and do nothing. I was wondering if I can add a new entry in rEfind manualy and like this send it to the .efi file of grub2win or even better to add a new entry in the iPXE menu with path to grub2win .efi and select it like the default one on the top. In this case I think even the machine can not find the boot loader will boot in iPXE and on the exit menu will go find the .efi of grub2win. Now the question is how to do that in FOG? I still didn’t figured it out.
But even I do that and works, the question is how to provoke the host to go and rewrite the NVRAM variable once it is in windows for example. I still don’t understand it. Because on one host, new cloned, it was able to boot in windows but had never rewrite the NVRAM variable and on reboot start again windows without seeing the grub2win, which is cleary on its place in the EFI partition.
Thanks again fo your help!

[Sebastian Roth]

@marted said in FOG doesn’t copy NVRAM from cloned machine to the new machine:

I was wondering if I can add a new entry in rEfind manualy

Sure you can. While I am not an expert on this and don’t know the right commands from the top of my head I can at least point you to the config used: /var/www/html/fog/service/ipxe/refind.conf

I know it is the default selected for exit from iPXE boot but because probably of the fact we use grub2win before the windows boot loader in the list

Can you be more specific on what you mean by that? Why do you use grub2win and is it installed on disk (in the EFI partition)? Why? As well, which version of grub2win do you use? Is your version ready to handle EFI properly at all?

[marted]

@Sebastian-Roth said in FOG doesn’t copy NVRAM from cloned machine to the new machine:

Can you be more specific on what you mean by that? Why do you use grub2win and is it installed on disk (in the EFI partition)? Why? As well, which version of grub2win do you use? Is your version ready to handle EFI properly at all?

Ok, I’ll try to explain. Now we have a lab with 400 hosts and all of them are dualboot Windows Linux. All computers must be booted in windows when nobody use them. The choice of Grub2win came after we couldn’t find a propre solution how to make the host to boot from a distance in Linux partition from Windows, because was not easy to change grub 2 from windows and even we are able to mount Linux partition and change the options in grub.cfg file and reboot after , it was not a stable solution and even when Linux partition is formatted on ext4 it was more difficult. We have to used different software. Now we found Grub2win (grub efi version more customizable and excellent solution for dual boots do Windows installed) which we can very easy control with a simple Bach script. I created a process which works perfectly for imaging the hosts- install a image host with Windows/Ubuntu and Grub2win - take the image and send it to a host - it will boot in Windows because Grub2win was made if a client doesn’t make a choice between Windows Ubuntu in 5 sec it will automatically boot in Windows - join domain grace a fog - after small snapin change the conf file of Grub2win and make Linux default and reboot - the computer reboot and go to Linux - there I created a script to rename the host an it joins Active Directory - at the end the script change again the config file of Grub2win from Linux and make Windows again default system - reboot. Works great!
Now, without touching the host we have two system renamed and joined domain and stays booted in Windows at the end (condition asked by the professors who give courses in the lab). Staying in Windows give us possibilities to always control hosts with fog client (stop, restart, send packages) and if we want to boot in Linux we send a snapin and puppet make it’s job in the Linux partition for update Ubuntu and install packages.

Now I need only to figure out how to solve the problem with NVRAM.
I hope is clear the information.

[Sebastian Roth]

@marted Ahhh, now I see. Well done, seems like you have come up with a great process to make sure both your Windows and Linux installation are setup nicely after the image deploy and changing OS on reboot works as well!

While I haven’t tried grub2win myself I would expect you need to adjust /var/www/html/fog/service/ipxe/refind.conf to make it find your grub2win binary in the EFI partition. The information about adding an entry to NVRAM using efibootmgr tool probably doesn’t help in your case I’d think.

So I would assume the easiest way right now is adding a menu entry at the end of this file like this:

menuentry grub2win {
    loader /EFI/grub2win/grub2win.boot64.efi
}

As well you want to adjust line 441 in refind.conf and set to default_selection grub2win - all untested… see what you get.

Note: This change will reflect on all systems booting to the iPXE menu and chainload to disk. Just be aware this might have an impact on all your clients at once.

One thing that came to my mind when reading your post is that you might be able to achieve the same thing by adding specific Host EFI Exit Types (host settings in the web UI) and switch between those for individual clients or groups of clients. BUT the issue is this part of FOG is not customizable as of now. So it would need manual code adjustments in bootmenu.class.php unfortunately. I can’t give you a ready-set-go solution for this right away as I haven’t done it for UEFI machines myself yet. Some years ago I used the old grub4dos binary we ship with FOG since a long time to switch default boot between Windows and Linux on MBR/legacy BIOS based machines when those chainload back to boot from disk as a default from the iPXE menu when there is no task scheduled. Sorry this sentence is a nightmare but I still hope you get what I mean.

So I could see you using rEFind or even grub2win (if it’s PXE capable) to boot the two different OSes without having to modify the grub2win config on the clients at all. Probably don’t even need to install grub2win on the computers. Not saying this is the most reasonable way to go. As you already have it working the way you have, you might just stick to it. Just thought I throw this in for something else to look at.

[marted]

Thank yo so much @Sebastian-Roth . I’ll try tomorrow the config you suggested and will give you feedback.

[marted]

@Sebastian-Roth sorry for my late response but I wanted to test everything before asking you again for help.
Now the problem is that I see the rEfind menu in some model UEFI (HP 800 G2 UEFI) and on other HP 800 G4 UEFI), the boot stays on the message rEFInd initializing and does nothing.
Furthermore, on the first one model where I see the menu, I still don’t understand something - I added the menuentry for grub2win you suggested and I cannot see it. After I deactivated ALL entries and still see the same menu on boot! Do I have to run some command to apply the changes in refind.conf file or it applies the changes every time it boots?
Just to mention we compare the BIOS of both two computers G2 and G4 and they are equal, secure boot disable and legacy disable.

[Sebastian Roth]

@marted Try the latest rEFInd version you find here: http://sourceforge.net/projects/refind/files/0.11.4/refind-bin-0.11.4.zip/download

See if those work better than the ones we have as default.

After I deactivated ALL entries and still see the same menu on boot! Do I have to run some command to apply the changes in refind.conf file or it applies the changes every time it boots?

Changes should be active on the next boot as soon as you save the file. Though I haven’t played much with the config lately. Maybe there is some option that I have forgotten about that you need to enable/add/change/remove to make those boot entries work. @george1421 would you have an idea?

[marted]

@Sebastian, from the downloaded zip file, do I need just to find the .efi file x64 and replace the old one on the server with it? what about the .conf example in the zip? Do I have to copy it also to the server replacing the old one?

[Sebastian Roth]

@marted I would say use the .efi file should do. If you are keen you can copy the .conf over as well but using a different name and diff the two files.

[marted]

@Sebastian I tried your other suggestion for executing a postscript and I came with this command I executed in debug session on a client and it works
For me, it will be a better solution instead to mess up with rEFInd boot.
Now I need just to figure out how to add the script and where

efibootmgr --create --disk /dev/sda --part 1 --loader ‘\EFI\grub2win\g2bootmgr\gnugrub.kernel64.efi’ --label “Grub2Win”

[marted]

@Sebastian to run this command with efibootmgr, do I need just to create a bash script, make it executable and put it in /images/postdownloadscripts. ?

[george1421]

@marted The proper way is to create a bash script and place it in /images/postdownload directory and then link (call) it into the fog.postdownload script. If you have different hardware or images, you can also create a conditional if statement so that it only calls this command if the image name matches a certain image name.

I have examples of post download scripts in the tutorial forum. Some are windows focused but the concepts are the same.

https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection

[marted]

@george1421 Thank you so much!

[Sebastian Roth]

@marted said in FOG doesn’t copy NVRAM from cloned machine to the new machine:

I tried your other suggestion for executing a postscript and I came with this command I executed in debug session on a client and it works

Nice. Well you might go with that for now and come back to other solutions when you feel like it.

[marted]

@george1421 @Sebastian-Roth I did the changes, just please confirm that everything I did is correct :

1. I created a file with permission 775 on the server FOG in /images/postdownloadscripts called fog.grub2win

#!/bin/bash
/bin/efibootmgr --create --disk /dev/sda --part 1 --loader ‘\EFI\grub2win\g2bootmgr\gnugrub.kernel64.efi’ --label “Grub2Win”

2. I added the script in fog.postdownload

#!/bin/bash
## This file serves as a starting point to call your custom postimaging scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post download scripts are
. ${postdownpath}fog.grub2win

is everything OK?

[george1421]

@marted Yes, I would make a comment and add a debugPause in your script so you can see it run something like this.

#!/bin/bash
echo Updating the Grub boot manager
debugPause

/bin/efibootmgr --create --disk /dev/sda --part 1 --loader ‘\EFI\grub2win\g2bootmgr\gnugrub.kernel64.efi’ --label “Grub2Win”

echo Grub configuration has been updated
debugPause

The echo statement will allow you to see while the post install script is running that your efibootmgr code is running. The debugPause will pause the code while running in debug mode.

[marted]

@george1421 thank you !

[Sebastian Roth]

@marted Looking good.