Posts made by jmvela2x

@george1421 SANBOOT does nothing using the ipxe.efi bootloader and a BIOS based OS. It defaults me right back to the menu with no action taken. Also, as far as I can tell, the exit mode is based on which bootloader I am using. If I set the exit types to reFIND (EFI) and SANBOOT (BIOS) and use the ipxe.efi bootloader then it always attempts to use reFIND. This works if my OS is EFI based and boots as intended. If I am using a BIOS based OS, reFIND comes up and leaves me at its own menu. Likewise if I set the EFI exit type to SANBOOT in this same use case, the exit only serves to reset the default timer and bring me back to the main FOG menu at boot.

I was only able to successfully move to booting from the existing OS drive from the menu while using a BIOS based OS with undionly.kpxe or an EFI based OS with ipxe.efi. While that’s progress, it’s not really what I was hoping for.

Now that I have a greater understanding I think I can pose the correct question.

Our target host need to be able to switch between BIOS and EFI based operating systems on a regular basis. I get the use case for dynamic DHCP profiles, but it seems to me that works best when each host is either EFI or BIOS based.

Let’s say for example I have an EFI version of Windows 10 on a system and reFIND is working great with ipxe.efi. After some time testing the owner of this system wants to test on Windows Server 2016, but BIOS based. Same host, different exit type.

Is there a way to make this work? I was hoping that EXIT would be the right method and would rely on falling back to the next boot device (see: exit PXE bootloader and carry on in normal boot process order).

@jmvela2x Likewise reFIND is working with ipxe.efi and a UEFI Win10 image. Continuing testing is ongoing, but I think I may be unblocked for the moment. Thanks for the help with the sanity check @george1421.

I moved to a Legacy image and SANBOOT exit is working with undionly.kpxe (I had previously misremembered that we were using undionlykkpxe).

I am waiting for a change request to be processed for the subnet scoping so I can test with ipxe.efi. Making progress at least.

@george1421 I did run across that wiki at one point. I am relatively sure our DHCP server is Windows Server 2019 at this point. Our whole organization has been moving away from 2012 for over a year now.

Since we use both types of disks, the DHCP profile sounds like the best way to go.

Just for clarification and my own curiosity, will this issue happen in reverse if I use ipxe.efi and try to sanboot to an MBR OS disk? I intend to test this either way for my own learning (as well as undionly.kkpxe with an MBR disk. Also, what is the ‘Exit’ boot option for if not to just fall back to the next boot option in BIOS?

@george1421 I tried that too. I posted a screenshot previously of my output for REFIND. I end up with a flashing cursor and no progress.

The system has CSM support enabled (to boot to a UEFI OS) but I am netbooting in BIOS mode using undionly.kkpxe. I will attempt to change to ipxe.efi tomorrow and try again and see what results that yields.

@george1421 The disk image I provided is EFI. See EFI 100MB EFI system partition in screenshot. Since the disk structure doesn’t matter to FOG that seems to be a non-issue either way.

My BIOS has two places where I can change settings for PXE boot. In the first image you can see that boot options 1 and 4 are legacy and UEFI PXE boot respectively. UEFI is only enabled for testing and all of my troubleshooting here has been done booting to the IBA* device seen in the screenshot (what I understand to be BIOS FW for PXE booting). Booting to the UEFI PXE device fails (since the bootloader I am using is not ipxe.efi).

@george1421 The OS disk is UEFI so there’s no active partition to find with SANBOOT. The NIC Oprom booting PXE is BIOS (Legacy) using undionly.kkpxe.

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

@george1421 Nothing reports as active it seems. This is a GPT disk.diskpart.txt

@george1421 Missed this the first time. Apologies.

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

@george1421

It just sits here with a flashing cursor.

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

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

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

@george1421 Our environment is a mix, but the primary test system we are using is legacy (BIOS) based.

On the latest mainline (1.5.9) none of the options for boot exit type seem to work to boot to the next device (the OS drive in this case). I see a variety of cases:

1. grub prompt (all grub options)
2. refind efi (flashing cursor)
3. sanboot (flashing cursor)
4. exit (chainloading failed; however we are able to hit ‘s’ and then type exit and get the behavior we want here)

I moved to the latest dev-branch (1.5.9.119) and now I see the same message in all cases: ‘Booting from SAN device 0x80’.

Any ideas? The goal is to have all of the systems in our environment boot to PXE by default and then move on to the OS disk after timeout so they can pick up queued tasks, etc.

@Sebastian-Roth I’m aware of the ability to hide menu options, but there are certain things I need accessible to admins that normal users shouldn’t see. I see an Advanced Menu, but it doesn’t work how I imagined it might in that I cannot set menu items to appear there and enable it with login and only see them after selecting it. Is there a Wiki resource for the ipxe menu for 1.5.9? I have found some information, but a lot of it seems outdated at this point.