Client boot to HD goes to memtest.
-
I am seeing the same issue. I am using Trunk 5676.
Boot.php output available here http://pastebin.com/0ADFrF1v
-
@LJedi said:
... choose --default fog.local --timeout 3000 target && goto ${target} :fog.local || goto MENU :fog.memtest ...
Well, there you go. After ‘:fog.local’ there is a line missing. Depending on your configuration (general (FOG_BOOT_EXIT_TYPE) or host ‘exit type’) you should see ‘exit’ or ‘sanboot …’ or ‘grub.exe …’ there. Please check all your exit type settings in the web interface.
@mrdally204 Same for you! Let’s see if you can find and fix this within the web interface. You might have found a bug here. Please keep your eyes open and let us know if this is coming back at some point.
-
I had this problem too, upgrading to the latest trunk/svn solved it for me. This happened to me last week, so whatever svn version was valid at the start of last Tuesday was having that problem for me, but it went away after an update and restart of the server.
-
@Sebastian-Roth I decided to try to figure out how to add a WinPE option on the menu, and after I got that working (using an ISO, not wimboot btw), I noticed that boot from hard disk started working again.
I’ll see if I can repro the original bug tomorrow morning.
-
@AlexMaxwell I don’t suppose you’d be willing to share how you got winPE to work through pxe using an iso? I tried to do that many moons ago to no avail.
Please and thank you =D -
Fog Configuration --> FOG PXE Boot Menu Configuration --> Exit to Hard Drive Type
Exit to Hard Drive Type was set to SANBOOT. I did change it to EXIT and that seems to fix the issue.
-
@Arrowhead-IT I started putting together a how to last week so @Wayne-Workman can create a wiki page. Let me get a link to that document.
Here is the outline. Both methods work. I wrote the document from a brain dump, so the instructions may have a few kinks but it does work.
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog
-
@Arrowhead-IT
Obviously, you’ll have to adjust paths.- Install windows ADK
- Launch Deployment and Imaging Tools Environment (basically a glorified cmd prompt). I always run this as administrator, but I’m not sure it’s required here.
a. mkdir c:\temp\winpe
b. copyxpe x86 c:\temp\winpe\x86 - (Optional) Add drivers as per https://technet.microsoft.com/en-us/library/hh825070.aspx
a. dism /Mount-Image /ImageFile:c:\temp\winpe\x86\media\sources\boot.wim /index:1 /MountDir:C:\temp\winpe\x86\mount
b. dism /Image:C:\temp\winpe\x86\mount /Add-Driver /Driver:d:\share\winpe10.0-Drivers-A01-6XFM6\winpe\x86 /recurse
c. dism /Unmount-Image /mountdir:C:\temp\winpe\x86\mount /commit - Delete bootfix.bin (to get rid of the ‘press any key’ prompt)
a. del c:\temp\winpe\x86\media\Boot\bootfix.bin - Create ISO
a. MakeWinPEMedia /ISO c:\temp\winpe\x86 c:\temp\winpe_x86.iso - Copy the ISO to the FOG server so we can access it via http
a. mkdir /var/www/html/winpe-build2
b. cp /mnt/myshare/winpe_x86.iso /var/www/html/winpe-build2/winpe_x86.iso - Create a new menu item from the FOG UI Fog Configuration->iPXE New Menu Entry
a. Parameters:
initrd http://${fog-ip}/winpe-build2/winpe.iso chain memdisk iso raw boot || MENU
Like:
- Test
-
@Sebastian-Roth I don’t know what is causing it, but I test a few possibilities
-
@AlexMaxwell You are a beautiful and wonderful person.
-
@Sebastian-Roth This was a new install from Trunk. I am still very new to the Fog project and started with a fresh install of 14.04 server and latest Trunk (5676) at the time. The default setting in PXE boot menu was “sanboot”. I switched it to EXIT per LJedi post and it seems to fix the issue.
-
I tried to reproduce this with 5686, and the boot menu looks fine, so I’d call it fixed . For anybody who’s seeing this issue, I’d recommend just changing anything in the iPXE Boot Menu, saving it and changing it back.
Now, to mark this as solved…
-
Since this thread wandered a bit, I’m not sure if we really know the root cause here. I understand upgrading to the latest trunk, and then changing the boot menu and changing it back resolved the issue. But its not clear where the issue was introduced.
I guess we will have to just keep this in mind as/if others come across the same problem.
Thank you for reporting back on a solution.
-
I added code last night to find out data and always failback to my suggested default in case it isn’t set.