Topics created by Zer0Cool

I actually made some progress on this front. It became a bit more clear when I thought it over and made some considerations.

My setup is such that I have mirrored (via rsync) local repos of CentOS and Fedora. I then symlink the ISO’s within those repos to another place to make them easy for people to download the ISO. In this scenario I don’t have to do anything with the ISO to get the installation files need by PXE as they are available in the repo as I have syncd them.

With the above in mind, I should be able to accomplish the same for any Linux distro that I can mirror/rsync locally which nullifies the needs/goals of my OP.

I then thought about what OS’s this need actually applied to, and in my case it came down to Windows 10 and ESXi (various versions). I don’t mind downloading the ISO manually. What I was looking to accomplish was being able to take an iso or a batch of them in a dir and identify their; OS, version, build, revision and be able to use that to create a unique directory structure for said iso and then dumb the iso contents into the created dir structure for it.

The part I was hung up on was how to get the information I needed for this and that part, at least for Windows 10 (really any Windows ISO) and ESXi I have figured out at least as a proof of concept. I realized that the iso file name would not be the most reliable method of doing so and found ways unique to each OS family to identify the metadata I needed.

ESXi (having checked multiple Dell isos from 6.5-6.7):

I found that they had a /upgrade folder with 2 note worthy files in them. metadata.xml contains the version number and build number. profile.xml has the full name (so even if the file name of the iso is changed this should stay the same) from which I could extract things like the Dell revision and U1/U2 monikers used for Update 1 and Update 2, etc. It also has a tag for “creator” so I should be able to differentiate between Dell isos and non-dell isos.

To parse out the xml I found that xmllint provided by libxml2 would allow me to reliably pull this info from the xml files. Coincidentally, libxml2 was needed by wimlib anyhow (mentioned below for Windows).

Windows 10:

I installed wimlib and using the wiminfo command on the install.wim (combined with grep) I am able to pull information about the ISO as well as deduce if the ISO is a Windows ISO. I can get name, version, build number in this fashion.

I may expand this to Server 2016/2019 if they start releasing new iso builds “frequently” like they do with Windows 10, but older versions the iso hasnt changed for a long time and I have these setup already.

So basically it comes down to checking the ISO’s for the structure/files that match the OS family. In this case /upgrade/metadata.xml being ESXi and /sources/install.wim being Windows. Then I either parse out the XML for ESXi or using wiminfo pull the info from the wim file for Windows.

After that should be “easy”. Create a path using that info, check if it already exists, dump the iso contents, unmount, etc. I am also considering putting a fail safe kind of option in so that if the ISO doesnt match any conditions I am checking to “classify” it, I can prompt the user for manual input if they want to process the ISO allowing them to determine the path to dump it into.

Follow Up Question:

I hadnt considered it before, but generally speaking I assume it would be possible via the bash script to also update or add to the FOG’s iPXE menu by manipulating the “config” file that stores the menu? Or is there a database in between that would make that problematic?

I am not stuck on automating the menu creation but if its a relatively simple addition might as well add it.

Conclusion:

Once I get this written up into a moderately working fashion I intend to post it on my Github and would be happy to share the link back here.

Thanks

@Zer0Cool From what you describe you went a far step already. DHCP relay is definitely what you need to male PXE booting across subnets possible. Would you mind taking pictures or maybe even a video of a client booting that ends in the timeout? Possibly this could shed a light on what is missing.

Forget it, sorry to waste anyone’s time. Redoing it has worked on all machines. I am guessing applying just the snapin via group wiped the key fields for each host.

CentOS 7.4 and 7.5

Works with: UEFI or BIOS

To start we need the installation files in our /tftpboot/os/centos directory. This can be done by manually copying the required content from a CentOS iso or by using rsync to sync from an online mirror. A list of official mirrors with rsync links can be found here. The following will presume the latest version of CentOS (at this time 7.5.1804) but altering the version to your desired version in the steps should work.

You do not have to do the steps in BOTH “Using Files from ISO” and “From rsync”, its one or the other.

Using Files from ISO:

Create the directory for CentOS/version if it doesnt already exist: mkdir -p /tftpboot/os/centos/7.5.1804 Mount the ISO and copy the required files to the above directory: mount /{path to the iso}/filename.iso /mnt/iso/ cp -R /mnt/iso/* /tftpboot/os/centos/7.5.1804 umount /mnt/iso

Using rsync:

Do not create the subdirectory for the CentOS version, just have /tftpboot/os/centos ready, rsync will create the subdirectory.

run the rsync command using a rsync url from the list of mirrors you want to use. This can take hours to run:

rsync -avzP --log-file=/var/log/rsync_cron/rsync_yum_mirror.log --delete --include="/7.5.1804" --include="/7.5.1804/**" --exclude="*" rsync://mirrorurl/centos/7.5.1804/os/x86_64/ /tftpboot/os/centos

feel free to change the path/name of the log file. I use this rsync to also pull updates allowing me to use my FOG server as a local YUM repo as well. If interested in doing so change the rsync path to be rsync://mirrorurl/centos/ instead. This will make the amount of data downloaded much greater, but will later let you use the FOG server as a YUM repo. I placed the rsync command above in my crontab -e without the -P switch for rsync and have it sync once a day. Doing so is a bit beyond the context of this guide though.

Also note that if the mirror is down the command can fail, you may need to switch to another mirror or if setting up cron having it sync multiple mirrors just in case.

Adding iPXE entry:

From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

Menu Item: name as desired (ex: os.centoslatest) Description: as desired (ex: CentOS 7.5.1804 - Install). Note: This is what is seen in the iPXE menu on the host machine! Parameters:

Manual or rsync without wanting YUM server too:

kernel http://${fog-ip}/os/centos/7.5.1804/images/pxeboot/vmlinuz initrd http://${fog-ip}/os/centos/7.5.1804/images/pxeboot/initrd.img imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804 boot || goto MENU

With rsync pulling all data for YUM:

kernel http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/vmlinuz initrd http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/initrd.img imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/os/x86_64/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804/os/x86_64 boot || goto MENU Menu Show With: as desired. Save changes

Alternate directions here.

@quazz Got the result:

noTftpBuild=''

Not sure if thats good or bad.

@joe-schmitt Providing a remote machine wont be an option for me to help, but any testing you need done I would be happy to do and report back.

If I need to setup any machines on my end for me to test with I can do that as well.

I have a more clear picture of the process you have detailed with the snapin, makes sense. I will make some alterations next week and test it out. Thanks

@wayne-workman Ok cool, I will look into it, Thank you.

@quinniedid which is what I guessed. 🙂

@quazz Alright that appears to work. symlinks in /var/www/html are working. Thank you!

@quazz said in HTTP Redirects After Upgrade 1.5.2 to 1.5.3:

@zer0cool I think it will redirect anything with url/fog so try going one directory higher.

Since I appear to be unable to mark moderators responses as the solution I have quoted your solution and will mark this solved. Thanks!

@tom-elliott I expected that may be the case. I did not mean to imply any issue, just observations in case someone is impatient (I almost tried a reboot while it was on #2).

Now its back to trying to get the colors of the menu the way I’d like (https://forums.fogproject.org/topic/11972/ipxe-menu-colors-help).

Thanks

@george1421 I am pretty sure it comes down to the Nvidia NVS 310 GPU’s for me. It may even come down to the specific make/model of them, but all of my Dell Precision T3620’s have them. The i7-6700 in each also has built in Intel iGPU.

The NVS 310 has 2x DP connections, and when connected to either the UEFI menu renders scrambled and vertically smashed. Switching to a motherboard output, using the iGPU, it renders as expected. Come to think of it, it was also scrambling and condensing the ESXi installer…at the time I presumed it was ESXi, but now I am certain it was the specific GPU.

You may even recall me “complaining” that the text size/resolution was different in UEFI vs BIOS. This is not the case using the iGPU for me. Now BIOS and UEFI are identical in size and format.

@george1421 said in iPXE Menu Colors Help:

I know messing with the iPXE colors is a bit mind blowing

Its especially hard when half the settings dont change anything because your GPU/background removal has rendered them moot (and your not aware of it). For me the problem was even with documentation and going through it meticulously as soon as I would start to wrap my head around it I would make a change and nothing would happen (or something other than expected), which would lead to presuming I didnt have my head around it. For example setting rgb either has no effect or results in transparency or a default color when in fallback mode. So imagine setting an rgb value to what you know is blue and getting white instead. Makes you question things lol.

After switching GPU’s and getting it to render in normal mode and not fallback, I have sorted out the formatting and added my own background.

Like you I have the multi-gpu setting on auto, have been using BIOS 2.6.1 and 2.8.1 (thats how long I have been working on this lol) and had leading up to this a single monitor connected DP to the NVS 310 (now the iGPU motherboard DP port).

To be honest, if it was my personal computer I would likely look into firmware updates for the NVS…but in my case I am happy just using the iGPU for staging. Thanks for the input

@Zer0Cool I know im late to the party but…

The way to run the installer from the live only mode with fedora is with the command

sudo liveinst

then bam the installer will start and all will be well with the world

I found the answer here [https://docs.fedoraproject.org/en-US/Fedora/16/html/Fedora_Live_Images/sect-Fedora_Live_images-Installing_Fedora_from_the_Live_Image.html](link url)

@george1421 Ok so not an issue with the network, R620 works just fine off the same switch.

I am gonna chalk it up to the Dell 3620’s firmware (which is the latest) being problematic. Its not the first time it proved to be, likely wont be the last.

I guess I can live with the issue as it always eventually runs setup.exe. As long as its not a wide spread issue and limited to that model machine I am gonna move on and just live with it.

Thanks for the help though, always good to have another person to bounce ideas off and to get other ideas from.

@george1421 Yep they are all exactly the same hardware.

What are your thoughts on the Fedora issue I am having?

Thanks again for all your help!

As an additional note: each label you use must be unique across all of your menu entries.

IE: If you make a menu entry for ESXi 6.5 and another for 6.7, then these lines:

iseq ${platform} efi && goto esxi_efi || goto esxi_bios :esxi_efi ... :esxi_bios ...

must have unique labels, for example esxi65_efi vs esxi67_efi instead of both having esxi_efi (or esxi_bios).

If you use the same label in 2 different menu entries than iPXE will go to whichever is listed first in your boot.php.

Could anyone help me with just getting the colors as per my original post. I have been in the iPXE General Config | Menu colors, pairing, settings for hours and cant wrap my head around whats whats.

Put simply, here is the color scheme I am aiming for:

title text and selected text to be 0x0077c8 (selected text white background) background black unselected text white

Right now both UEFI and BIOS are greyish title, white selected text with red background, red unselected text. Its really hard on the eyes.

I have been mulling over:
http://ipxe.org/cmd/cpair
http://ipxe.org/cmd/colour

and my boot.php and just cant wrap my head around what changes what. I have tried playing around with it and the results so far have been 100% not what I expected making it impossible to gain any traction on it. Some options I cahnge and expect to see a difference appear to do nothing, others I change and expect a certain element/color to change and something completely different changes.

Thank you

Well, I mounted the ISO for 6.5 on the server, copied everything over, recreated the menu and edited the boot.cfg and the same issue:

The bootx64.efi and boot.cfg load as expected The VMWare ESXi installer loads files according to the boot.cfg The VMWare ESXi installer starts, the band/progress bar at the bottom gets past a couple stages and then PSOD on the “storage-stack” portion every time.

(all related to 6.5 U1 A10)
Tested 2x R620’s, one with all newest firmware, both have same issue. Tested on an FC630, works no issues.

ISO burned to physical media runs as expected and works in both R620’s via UEFI DVD/CD boot.

I am going to try and alter the 6.5 install to run over ftp instead of http to see if it changes anything. I had done this prior I think, but want to be sure. I will pass everything via ftp (bootx64.efi, boot.cfg and all modules from boot.cfg).

If that doesnt work I will just give up on the R620’s getting PXE booted ESXi 6.5 U1 A10. As long as its 1 or 2 machines/models that arent critical I can live with that but if the crashes become the rule and not the exception thats going to cause issues for me.

Lastly, is there anyway to via UEFI do something similar to a memdisk/iso load? I know memdisk itself is BIOS only, is there a way to UEFI boot straight from ISO?

Thanks

EDIT: ftp crashes just the same, i give up unless I can UEFI boot the ISO

Fixed in working branch.

@sebastian-roth I changed that line but do not see any difference. This is what I altered:

explode("\n", $mainFallback), array( 'goto MENU', ':get_console', "console --x 1024 --y 768 --picture $this->_booturl/ipxe/$bgfile " . "&& goto console_set || goto alt_console", )

I also noticed a vast difference between the size of the menu in BIOS and UEFI, the BIOS version is actually a little too big if anything, but the UEFI version takes up maybe 1/4 of the screen.

Any way to get these 2 menus on par in terms of size with each other?

As an aside, I thought setting the resolution to 1024x768 (matching my bg) would get the background to display, but it has not.

I guess next step is to try and save my bg as 800x600 and see if it displays, then as png instead of as jpg.

Thanks