Topics created by londonfog

@londonfog I can most assuredly tell you that no one using FOG has done this before.

The challenge is getting both iPXE and the FOS Linux kernel to use the serial console port (even at that I don’t know if the SOL redirect will work correctly).

The first step is that you will need to rebuild iPXE using the built in tools in the fog server. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe I would run through this process the first time as is just to get a base line compile setup.

Then you will want to hack a config file to enable the serial console in iPXE as outlined here: https://ipxe.org/console

As an example here is the fog supplied console.h file https://github.com/FOGProject/fogproject/blob/171d63724131c396029992730660497d48410842/src/ipxe/src/config/console.h#L37 note that you will need to turn on the serial console in the console.h in the build path for iPXE. You will need to do it for both the bios and uefi config files.

You will probably want to add the following lines right under enabling the serial console.

#define COMCONSOLE COM2 #define COMSPEED 9600 #define COMDATA 8 #define COMPARITY 0 #define COMSTOP 1

You will need to make the changes correctly for your SOL configuration.

Then rebuild iPXE a second time. This time move the built files to the /tftpboot directory.

Now for bzImage (fos linux kernel), it looks like you just need to add this to the global kernel args settings console=ttyS2,9600

@londonfog Not sure but I don’t think there are API calls for the iPXE menu stuff. I suggest you look into using a SQL query/insert or you might be able to code your own plugin to get what you want.

@londonfog You only get this screen when you do a deploy image from the iPXE menu? Where a traditional unicast (by registering the target computer and then picking deploy) works correctly?

OK lets see if we can get the target computer into debug mode another way. FOG WebUI->FOG Configuration->FOG Sertings Hit the expand all button, then search for KERNEL DEBUG and enable the check box and hit save. Now pxe boot the computer and go through deploy image. Does that put you to the linux command prompt?

If not go back into the same area and uncheck that option and then search for KERNEL ARGS and paste in isdebug=yes and try it again.

Hopefully one of the methods will get us into debug mode.

@londonfog This is just a guess but the api token should be in the WebUI -> FOG Configuration -> FOG Settings page. Just hit the expand all button then search the page for API. This is where I might expect to find FOG (itself) related settings.

@londonfog OK lets start out with how FOG works.

Your computer pxe boots and downloads and runs iPXE that is either undionly.kpxe or ipxe.efi depending on the target computer’s firmware. Within that ipxe boot loader it has a script that finds the FOG server and then calls a file called default.ipxe. This file is in the /tftpboot directory on the FOG server. Inside default.ipxe there is a chain call to boot.php which builds the iPXE menu.

I’ll stop here because that is the relevant bits.

Now with a windows computer using a web browser you can view the FOG iPXE menu by calling this URL http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00 That will display the text program that builds the FOG iPXE menu. If you can read programs this should be 100% understandable.

Now when you register target computers with FOG, the FOG UI will add the host definition into the MySQL database on the fog server. The database in question is fog, with the table of hosts. If you log into the mysql client program on the FOG server you can issue these commands

use fog; select * from hosts;

To get a listing of hosts registered on the FOG server.

Now when you register FOG manually at the end of the registration it asks about some additional fields, Other1, Other2, and my be primary user. These are extra fields that FOG doesn’t touch or use during the imaging process. So for your custom code you could look (via sql query) at the other1 field, if that field has a specific value then you know you need to autoboot into the ubuntu auto installer.

OK NOW bringing it all together.

Create your own PHP web page (lets call it autoboot.php) that queries the fog database for the supplied mac address (this is supplied by ipxe). If the other1 field equals ‘yes’ then you will chain to the ubuntu installer code. If isn’t a match it called the FOG standard boot.php with its required parameters. Now update default.ipxe on the fog server to call autoboot.php (your code) first. Then in turn autoboot.php will either create the ipxe script to call the ubuntu installer code or the standard boot.php

To say it another way, you will write a php program that will intercept the call to fog’s boot.php to run your code.

@londonfog You’ve probably seen my post in your other topic: https://forums.fogproject.org/post/143080

I managed to PXE boot it using NFS instead of the url=...iso option. So I have not played with the ISO option. See my post and give it a try using the NFS method.

Now bacl to the point of you saying that it does work with other machines but not with Dell Precision 5750 in UEFI mode. Do you have other machines that PXE boot in UEFI mode and loading this fine? I mean, is it just that Dell Precision 5750 causing the problem or potentially any UEFI mode machine?

@londonfog said in Use http instead of tftp for fetching kernel and initrd:

and as long as directory above is in /var/www (ubuntu server here) it will work?

Yes. Your actual files will need to be in /var/www/os/ubuntu/20.04/casper/ If all you are doing is changing the protocol.

I agree that tftp over to a remote site will be painfully slow.

If your remote site has a web server available, it may be faster to host this iso locally at the remote site:
url=http://{fog-ip}/os/20.04/ubuntu-20.04.1-live-server-amd64.iso so you don’t have to copy that iso across your WAN link.

@londonfog Just wondering out loud but if that python script can hit the FOG API, and register that new host and then select image deploy when the target computer boots up for the first time and it pxe boots, it will boot right into imaging. So if you already have the image defined, then you would create one curl api call to register the new server’s name and mac address with fog, then a second curl api call to deploy your image.

ref: https://forums.fogproject.org/topic/11184/api-powershell-create-host-and-deploy-task-script

@faboulous said in 20.04 autoinstall:

If someone manage to do so, it would be interesting to check what is_casper_path and matches_uuid does and return.

I don’t have a setup to dive in this right now and so I just started looking at the code. But maybe that’s of any help to you too.

Looking at the definition of is_caspar_path I get the impression that there is no possible way for this to return 0 (true in bash logic) to actually proceed to the next check.

Edit: Ok, forget what I said here. This is using bash globbing to expand filenames when a file exists matching the glob used.

Anyhow, I figured out why it would not return successful from the do_nfsmount() call. It checks UUIDs that are stored within the ISO in path .../.disk/casper-uuid*. Now when we prepare things and copy contents from the ISO we are missing that hidden folder (starting with a dot)! To fix that run the following command on your FOG server with the ISO mounted in /mnt/loop:

cp -R /mnt/loop/.disk /images/os/mint/20

I’m able to PXE boot into the Mint20 XFCE Live system with that fix on a VirtualBox VM (hosted on Debian 10) with only 768 MB of RAM set for the VM.

@george1421 We might think about switching to rsync -a /mnt/loop/ /images/os/... in your great tutorials on PXE booting installers to prevent that from happening. What do you think?

@londonfog I just tried Ubuntu Server 20.04 as well and it is working fine too - even using kernel and initrd from the ISO and not download the netboot ones! The important part is that you need to copy the .disk folder over as mentioned above.

This ended up being the case. Apparently there was a bug in the version of ipxe.efi and cloning the version in the github repo below resolved the issue. I was so caught up in other things I forgot to actually try this until I was reading over this thread again today.

Thank you for your help!

@george1421 said in UEFI Boot:

@londonfog Hmm, ok that isn’t it then. I thought it was possible that something happened with the 1.5.8 update and ipxe.efi was damaged some how.

In each of the boot loaders (undionly.kpxe and ipxe.efi) there is a script that calls default.ipxe on the FOG server… But thinking about it now, its getting past that point because it calls default.ipxe which chains to bootp.php. That http call is failing for some reason. So default.ipxe has already been loaded by ipxe.efi.

I don’t have an answer why only uefi has this issue. I can say that 1.5.5 is kind of old, but I don’t remember your issue being an issue in 1.5.5. I guess you could try ipxe.efi from 1.5.8 to see if that changes anything. Here is the link to the github site where you can download ipxe.efi https://github.com/FOGProject/fogproject/tree/master/packages/tftp

@londonfog There is a long story about NVMe drives swaping around possibly on every reboot as the kernel does not seem to enumerate the drives always in the same order as it does with ATA/SCSI drives. For more details see here: https://forums.fogproject.org/topic/12959/dell-7730-precision-laptop-deploy-gpt-error-message

For your situation: I am not sure what we can do to help you work around this. Please read through the other topic and see if you can get an idea on this.