Posts made by AllFoggedOut

Intel NUC NUC6i5SYH
FOG v1.3.1-RC-7
NUC BIOS v57
Single M.2 256MB Intel NVMe drive
8GB RAM
LEGACY Win7 x64 SP1 = WORKS (Host BIOS Exit Type: SANBOOT)
UEFI Win10 x64 = WORKS (Host EFI Exit Type: rEFInd)
Single disk, multiple partition, not resizable.
Date Tested: 3 Feb 2017

@george1421 Yeah, maybe that was it - just a cold boot after the BIOS update to 'bed things in". Like I said, I was stunned to see the NUC suddenly behaving, so I went back in to BIOS and undid my changes to confirm if that was the cause - still boots w/o issue.

I recall there being a Wiki page somewhere listing hardware that is known-to-work with FOG. Would be good to update that with this information. Not sure if this account has permissions to update…otherwise I’ll create a new one.

So, for reasons I don’t quite fully understand, the problem appears to be resolved (it wasn’t working yesterday after I installed v57 BIOS…)

I was looking at BIOS options, hoping to find something along the lines of “Always show Boot Menu”, thinking this might be a hack to work around the problem. Following a reboot I discovered the NUC now boots from iPXE Boot Menu w/o issue.

I’m still a little confused as to how this is now working, after testing it yesterday and finding it wasn’t playing ball. Not sure if the act of disabling the SATA channel has somehow adjusted configuration somewhere (I re-enabled SATA to confirm if that was the cause, but it made no difference - everything still works fine).

I’ve just completed a Legacy Win7x64 SP1 image deployment + reboot - no issues at all.

Weird…but in a good way.

Just a quick update: Intel are still investigating. They did release v57 BIOS asking me to test it but it hasn’t resolved the issue.

Will update if any/more progress is made.

Edit: see my update below.

Thanks to @TomElliott for clearing things up via Chat. Seems I dug myself a hole when changing storage paths.

I’ve posted about the F10 boot weirdness on the Intel Support forums. Will update based on what comes back.

Ok, I’ll try and explain this from a different angle.

I have an issue with iPXE Exit Mode loop that is affecting Win7x64/Legacy BIOS.

In the process of trying to diagnose this issue, I decided to install Windows 10/EFI to see if this also suffered from the same problem.

During the cloning of Windows 10 I realised I was running out of disk space in “/images” on the FOG server.

I aborted the clone, cancelled the imaging task and set about creating a folder for use by FOG to store images.

I moved everything under “/images” to “/stor/fog”. Via the FOG web interface, I went into Storage Management -> DefaultMember, and changed “Image Path” and “FTP Path” to the new folder.

I then recreated the imaging task which failed because I had the wrong permissions on my folder (my fault, not a bug).

When I then attempted to deploy the same image, it failed because the FOG script “fog.checkmount” still contained the OLD storage path. Why did this script still contain the old path? Shouldn’t it have been updated to the new path when I updated DefaultMember?

I also failed to copy “.mntcheck” from /images (my fault, not a bug).

I also deleted “/images” from the server. If I had left this folder in place, I’m guessing the “Checking Mounted File System” would have just continued to work, despite pointing to a defunct/no longer used location.

Now that I’m thinking about it, the NFS exports were also not updated. I had to manually edit /etc/exports, put the new folder in and run exportfs -a.

My assumption was that updating DefaultMember would mean:

a) NFS exports is updated with the new folder
b) fog.checkmount is updated with the new folder

Perhaps the preferred/supported approach is to simply add new storage areas, rather that editing the existing ones.

None of the above has any relation to my iPXE Boot Menu issue with Win7x64/Legacy. It is a coincidental observation that I thought I’d bring to your attention in case it’s a bug with updating Storage Management paths.

@Tom-Elliott said in FOG menu boot loop after image deployment:

It’s simpler just to reboot the machine (or machines as the case may be) to pick up the new data.

The script I’m referring to is/was on the server.

@Omar.rodriguez said in FOG menu boot loop after image deployment:

I understand I might be late to this thread… but we’ve ran into this issue here at the office I work at. Do you happen to have 2 hard drives on your computer?

The NUC contains a single M.2 SSD

When you get the FOG menu on the PC and you press the “Esc” key does it boot into the OS?

No, I get an error message about chainloading failed, and an auto reboot in 10 seconds. This is for Win7x64 using SANBOOT.

My “possible bug” comment related to the fact that, after changing “Image Path” and “FTP Path” in Storage Management -> DefaultMember, to a new path, the FOG script file “src/buildroot/package/fog/scripts/bin/fog.checkmount” still contained the old path, which caused image deployment to fail at the “Checking Mounted File System” stage. The reason it failed is because I deleted the old, defunct path from disk.

@george1421, yes, this is still an iPXE exit mode issue.

In summary, Win7x64 Legacy == iPXE Exit Mode loop. Win10x64 EFI == no issues.

Win10x64 unattended capture/deployment works fine using rEFInd (SANBOOT does not work - same issue as with Win7x64 above).

Initially I had rEFInd complaining about my scanfor line containing legacy BIOS options which were incompatible since my BIOS lacked the necessary Compatibility Support Module. Removing hdbios from the list made the error message go away. Had a minor bit of confusion initially because I was editing the wrong refind.conf - correct path is ‘/var/www/html/fog/service/ipxe/refind.conf’.

I might try rEFInd again for my Win7x64 issue (now that I know which file to edit), but I don’t think it’s going to help - the fact that I got a blank screen and flashing cursor vs a rEFInd menu + error message under EFI suggests it’s not happy.

During the course of testing I had to move my image storage directory owing to a lack of space. I moved all files under /images to another LVM volume group. I then updated the path in Storage Management. I then ran into an issue post-image capture (repeated “Database Update failed” messages) which was resolved by changing permissions on the new folder (and sub-folders to fog:fog and mode 775). Not sure if this is correct, but it worked. Apache error_log showed the FTP rename operation failing. I then had a 2nd issue during image deployment where “Checking Mounted File System” failed. Seems the script “src/buildroot/package/fog/scripts/bin/fog.checkmount” still contained the old storage path (possible bug?). I also must have missed the “.mntcheck” file when moving files around - had to recreate it.

Anyway, that aside, Win10x64 clone/deploy is now working seamlessly.

@Tom-Elliott said in FOG menu boot loop after image deployment:

If the debug->fixparts method works to make the system bootable would you mind seeing if the development init’s are working for you too?
If so, please try downloading the dev init’s on your system and seeing if your systems are working after a deploy. I don’t know IF they will work and I have no means to replicate the problem currently.

FWIW, these work. I was able to capture and deploy my Win7x64 image w/o any obvious errors. Windows boots when I select the NVMe drive in F10 Boot Menu. Unfortunately, my original problem persists.

I’m going to install/clone/deploy Win10 in EFI mode and see how that goes.

@Tom-Elliott said in FOG menu boot loop after image deployment:

1. The image was pushed up and the disk was detected as GPT even though you have it setup as MBR in windows. This, by itself, shouldn’t cause any major issues but the deploy back to disk might. Though it would be ultimately better to fix the partition layout for the capture, you can fix this for deploy by using postdownloadscripts. Essentially, if you can boot the system into a FOS Debug mode and run fixparts <devicename> I suspect you’ll see it asking to fix the partition table. If it is, confirm and save, cancel your created tasking and reboot the system that booted up.

In FOG Debug, I run ‘fixparts /dev/nvme0n1’, and I get ‘MBR command (? for help)’. No sign of an error state or request to fix the partition table.

2. (Least likely if image was captured relatively recently) The MBR is not setting the partition boot partition in a “bootable” state.

If I print out the existing MBR Partition Table via ‘p’ command, I get 2 partitions, the first is set with the boot flag; all looks healthy.

Just my thoughts.

I appreciate your thoughts!

I’ve set “Host Bios Exit Type” to “REFIND_EFI” under the host definition. I’ve edited “packages/web/service/ipxe/refind.conf” to have “scanfor” set to “hdbios”. All I seem to be getting is a blank screen with a flashing cursor in the top left.

I also set “scanfor” to “manual”, and defined a manual stanza at the bottom of refind.conf. Also bumped timeout to 10. Same behaviour.

Same behaviour with SATA enabled/disabled, pressing/not pressing F10 (as described previously),

Do I need to restart something for changes to take effect?

@george1421 said in FOG menu boot loop after image deployment:

@AllFoggedOut Did you try an exit mode using rEFInd (yes I know its intended for EFI systems, but the docs also say it supports bios based systems too)? Its a long shot but it might find the boot disk. You need to change this in the host definition and for the bios exit mode.

I haven’t looked at rEFInd yet - I’ll take a look and see what’s involved.

The sanboot should use the first hard drive reported to the bios, which is why I find it a bit surprising that it doesn’t work. But I can’t say its consistent for M.2 disks.

Yeah, it’s odd to say the least.

@george1421 said in FOG menu boot loop after image deployment:

@AllFoggedOut When you don’t hit F10 you have the default boot set to the LAN?

While this isn’t an answer to the issue, do you need unattended imaging with these NUCs? If not why not just change the boot order to boot to the local hard drive and then press F10 if you need to reimage them.?

Yes, the default boot option is LAN. Yes, unfortunately, I do need unattended imaging

@george1421 said in FOG menu boot loop after image deployment:

The M.2 disk should function just like a sata attached disk.

So I’ve discovered something a little…odd.

Firstly, I had SATA completely disabled in BIOS, which I thought might be the cause of my problems (the NUC functions perfectly w/o it, save for this issue we’re discussing). Turns out, it’s not. Even with SATA enabled and set to AHCI, I’m still unable to boot via SANBOOT.

However, (with SATA completely disabled) if I hit F10 during boot (Boot Menu), it displays:

LAN : IBA CL Slot 00F3 v0104
INTEL SSDPEKKW256G7 : PART 0 : Boot Drive

If I then select LAN, once the graphical Fog Menu counts down to 0, the NUC boots to Windows! If I don’t hit F10 during boot, the Fog Menu goes back to its infinite loop.

Wth? It’s almost as if the act of hitting F10 is populating something necessary that is otherwise empty/blank/skipped…? Is this a BIOS bug?

@george1421 said in FOG menu boot loop after image deployment:

Just as a point to note, if you did something with syslinux then you have a problem. FOG does not use syslinux since the early days. iPXE is now used for the boot loader. What are you setting the dhcp option 67 to?

Perhaps a big red banner across the top of “https://wiki.fogproject.org/wiki/index.php?title=Boot_looping_and_Chainloading” to indicate it’s no longer relevant might be a good idea

DHCP hasn’t been fiddled with since install, so it’s whatever comes out of the box. Checking dhcpd.conf, it doesn’t appear to be defined. Actually, reading dhcpd.conf again, there’s a “Class Legacy” definition with “filename undionly.kkpxe”. I assume this is being applied.

This sure does sound like an exit mode issue. Are you changing the bios exit mode in the host definition or the global setting?

I’ve fiddled with both. I understand host definition takes priority? Last round of testing was with the host definition.

Also does that NUC have a personality selector? Some allow you to define Win7,Win8,W10, Linux and we found that it IS important for that personality to be set correctly. This is set in the firmware and not the OS or FOG.

Just had another look - not that I can see.

Server

• FOG Version: 1.3.1 RC7
• OS: CentOS Linux 7.2.1511

Client

• Service Version: ?
• OS: Win7x64

Description

I have an Intel NUC NUC6i5SYH, with a 256GB M.2 NVMe drive. I appear to be 1 version behind the latest BIOS update (v55) but according to the ReadMe, the only change is “Updated RaidDriver”.

For work reasons, I have Win7x64 installed and running on the device. I will be also installing/imaging Windows 10 at some point.

I can acquire and deploy the Win7x64 image w/o issue. The problem comes after task completion and reboot.

The FOG Boot Menu is displayed with “Boot from hard disk” selected. After countdown, the screen turns black and I get a text version of the FOG Boot Menu. At this point, the boot menu enters an infinite loop, repeatedly counting down from 3.

I’ve tried changing “Exit to Hard Drive Type” between all of the available options - none result in a successful boot to Windows. I also tried updating Syslinux to the latest version (as described in a Wiki document), but that also didn’t help.

The BIOS is set to LEGACY boot, and Secure Boot is DISABLED (triple checked). Boot order is LAN, NVMe drive.

I recall seeing an error message flash up on the screen similar to “Boot from SAN device 0X80 failed: Operation cancelled (http://ipxe.org/0b8080a0)”. Not sure if this has any bearing.

Using the “Exit to Hard Drive Type” of “Exit”, I get an error about chainloading failed, then an automatic reboot after 10s.

If I change the BIOS boot order to boot from the NVMe drive, Windows boots w/o issue.

Thanks for any help!

Edit: solution was BIOS v57 and a cold-boot of the NUC.