FOG Hangouts

@fry_p While you are right that options can be used for MSI install (very important I know!) this is not something specific to MSI. The SmartInstaller can also be called using options: https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_0.10.0.2B_Installation_Options

@shruggy Wuuld you mind opening a new topic on this as it’s not related to the initial post. We try to keep things sorted for others to easier find a solution when reading this. You might just open a new one without much text and I can move your post over.

Please take a look at the apache and PHP-FPM logs (see my signature) and post information from the time when this happened in the new topic.

@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.

@lkisser in regards here it almost sounds like there could be 2 hard drives on the 3620? If so chances are the drive that is set to boot still has windows 7 installed, and the other drive actually has the windows 10 image on it. This is possible but again we’re left with too few details.

This is heavily dependent on what you’re doing. Seeing as 3600 != 3620, does the 3620 have a windows 10 capability?

What type of image are you using? For example, if the image you’re using is OEM, you can only deploy this image to the same make/model of machine. Legally speaking. In order to use a common image you would need to purchase one VL key for each make/model type you have. You would also need to use a different OS, Not the one the manufacturer deployed on the machine you’re using.

As @Sebastian-Roth has stated, fog is an imaging software. If you deploy an image to a machine, it will not magically switch back and forth to Windows 7 or Windows 10. It will be whatever you deployed to it. Plain and simple. Whether this image works or not.

Generalizing an image to be hardware independent is a task in and of itself and there are many posts around here and the internet to do such things.

What does the SAN 0x80 have to do with this? This is an error for some BIOS models. That’s why there’s many different exit types. All this element of FOG does is tell the machine to boot to the first hard drive.

@lkisser Sorry but I still don’t get why you keep mentioning Windows 7 and Windows 10. Just doesn’t make sense to me.

FOG is an imaging software. You take an image of one computer (whatever OS is installed) and you deploy it to another one. I can’t see how you could have a generalized Win 10 image, deploy that, fails and you reboot to be back in Win 7?!?

Sorry if this sounds silly. I don’t mean to be rude. I just don’t understand what you mean. Please try to use more words to explain what you are trying to do.

@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?

@Demache Nice we found this and you were able to fix it so quickly. When looking through the code I thought about HTTP/HTTPS possibly being an issue but dropped that idea. Now looking at it again I think you have found a bug in the code! Just pushed a fix.

Though I still really wonder why the backup logic of checking size via FTP didn’t work in your case either.

@mattlong01 Please read through this topic and try the suggestion on manually creating the Windows EFI bootloader entry to see if that might help: https://forums.fogproject.org/topic/14142/fog-doesn-t-copy-nvram-from-cloned-machine-to-the-new-machine

@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.