Unable to boot to disk after PXE Menu timeout
-
@jmvela2x what style of firmware does the target computer have (bios or uefi)?
-
@george1421 Our environment is a mix, but the primary test system we are using is legacy (BIOS) based.
-
@jmvela2x ok in the host definition for this test system, there are two exit modes one for bios and one for uefi. Depending on the target computer FOG will pick the right one for the target computer.
These are valid bios exit modes
sanboot
grub (any flavor)These are the valid exit modes for uefi
refindI don’t know off the top of my head what
exitdoes. FWIW you can not use a bios exit mode on a uefi computer, the same the other way around.So for bios computer exit mode of SANBOOT works 99% of the time the other 1% grub will work.
-
@george1421 I’m aware of this from having read other threads. In my testing of this one system I have changed the settings for both exit types to match on each test to eliminate that variable being at issue. The issue still stands in that I am unable to successfully boot to a drive after the menu timeout with any exit type.
-
@jmvela2x Its highly suspicious that SANBOOT is failing to boot the target computer in bios mode. I’m not suggesting that it will not fail, but based on my experience it has always worked.
So if you change the boot order in bios to hard drive first does it boot into the target OS?
What target OS are you working with?
-
@george1421 It definitely does work if we change the boot order to boot to the hard drive. The OS is Windows 10.
Everything else works: host registration, image capture and deployment, etc. It’s just this one thing for the moment that’s a blocking issue.
Again, I am able to hit the iPXE menu and ‘exit’ to boot target OS disk using the ‘exit’ option (but only in 1.5.9 mainline; in 1.5.9.119 I see the ‘Booting from SAN device 0x80’ every time in every exit mode).
-
@jmvela2x said in Unable to boot to disk after PXE Menu timeout:
device 0x80
So how are these target computers setup? In bios terms 0x80 is the first hard drive in bios where 0x81 would be the second detected hard drive in bios.
Is the boot drive on these computers sata or nvme?
What is the model of computer you are using for testing?
There has to be something here that’s different.
-
@jmvela2x On one of these windows computers, will you post a picture of the disk manager showing the disk and partition layouts?
-
@george1421 The boot drives are SATA. The system is a Gigabyte Z390 Aorus Ultra.
I am finding that I see different behavior (in 1.5.9.119) by changing the exit type at the host configuration page rather than Fog Configuration>Fog Settings>FOG Boot Settings though.
I thought the latter would override the former.
-
@jmvela2x The global settings are applied first, then host specific settings will override the global settings. This way if there is a one off situation you can fix the boot method for individual computers without impacting all computers.
Understand when you say you have a bios computer and SANBOOT doesn’t work, its equivalent to saying the sky is green. While it can happen, it should be. That is why I have so many questions, I must be missing something.
-
This post is deleted! -
It just sits here with a flashing cursor.
-
Here’s the output of <http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=<mac_address_of_vm>> if it helps any:
#!ipxe
set fog-ip 10.132.81.150
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
set storage-ip 10.132.81.150
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://10.132.81.150/fog/service/ipxe/nothingisbeyondourreach.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0x00567a 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is registered as f223-100-15-z3!
item --gap – -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.keyreg Update Product Key
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.quickdel Quick Host Deletion
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 30000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.memtest
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
:fog.keyreg
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param keyreg 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.deployimage
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.multijoin
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param sessionJoin 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.quickdel
login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param delhost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
param sysuuid ${uuid}
:fog.sysinfo
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://10.132.81.150/fog/ consoleblank=0 rootfstype=ext4 storage=10.132.81.150:/images/ storageip=10.132.81.150 nvme_core.default_ps_max_latency_us=0 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
:bootme
chain -ar http://10.132.81.150/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot -
@jmvela2x said in Unable to boot to disk after PXE Menu timeout:
:fog.local
sanboot --no-describe --drive 0x80 || goto MENUThis is what I would expect for a bios exit.
Again can you post a picture of your disk layout using the windows disk manager for this target computer?
-
@george1421 Missed this the first time. Apologies.
-
@jmvela2x The only thing I see strange is there is a mfg recovery partition in the first position on the disk, where normally under bios the first partition is the OS partition.
Using diskpart can you see which partition is marked active?
-
@george1421 Nothing reports as active it seems. This is a GPT disk.diskpart.txt
-
@jmvela2x I’ll need to check a bios based computer, but I think the C drive needs to be marked active. Some of these OEM recovery system will insert themselves in the boot order in case the main OS is corrupt. They chain load from their partition to the C drive partition. So I could see why sanboot isn’t working because it can’t find an active partition to chain to. But its been a few years since I dealt with a bios based win10 install. So I need to confirm it.
-
@george1421 We also have a legacy (MBR) based install master image of Win10. I will test SANBOOT exit for this OS tomorrow when I am back on site.
Refind EFI should work though right? I’m booting PXE with legacy FW and the OS is UEFI based. This is what I see in that case:
-
@jmvela2x said in Unable to boot to disk after PXE Menu timeout:
Refind EFI should work though right? I’m booting PXE with legacy FW and the OS is UEFI based. This is what I see in that case:
I’m not sure I understand the statement. With a uefi system (pxe booting ipxe.efi) the exit mode should be refind. Now if you would have said bios works perfectly but uefi kind of hangs, then there are settings in the refind.conf file that we might need to tweak. But refind does do a pretty good job finding the uefi boot partition on the disk. What you have on the screen is typical of a uefi exit.
