LF USB Fog solution for LEGACY network clients

[sudburr]

I have LEGACY systems that boot LEGACY only (non-UEFI) that are on a network that can only handle a single bootstrap which is set for UEFI clients.

I want to USB boot these LEGACY systems to be able to FOG over that network AS IS.

A LEGACY USB solution is the only solution being considered.

[Wayne Workman]

@sudburr what do you mean by “on a network that can only handle a single bootstrap” ? Windows and Linux DHCP can hand out different options based on the arch type of the requesting system, this is outlined in this wiki article: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

[sudburr]

@Wayne-Workman Changing the network configuration is not an option. The only option being considered for these legacy machines, if they want to use FOG is to create a USB solution.

[Tom Elliott]

@sudburr while I understand what you’re looking too do, I’m just asking a question about potentially using dhcp server to determine how the machine is booting, and passing the correct pxe boot environment based on that. I’m not sure if this was considered so forgive my blindness here.

What I mean, if these machines are booting and already have network access, as the bios is setup for legacy booting you can use special cases in dhcp to handle both uefi and legacy style booting.

[Tom Elliott]

And I say this because if they’re booting uefi windows, why not just pxe boot over uefi as well. Either way, yes I suppose it’s possible, I just don’t fully understand the requirements.

[george1421]

@sudburr said in LF USB Fog solution for LEGACY network clients:

if they want to use FOG is to create a USB solution.

There already is a working USB boot solution: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

It does boot bios as well as uefi.

[Wayne Workman]

This sounds like the xy problem to me. Why can’t the network be modified?

[sudburr]

@george1421 Thank you George this is what I was looking for … I created the FOS-USB.

It boots, gets an ip, sees the server, but I cannot register/image.

If I attempt a full registration, when I’m asked to choose an image, it lists the images on the server correctly, but it will never actually register on the server. (1.4.4) so it doesn’t image.

Registration says it succeeds but buried in the wall o’text is that it cannot find a valid MAC; even though it IS communicating. Checking the server and there is no host entry for this newly `registered’ machine.

I am able to register a machine that can UEFI network boot directly from the FOG server.

The UEFI machine suffers the same problems when using FOS-USB.

Choosing to deploy/image, I don’t receive an option to choose an imagem then I eventually get:

/tmp/hinfo.txt: line 1: invalid: command not found
* running post init scripts ...Skipped
An error has been detected!
Fatal Error: Unknown request type :: Null
Kernel variables and settings:
BOOT_IMAGE=/boot/bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=10.12.40.14/fog/ boottype=usb consoleblank=0 rootfstype=ext4

The “command not found” pointing at /tmp/hinfo.txt shows up a lot in the registration outputs.

[sudburr]

@Wayne-Workman Nope. Pretty cut and dried.

Certainly with the right tools anything can be done with anything, but this isn’t anything. It’s A connecting to B using only A… no C, no D, no E and certainly no F. That’s just the way things are in this particular design equation. Adapt or die.

[sudburr]

@Tom-Elliott Legacy machine cannot boot UEFI, ergo cannot boot UEFI no matter the source.

[george1421]

@sudburr Did you remember to update the grub.cfg file?

The hinfo.txt file is created by a call to the fog server during FOS boot up. Are you enforcing https on your server or will http calls work?

Fatal Error: Unknown request type :: Null
This is covered in the caveats section. You need to schedule the job first on the fog server then usb boot the target computer and pick option #1. Understand the usb boot option gives up on some tight integration with FOG to bypass pxe booting altogether. There ARE trade-offs.

[sudburr]

Yes, grub.cfg is configured. The server is using http not https.

If I attempt a full registration, when I’m asked to choose an image, it lists the images on the server correctly, but it will never actually register on the server. (1.4.4) so it doesn’t image.

[sudburr]

@george1421 Manually populating the host, assigning an image, then creating the task to deploy, deployment via FOS-USB still fails with same results.

[george1421]

@sudburr Ah, just for clarity your fog server is 1.4.4? If so you need to fix a few things since the instructions build a 1.5.4 compatible FOS environment.

The solution is pretty easy, just copy from /var/ww/html/fog/service/ipxe the following files to the /boot directory (I think, check to see where they are on the flash drive) replacing…

bzImage32
bzImage
init.xz (probably the root of your error)
init_32.xz

The inits where changed between 1.4.4 and 1.5.1 which is probably causing your error. The FOG USB was developed using FOG 1.4.4 so it should work.

[sudburr]

@george1421 Bingo bango bongo! We have liftoff.

Thank you George. Wonderful work.

[Tom Elliott]

@sudburr that’s where i was confused. I was thinking it would boot uefi no problem, but for whatever reason you needed it to legacy boot for imaging.