Posts made by Zer0Cool

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

@george1421 said in Capturing a Linux Image?:

Same rules apply virtual or hardware.

I guess to elaborate I meant they were using tools specifically for virtual machines to prepare them for images.

@george1421 said in Capturing a Linux Image?:

In the VM world, I have a Centos 7 reference image setup as a template

Yea if these were in ESXi/vSphere id just do a template, but they are physical machines

@george1421 said in Capturing a Linux Image?:

In your case you want to clone fedora27 then probably have a post install script that sets the host name and any other unique qualities of the target system.

Do you mean like a generic kickstart file or something via FOG? I havent really looked much at FOG’s snapins/scripting abilities.

In any case odd thing is @george1421, I cant get Fedora 28 to boot installer. It boots but goes to a live system, seemingly no install option. If I reboot I lose it all. I get a dialog to create user but never see a dialog to format/part the hdd.

heres my config for it:

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

as mentioned, it loads, boots to desktop and asks me for a user name/pw (creation) and then boots into gnome, but must be running like a live cd. I looked at drives and it see’s my HDD, but appears to be using a roughly 8GB partition to run off.

I am at a bit of a loss since the CentOS entry I have is roughly the same and works as expected, booting the installer.

Any help would be awesome

FOG 1.5.2
CentOS 7.5

I have so far used FOG to capture and deploy Windows 7 images for a specific model of machine. The general process is I install/update Windows 7 on a physical machine and the software I need, then sysprep the machine and power down, then capture the image. This way when I deploy it, the host name is random, SID isnt the same, etc.

I have never done this process on a Linux host, in this case Fedora 28 Workstation. Is there something like sysprep for fedora that generalizes the installation?

This will be done on a Dell XPS laptop, NOT within a VM. So far all the directions I have found online are in regards to virtual machines and prepping them for imaging.

Also, is prep/image a better approach then using pxe boot to install media and a kickstart file?

Thanks

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.

@george1421 I symlinked my /tftpboot to var/www/html/fog/ so that everything i do under tftpboot in the os folder is available via http.

Turns out this works…

kernel http://${fog-ip}/fog/os/win/wimboot pause gui
initrd --name segmono_boot.ttf http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/Fonts/segmono_boot.ttf segmono_boot.ttf
initrd --name segoe_slboot.ttf http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/Fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd --name segoen_slboot.ttf http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/Fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd --name wgl4_boot.ttf http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/Fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd --name BCD http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/BCD BCD
initrd --name boot.sdi http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/boot.sdi boot.sdi
initrd --name boot.wim http://${fog-ip}/fog/os/win/winpe/amd64/media/sources/boot.wim boot.wim
boot || goto MENU

Had to add the 4 lines for fonts and now it boots in UEFI. I am amazed this was the issue and only on this machine. The fonts btw where in the locations, so its not like moving them into tftpboot was a problem. It was explicitly placing the initrd lines for the fonts in the ipxe entry that made it work…go figure.

@george1421 Hey, re: our pm’s with winpe and UEFI, I am still having trouble. Let me know if you would rather I create a new post for my issue or if its ok to carry on here.

kernel http://${fog-ip}/fog/os/win/wimboot gui
initrd --name BCD http://${fog-ip}/fog/os/win/winpe/am64/media/Boot/BCD BCD
initrd --name boot.sdi http://${fog-ip}/fog/os/win/winpe/amd64/media/Boot/boot.sdi boot.sdi
initrd --name boot.wim http://${fog-ip}/fog/os/win/winpe/amd64/media/sources/boot.wim boot.wim
boot || goto MENU

It loads the files, has about a dozen lines about patching the WIM file, says its loading ‘bootx64.efi’ and then just reboots (machine makes a single beep). It never gets to loading the winpe environment. BIOS it boots fine and moves on to winpe.

I tried with/without:

• ‘gui’ (on the kernel line)
• ‘pause’ (on kernel line)
• ‘rawbcd’ (on gui line)

None of the above changed anything. I also rebuilt my winpe files using copype amd64 /path and still had same issue. When re-creating (using copype) I didnt even bother adding the commands to connect to network and run installer.

I have seen others add 4 lines for fonts, I am going to give that a shot too. I also am searching for another viable test box to ensure its not just the specific hardware I am using.

I am running copype on a Windows Server 2016 box with newest MDT and ADK. wimboot is latest, 2.6.0 I think (on FOG machine).

Any help would be awesome, Thanks!

EDIT: ok must be something about the Dell Precision Tower 3620. UEFI boot worked on an R620. I even added the latest Dell Winpe 10 drivers to the boot.wim and still get the crash when UEFI booting. Still could use a solution, but it may end up just being that this specific model is allergic to ipxe/winpe

@tom-elliott jst realized I shouldnt do math this late at night…you could just do dot decimal for type/order instead of 10^#.

IE:

type.order:

ex: (type item - item order)
type D item A - 3 = 1 . 3 = 1.3
type D item B - 2 = 1 . 2 = 1.2
type D item C - 1 = 1 . 1 = 1.1

type C item A - 3 = 2 . 3 = 2.3
type C item B - 2 = 2 . 2 = 2.2
type C item C - 1 = 2 . 1 = 2.1

would allow ordering with type weighted, and likely be easier to code and store in variables than 10^

@tom-elliott Numeric seems the best option. I was trying to artificially accomplish this in my menus by naming them (which works in the list of menus in the web GUI but not in the iPXE menus):

a1.name
a2.name
a3.name
etc.

I would think a drop down with used numbers eliminated would be the ideal approach (IE: drop down has 1-50 in it, if 1-3 are already used drop down only shows 4-50). lowest number is at top of menu, highest number at bottom. Skipped numbers ignored.

In this fashion you could order menu entries and account for the “include with” as well.

ex:
entry A - include with unknown - 1
entry B - include with known - 2
entry C - include with known - 3
entry D - include with unknown - 4
entry E - include with known - 5
entry F - include with unknown - 6

So I boot an unknown host and entries A, D, F show in order 1, 4, 6. I boot known host and entries show in order 2, 3, 5. All hosts show 1-6.

I of course realize with that, you’ll eventually get someone who wants different orders per type lol…

EDIT: As an extra thought, you could add weight to type: (order for type if you will).

Ex (type-order):
type A - 4
type B - 3
type C - 2
type D - 1

So then each has its weight 10^#.

Type D is 10^1, so each ordered item is: item order * type order. Ex: Type D (10^1) = 10, plus the item order

ex: (type item - item order)
type D item A - 3 = 10^1 + 3 = 13
type D item B - 2 = 10^1 + 2 = 12
type D item C - 1 = 10^1 + 1 = 11

type C item A - 3 = 10^2 + 3 = 103
type C item B - 2 = 10^2 + 2 = 102
type C item C - 1 = 10^2 + 1 = 101

thus if show all types (in numeric item order):
type D item C - 1 = 10^1 + 1 = 11
type D item B - 2 = 10^1 + 2 = 12
type D item A - 3 = 10^1 + 3 = 13
type C item C - 1 = 10^2 + 1 = 101
type C item B - 2 = 10^2 + 2 = 102
type C item A - 3 = 10^2 + 3 = 103

Thus you have control over order within a type and order when types overlap. 10^# is one trick, but likely becomes burdensome after about 10-20 groups. You dont have to start at 10^1 like I did, you could start with .00001 through 10^5 (10 types) for example. There may be better programatic ways to handle it, just some brainstorming.

@wayne-workman I get that each feature request needs to be evaluated to see if its worth while. I truly have no concept of what it would take to allow re-ordering the menus but I can not imagine it would, by comparison to other aspects of FOG, be that complicated.

Lets say it takes 1 second for me to “just change the selection” and I am conservatively doing it only 1 time a day and only 300 days in the year. Thats 5 minutes of time spent just switching selection. Lets presume arbitrarily that 1,000 other Foreman users do the same thing. That 5,000 minutes a year spent “just switching” to the desired menu item, or in other words 83.33 hours a year spent doing something that may otherwise be altered to improve usability.

Just looking at the boot.php (and again not being a programmer myself) the new entries are not placed at the beginning nor appended to the end of the file, which leads me to believe there is already code determining its placement within the overall boot.php. It may of course be much more simple than defining order by the user…but something has to tell it my 6th entry goes after my 5th entry. If “something” is doing that, the mechanism is already there to set the placement in the menu, it would just be a matter of changing the “something” to a user.

@wayne-workman Its more an issue of having to skip 4-5 options at the top that I dont want to disable because I may need them sometimes to get to the next 4-5 option I created and will use regularly. If it was just 1 item I needed to use always, default would be the ticket.

So I made entries for installing CentOS 7.4, 7.5, ESXi 6.5, 6.7, Windows 7 and Windows 10. I have to skip over memtest (which I could need someday but not every time I boot), host registration x2 and image deployment to get to my options which I will use more frequently. I dont want to disable those 4 options as I will use them, just not as often as the entries I made myself.

What was it that you had done in 1.2.0? Maybe it can be altered to work in the latest versions?

I too am very interested in this as the options I will use the most, and thus want at the top of the list/menu, are the ones I have created.

I have a feeling the only way to accomplish this is by messing with the php files that dynamically create the menu, which I am not really comfortable with.

@george1421 @martinetwork I believe you can also use the following as a guide: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

I have done this a dozen times in the last few weeks with no issues.

Essentially let http and other services through firewall (no need to disable it) and you can use the command:

setenforce 0

to temporarily disable SELinux. Its up to you at that point if you follow the guide and permanently set it to permissive or if you take the time to set the SELinux contexts required for it to all work.

Hope this helps

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

@george1421 Very cool.

My png weighs in at a hefty 9kb lol. I will have to check the depth. Also I noticed in the boot.php that the console line does not include a statement for the depth (which may be fine).

The documentation here is unclear on the matter

The width, height, and colour depth are specified as minimum requirements; the actual values used may be higher than specified. If a background picture is used then the width and height may be omitted; the console size will then be chosen based on the size of the background picture.

So above I get that without a picture width, height and depth should be used? They then say that with a background width and height can be omitted, but do not say the same for depth.

Beyond that, they also say that the resolution should adjust to the size of the background image, leading me to believe if you had a 1024x768 background it should adjust to that resolution without specifying it on the console line which is good.

I am however wondering if adding the --depth parameter may correct the issues with the background on UEFI?

FOG version: 1.5.2

As I have been learning and using FOG I realized some options can only be used when the host has been booted BIOS or UEFI. For example, the included Memtest86+ can only run when the host was BIOS booted. Trying the menu option when UEFI booted results in errors. Alternatively, as per this post here, ESXi would only be supported out of the box when UEFI booted. I am sure there are many other examples of this.

It may also be that the parameters under BIOS and UEFI are just different. In other words the OS/Installer can run under either, but requires different parameters.

What I have found is its possible to use a single iPXE menu entry to cover using different parameters depending on how the host was booted. This is all done via the web GUI under Settings | iPXE Menu Item Settings (or for new entries ‘iPXE New Menu Entry’.

I altered the default fog.memtest entry, parameters field for example to the following:

iseq ${platform} pcbios && goto mem_bios || goto no_mem
:mem_bios
kernel memdisk initrd=memtest.bin iso raw
initrd memtest.bin
boot || goto MENU
:no_mem
prompt --timeout 30000 Host must be BIOS (not UEFI) booted for this option. Press any key to return to the menu... && goto MENU || goto MENU

The first line tests if the host was BIOS booted, if so it jumps to the ‘mem_bios’ label and executes the commands under that label, otherwise it goes to the ‘no_mem’ label and instead displays a prompt explaining why its not an option and then returning to the menu thus avoiding the error.

This results in 1 menu entry that changes behavior based on how the host was booted. I might even go as far as including in my entry descriptions some syntax/indicator of its compatibility, IE: “Memtest86+ (BIOS only)” so that its obvious to users without selecting it that it can only be used when BIOS booted.

Another example is my ESXi entry:

iseq ${platform} efi && goto esxi_efi || goto esxi_bios
:esxi_efi
kernel http://${fog-ip}/fog/os/esxi65/efi/boot/bootx64.efi -c http://${fog-ip}/fog/os/esxi65/efi/boot/boot.cfg
boot || goto MENU
:esxi_bios
prompt --timeout 30000 Host must be UEFI booted for this option. Press any key to return to the menu... && goto MENU || goto MENU

Similar to the above but the 1st line does the reverse test, is the host UEFI booted. The ‘:esxi_bios’ label and its commands could be altered as seen below if, for example, you compiled the ipxe kernel to include IMG_COMBOOT to support BIOS booting ESXi:

iseq ${platform} efi && goto esxi_efi || goto esxi_bios
:esxi_efi
kernel http://${fog-ip}/fog/os/esxi65/efi/boot/bootx64.efi -c http://${fog-ip}/fog/os/esxi65/efi/boot/boot.cfg
boot || goto MENU
:esxi_bios
kernel http://${fog-ip}/fog/os/esxi65/mboot.c32 -c http://${fog-ip}/fog/os/esxi65/boot.cfg
boot || goto MENU

In the above, we load ESXi one way if the host is UEFI booted and another if it was BIOS booted.
[Moderators Note]: I want to restate again that the mboot.c32 syslinux script will not boot using FOG Project supplied iPXE boot loaders (i.e. undionly.kpxe) since they are not complied by default with COM_BOOT enabled. YOU must compile the iPXE boot loader if you want syslinux support -Geo

---

I have so far only tried this with memtest and ESXi.

I also would love to see an option for a menu to be displayed or not based on this variable, IE: show the memtest86+ entry only when BIOS booted but not when UEFI booted, but have not found a way this is possible yet. Maybe the devs have some ideas as to if this is feasible?

I think that could really help make the menus a bit more flexible/dynamic. It could potentially be a set of check-boxes in the GUI for the menu entry: “BIOS”, “UEFI” or “Both” which would dictate if the menu entry is included for a host given how it was booted. Alternatively, maybe somehow tied into the ‘Menu Show With’ option.

In any case hopefully others find this useful.

@george1421 Ok, I am with you now.

Anyway you know of for me to include the png but prevent the crash when booting UEFI on some clients?

@george1421 are you saying then that @Tom-Elliott is incorrect in his statement or have I misunderstood what he said?

If it is actually down to the UEFI device, is there a way to include the background image so that it displays on capable systems but does not crash system which cannot display it?

After reading iPXE documentation it appears only png is supported (2 other file types for images I never heard of, not the typical jpg, bmp, etc), so I created an 800x600 version of my background as png (instead of 1024x768) and iPXE still crashes when it gets to the line loading the png. Computer makes a single beep and reboots.

I have been using a relatively new/modern Dell Precision T3620, updated to latest firmware. The server grade machines I will need to deploy to are generally ~5 years old or newer (in terms of when the parts in them came out, not the age of the machine itself).

What I have found so far is any attempt to add an image causes UEFI booting to crash, but I havent tried any other machines yet.

@tom-elliott said in Get iPXE Menus to Resemble Old Syslinux PXE Menus?:

ipxe efi doesn’t currently support background images.

@Tom-Elliott Am I following correctly that this is a limitation of iPXE and not FOG then?

To re-state it and make sure I am following along:

iPXE itself does not support background images when booting UEFI?

If so, I have been unable to find any mention of this limitation anywhere else (not that I dont believe you, but was hoping to be able to track progress on the issue). Is it a known issue as far as the iPXE folks are concerned?

I tried to register for the iPXE forums yesterday to ask them some questions but their registrations reCapture is broken, so I cant register. I emailed them and havent heard back regarding registration yet.

In any case its a bit disappointing if iPXE indeed is limited to no background image under UEFI

@tom-elliott Yea I am ok keeping it a flat menu structure, but right now my 2 big issues are:

1. UEFI and BIOS menus looking different (especially in size)
2. I am unclear on the correlation between the menu color fields and what they actually set in the Web GUI. The documentation on the matter has not clearly defined for me what the syntax of the fields means.

Hey All,

FOG 1.5.2
CentOS 7.4.1708
Acting as DHCP, TFTP, iPXE, etc.
Seperate DNS server

I have testing workstation booting and displaying menus both BIOS and UEFI booted. My question/problem is 2 part:

1. Is it possible to get the FOG iPXE menus via BIOS and UEFI to have the same appearance/style?
2. Is it possible to replicate the appearance/style of my old Syslinux based PXE menus?

Re #1:
As of now, the UEFI menu is much smaller then the same menu displayed BIOS booted. It also will not boot using the default background image under UEFI. If I clear the field for background it boots UEFI, otherwise it just boot loops.

Basically the BIOS menu is sized pretty large, taking up mostly the whole screen which is good, making it easy to read. The UEFI menu is about 1/4 of the screen and very hard to read. Id like to get them to both appear similar in terms of size/placement.

Re #2:
I had prior a manual install of tftp/dhcp/etc and using Syslinux (vesamenu.c32) under BIOS and UEFI had a very nice menu setup. Sub-menus, appearance exactly the same under either boot. I am not stuck on having submenus, but the theme/background would be ideal.

Here is an excerpt from “pxe.conf”, which is the theme file that passes all the appearance parameters to the menus:

MENU TITLE ---=== My Lab PXE Server ===---
MENU RESOLUTION 1024 768
NOESCAPE 1
ALLOWOPTIONS 1
# PROMPT 0
# MENU WIDTH 120
# MENU ROWS 16
# MENU TABMSGROW 26
# MENU MARGIN 10
# MENU HELPMSGROW 22
# MENU TIMEOUTROW 24
# MENU BACKGROUND 40;40 #00000000 #00000000 none
MENU BACKGROUND pxelinux.cfg/pxe.jpg
MENU COLOR sel 7;36;40 #ff0077c8 #ffffffff none

I am having a bit of a hard time finding out what parameters to change in FOG to get the same colors I had (black background, white text un-selected, particular shade of blue for title and selected text (with selection having white background). The pxe.jpg is 1024x768, mostly black with a logo at the bottom right. I tried this previously in FOG and it wasnt loaded, seemed like it was ignored. Never figured out if it was a format issue, resolution issue or FOG issue.

In any case any help would be appreciated. Thanks