I find the exaggerated shadows to slow down visual interpretation of the page.

Strangely:

git checkout hyperv-ipxetest1
error: Your local changes to the following files would be overwritten by checkout:
        packages/tftp/ipxe.efi
Please, commit your changes or stash them before you can switch branches.
Aborting

So I ran:

git checkout -- .

Which returned nothing but then I:

git checkout hyperv-ipxetest1
Branch hyperv-ipxetest1 set up to track remote branch hyperv-ipxetest1 from origin.
Switched to a new branch 'hyperv-ipxetest1'

and

git pull
Already up-to-date.

So I proceeded with installation and it reported:

Version: 9220986 Installer/Updater

iPXE.efi is now 356f … and it fails into a restart loop the same way.

I just recaptured those partimage images using partclone then deleted the old entries. Sorting still doesn’t sort.

The three items with “No valid data” in their “Captured” column are all PartImage captures from years back. They are not native to this box and were added manually by file copy and “Create New Image”.

Clicking once, twice, three times a lady, it makes no difference. It doesn’t sort ascending or descending.

As you can see in the video it didn’t sort, more of a rearrange. It “sorted” 2017, 2017, 2016, 2017, 2017, 2016 .

Here ya go. Image Sort by Creation on 1.4.0

It doesn’t sort by date.

Server

• FOG Version: 1.4.0
• OS: CentOS 7.3.1611

Client

• Service Version: n/a
• OS: n/a

Description

While on the Image Management page, selecting the column header `Capture’ re-arranges the list sorta, but doesn’t sort at all. I have 39 images.

Dropping ipxe.efi 2d79 onto a 1.4.0 install works happily.

That’ll do the job. I was hoping there would be a way to just download only the ipxe.efi files without the need to re-install the entire beasty. I’m sure there’s a way, but I don’t use GIT professionally.

RC-4 with fd6d1 works
RC-5 with 84d4 works
RC-6 to RC-9.2 with 2d79 works
… and there we go, the problem starts with RC-9.3 and ipxe.efi 17887 .

Where can I find a repository of the ipxe.efi that have been used in FOG?

This was working fine as late as May 5th with 1.4.0-RC4.

It is UEFI booting, downloading the NBP but the process is failing/restarting after the initialization of the second part at:

iPXE 1.0.0+ (a19ac) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS FTP HTTP HTTPS ISCSI NFS TFTP SRP VLAN AoE EFI Menu

This was working fine as late as May 5th with 1.4.0-RC4.

Server

• FOG Version: 1.4.0
• OS: CentOS 7.3.1611

Client

• Service Version: n/a
• OS: n/a

Description

I am unable to complete a network boot of a Hyper-V 2016 Generation 2 (UEFI) virtual machine. I have duplicated the problem with separate Hyper-V 2016 hosts and VMs.

I have tried kernels
4.11.0
4.10.10
4.10.9
4.10.1
4.9.11
4.9.4
4.9.1

The text of what happens.

PXE Network Boot using IPv4 ( ESC to cancel )
Performing DHCP Negotiation...
 Station IP address is 10.12.40.120
 Server IP address is 10.12.40.14
 NBP filename is ipxe.efi
 NBP filesize is 994048 Bytes
 Downloading NBP file...
 Successfully downloaded NBP file.
iPXE initialising devices...ok

iPXE 1.0.0+ (a19ac) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS FTP HTTP HTTPS ISCSI NFS TFTP SRP VLAN AoE EFI Menu

… then it immediately restarts the VM to begin again at:

PXE Network Boot using IPv4 ( ESC to cancel )

UEFI booting is working on physical, while LEGACY booting continues to work on everything.

VM UEFI booting was working on May 5th with 1.4.0-RC4.

Secondarily, while updating the kernels I generate the following errors in /var/log/httpd/error_log:

PHP Warning:  ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 492, referer: http://devfog/fog/management/index.php?node=about&sub=kernel&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMTEuMC42NA==&arch=64
PHP Warning:  ftp_rename(): RNFR command failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 769, referer: http://devfog/fog/management/index.php?node=about&sub=kernel&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMTEuMC42NA==&arch=64
PHP Warning:  ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 492, referer: http://devfog/fog/management/index.php?node=about&sub=kernel&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMTEuMC4zMg==&arch=32
PHP Warning:  ftp_rename(): RNFR command failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 769, referer: http://devfog/fog/management/index.php?node=about&sub=kernel&file=aHR0cHM6Ly9mb2dwcm9qZWN0Lm9yZy9rZXJuZWxzL0tlcm5lbC5Ub21FbGxpb3R0LjQuMTEuMC4zMg==&arch=32

< facepalm >

Oh geez … okay, ignore everything. There is no problem other than that the switch servicing that bench had been reprogrammed. The ports used had been set to the wrong vlan; a vlan serviced by a FOG server that didn’t have the intended accounts.

… oy

Nothing at all shows up in /var/log/httpd/error_log (CentOS) at the moment of the login failure … just checked it again and nothing populated.

From FOG Configuration > iPXE Menu Customization > fog.multijoin

Menu Item:

fog.multijoin

Description:

Join Multicast Session

Parameters:

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

Everything else ‘looks’ normal.

The purpose of using this multicast method is to bypass the need to register a machine. I have some 700 systems coming in that will require quick and dirty imaging.

We know this works on other fog servers; the question is why does this particular feature that involves authentication when joining a session fail to allow anyone but the one account to join a session on this server?

Server

• FOG Version: 1.4.0
• OS: CentOS 7.2.1511

Client

• Service Version: n/a
• OS: n/a

Description

This is a problem with just one FOG server. I cannot recreate the problem on another.

All created users except for the original `admin’ account on this one particular server cannot join a multicast session when manually initiated by the user during a network boot. The response after entering a user name and password is always, invalid login.

I have verified the client machine itself is not the problem.

I have deleted all additional user accounts then recreated them and still no go. Only the one remaining account can join a multicast session.

I tried length of password, length of username, alphabetical sorting differences of username;
ie: abmin, admin, testuser

1. network boot machine
2. Join Multicast Session
3. enter username and password
4. receive:

http...blahblahblah...\boot.php ok
Invalid login!

The problem presented itself while the server was running 1.4.0-RC14, so I updated it to 1.4.0 and the problem remained.

Simply deploying an individual image via unicast the credentials are fine.

Cool. Installing it post-fact was never an issue, it just felt curious that 7.0 wasn’t installed by default after the conversations about how much better it made things.

There were discussions a long while ago about the merits of using PHP 7.0 over the default 5.6 that is installed with FOG . Has any consideration been given to having the FOG installer installing 7.0 instead of 5.6?