Posts made by Dahrell

Not a huge issue by any means, but there’s a small bug with the UI.

When the side menu is collapsed and you hover over “Storage Groups” the list items’ text run out of the containing div.

The first picture you posted showed on the Storage Group Activity that it had two active tasks as of the time of posting. Those tasks must have completed before you checked Active Tasks.

@tom-elliott No worries, just trying to contribute Thanks for the response! Hope things are working out for you.

Nope, orphaned or not it still spits out those PHP:warns in the error.log.

I cleaned the hostMAC table where there were no hostID in hosts that existed for a hmHostID which resolved the listings of null for Host Name but then I tried deleting again and no changes were made via “Select All -> Delete Selected”.

Hi,

I grabbed the working-1.6 branch and am running it through Ubuntu16.04 on Windows as a test environment for the team’s newest releases! I must say the UI looks amazing!

The issue I noticed tinkering with the new UI is that on the “Pending MACs” page (under the hosts dropdown menu on the side nav), when I attempted to select all and delete the entries it doesn’t reflect changes after postback.

After navigating away and back or just refreshing it reflects changes but shows the values for Hostname as null.

These might just be orphaned records that are causing issues but regardless, here is the last 5 lines in apache2 error.log after trying to delete the entries that had their hostname changed to null:

[Tue Jul 10 12:51:10.799229 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning:  ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs
[Tue Jul 10 12:51:14.147645 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning:  ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs
[Tue Jul 10 12:51:15.069292 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning:  ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs
[Tue Jul 10 12:51:16.442140 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning:  ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs
[Tue Jul 10 12:51:17.333016 2018] [php7:warn] [pid 600] [client 169.254.98.2:37676] PHP Warning:  ftp_close() expects parameter 1 to be resource, null given in /var/www/fog/lib/fog/fogftp.class.php on line 115, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs

Another interesting line amidst all the other warning lines is:

[Tue Jul 10 12:48:19.594482 2018] [php7:warn] [pid 552] [client 169.254.98.2:37584] PHP Warning:  gethostbyname(): Host name is too long, the limit is 255 characters in /var/www/fog/lib/fog/fogbase.class.php on line 2159, referer: http://169.254.98.2:8080/fog/management/index.php?node=host&sub=pendingMacs

My best guess is that if you navigate to cd /var/www/fog/management/ and don’t find an index.php file, there’s a chance that you didn’t run the installfog.sh script with the sudo permissions needed to write the files to the proper folders that the apache server needs to complete the request.

Verified today that it does indeed require the Microsoft Ethernet Adapter on Surface Pro 4 and that it works with a Kernel Argument of has_usb_nic = 1 and Host Kernel of bzImage version 4.13.4! You have to create a host in the FOG Web Interface with the MAC of the adapter. Make sure the dock is removed before booting. When it prompts to remove the usb and replug leave the adapter in. Do not remove and hit ENTER.

Thanks again for your help previously!

Yeah they’re forcing only Microsoft PXE devices on Surfaces.

https://docs.microsoft.com/en-us/surface/ethernet-adapters-and-surface-device-deployment

"Booting from the network (PXE boot) is only supported when you use an Ethernet adapter or docking station from Microsoft. To boot from the network, the chipset in the Ethernet adapter or dock must be detected and configured as a boot device in the firmware of the Surface device. Microsoft Ethernet adapters, such as the Surface Ethernet Adapter and the Surface Dock use a chipset that is compatible with the Surface firmware.

The following Ethernet devices are supported for network boot with Surface devices:

Surface USB to Ethernet adapter

Surface USB 3.0 Ethernet adapter

Surface Dock

Surface 3 Docking Station

Surface Pro 3 Docking Station

Docking Station for Surface Pro and Surface Pro 2

Third-party Ethernet adapters are also supported for network deployment, although they do not support PXE boot."

It still won’t get to PXE. I think any non-Microsoft USB peripherals or USB Bootable devices are being ignored on boot? Maybe the updated UEFI firmware has changed the behavior of what peripherals are usable at boot. Once I get to the section where it asks me to replug the generic USB adapter and I move the ethernet over to it, it works on 4.15.2. I tried Kernel Versions 4.10.1 and 4.10.10 with the dock and the adapter by itself but still no success.

Yeah I can test if using 4.10 for the dock will work as well.

Haha, well I will either tomorrow or later this week see if the Microsoft USB Adapter works by itself. If not, it’s not a huge issue to use the dock for PXE booting and then switching over to a generic USB Adapter when prompted to accomplish the imaging.

Thank you for all ya’lls effort and time!

I ran the command again to capture for ya’ll to see with just the dock. The strange thing is that, in order to test a usb-to-ethernet adapter I had the dock (with the ethernet plugged into it) and the usb adapter connected and booted to PXE then it attempted to grab IP from DHCP as expected and failed again. However when debug reached the command line for the init.xz I moved the ethernet to the usb adapter and ran udhcpc on eth1 thinking that eth1 was the usb adapter (eth1 has the MAC of the dock which originally didn’t work). Upon running the command it worked as if the dock was using the adapter to communicate to the DHCP properly! But on boot the usb adapter doesn’t even attempt to PXE boot and I’ve tried to Alternative boot and to change the boot order, both of which don’t work. >.<

THE SOLUTION, however, was to have the dock to boot to PXE and a USB adapter plugged in at boot. Then when prompted to replug the usb, unplug the dock completely, then replug the USB adapter, move the ethernet cable to the USB adapter, hit ENTER to proceed. This makes me curious if the Microsoft Certified adapter will PXE boot like the dock and grab from DHCP without a hitch. If so I’m sorry I wasted ya’lls time. Why Microsoft… just… why?..

After Running udhcpc eth1 with the USB Adapter

After Running udhcpc eth0 (no USB Adapter)

Blank Conversation After (no USB Adapter)

@Tom-Elliott @george1421 Thank you guys for your responses! We have repair center PCs using FOG constantly and they obtain IPs flawlessly and works as intended it just seems that Surfaces want to be the problem child. I’ve attempted pings to the FOG server itself with the manual setup of IP and to no avail. I haven’t tried WireShark with those particular filters though I will definitely get on that and have that to you soon!

Hi,

My configuration:
FOG: 1.5.0
Kernel: 4.15.2
SVN: 6078

The FOG server has been a great tool for our PCs! Unfortunately, when attempting to image a Windows Surface Pro 4 there is a failure to obtain an IP from the DHCP (Windows Server 2016). Any help is appreciated! I hate to bother ya’ll. It might require the actual ethernet adapter? If more information is necessary I’ll be happy to oblige.

• The Surface has Secure Boot and TPM disabled with network boot as the primary boot option.
• It is being networked via Microsoft’s offical Surface Pro Dock.
• It has booted to the Registration Menu and manages to register the machine (using the dock’s MAC).
• Has successfully made it back to the Menu with the correct name it registered with.
• Have updated Firmware for UEFI environment.
• Cold booting.
• Have captured DHCP conversation and no communication was even attempted.

Upon choosing to Redeploy, the system works fine but after reboot from choosing the image to redeploy with the Surface fails to communicate with the DHCP to get past verifyNetworkConnection in funcs.sh.

I’ve used a static IP ifconfig in debugging to satisfy the verifyNetworkConnection but it fails to checkin at that point. Below I’ve attached some images to give more details!

Physical Device Setup Visual

The Printout of the IP Retrieval Failure

The Error Printed After Attempting Deployment

Printouts of Attempts to DHCP an IP in Debug

Try adding the user you want to use the mv command with by first using:

sudo gpasswd -a <username> www-data

Where the <username> is replaced with the actual account name you want.
That may give it permissions to move files into folders owned by www-data.

Then do your mv command to move the file to the /var/www/fog/service/ipxe/ folder and run:

USE fog; UPDATE globalSettings SET settingValue = ‘<backgroundimgfile.png>’ WHERE (settingKey = ‘FOG_IPXE_BG_FILE’);

in the mysql prompt to update the file that is referenced for that setting.

Instead of deleting the MACs you could go into the management portal and enter the MAC address which should update the MAC address for that host.

If you still wish to do a deletion of the MAC addresses and you know the id of the host you’re trying to delete the MACs for then simply do:

sudo mysql
use fog;
delete from hostMAC where(hmHostID = theIDfortheHost);

Where theIDfortheHost is obviously the known ID. If you don’t know the hostID then do:

select hostID from hosts where(hostname = ‘theNameFortheHostMachine’);

This will grab the hostID to use for the deletion command.

You could simply create a group that has those specific snap-ins assigned to them and then modify the fog.man.reg or which ever file is being referenced for your registration process to take in a group id. Then pass that to your registration by changing the body of the full_reg function in the lib/reg-task/registration.class.php to update the host’s group. If your fog configuration doesn’t already make the tasks for pushing snap-ins then create some tasks using the host.class.php to queue up those in the same full_reg function at the end after you have created and saved the host.