Posts made by Psycholiquid

EFI 01 Timer Test:

but I have the hsa_usb_nic=1 still on

EFI timer test:

Surface Test with USB NIC and using file 04_ipxe.efi I get the following:

It will get to the menu without issue. I am choosing the last option to Compatibility to see it hit the init file and the following happens:

Works without issue, eth0 doesn’t pick up on DHCP but secondary USB NIC does and works to image or register hosts.

Surface Test with no USB NIC and using file 05_ipxe.efi I get the following:

It will get to the menu without issue. I am choosing the last option to Compatibility to see it hit the init file and the following happens:

Never gets past init.xz

@sebastian-roth said in Microsoft Surface Pro 4:

@Psycholiquid If you are keen enough we might even figure out that issue as well and get rid of that need to unplug/replug USB NICs as well. But let’s focus on the iPXE issue first. Thanks for testing!

No problem Its what I do LOL

@sebastian-roth said in Microsoft Surface Pro 4:

@Psycholiquid Please add the has_usb_nic=1 parameter (either in the host’s settings if it is registered already or in the general settings page (you’d see this for all hosts then). On boot it should prompt you to remove and replug the USB NIC. Then DHCP should work.

By the way: Which version of FOG do you have? Tom has added the feature to recognize clients by sysuuid rather than MAC address. See here. AFAIK this should work in FOG 1.4.4

Surface Test 1 with no USB NIC and using file 04_ipxe.efi I get the following:

It will get to the menu without issue. I am choosing the last option to Compatibility to see it hit the init file and the following happens:

So all in all it works but again you have to run arond unplugging and replugging docks or USB NICs (Docks in the case of Surfaces/

@sebastian-roth said in Microsoft Surface Pro 4:

@Psycholiquid Please add the has_usb_nic=1 parameter (either in the host’s settings if it is registered already or in the general settings page (you’d see this for all hosts then). On boot it should prompt you to remove and replug the USB NIC. Then DHCP should work.

By the way: Which version of FOG do you have? Tom has added the feature to recognize clients by sysuuid rather than MAC address. See here. AFAIK this should work in FOG 1.4.4

I am on 1.5.0 RC7. Trying the has_usb_nic=1 now that has worked in the past but I opted for the USB nic that just works in using in a lab environment it is a pain to go around unplugging and plugging back in. But I will do it for you anyway and come back with results.

Surface Test 2 with now USB NIC and using file 05_ipxe.efi I get the following:

It will get to the menu without issue. I am choosing the last option to Compatibility to see it hit the init file and the following happens:


@sebastian-roth said in Microsoft Surface Pro 4:

Thanks heaps for reporting back on this…

@psycholiquid said in Microsoft Surface Pro 4:

I am using ipxe7156.efi

Yes we still have those old binaries around as we couldn’t figure out what’s wrong with the newer iPXE versions. I beg you to help us finding what’s wrong and finally get rid of those ugly extra binaries!!

Please take 15 minutes (I am pretty sure it shouldn’t take any longer) to test a couple of binaries for us as we devs don’t have those devices to test with. Find the files to test here. Please try out 04_ipxe.efi (should work) and 05_ipxe.efi (should have an issue, hanging on init.xz) and report back. Then if you have another 20 minutes, please also test the binaries called svnXXXX_ipxe.efi and let me know which ones work and which don’t.

Surface Test 1 with now USB NIC and using file 04_ipxe.efi I get hte follwing:

It will get to the menu without issue. I am choosing the last option to Compatibility to see it hit the init file and the following happens:

So here is the whole snoop to see if we can glean some info out of it.

Surface:

Frame 1510: 401 bytes on wire (3208 bits), 401 bytes captured (3208 bits) on interface 0
Ethernet II, Src: Cisco_5e:53:17 (00:a3:8e:5e:53:17), Dst: Vmware_bb:44:5b (00:50:56:bb:44:5b)
Internet Protocol Version 4, Src: 10.20.42.3, Dst: 10.20.60.8
User Datagram Protocol, Src Port: 67, Dst Port: 67
Bootstrap Protocol (Request)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 1
    Transaction ID: 0x3697a7aa
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 10.20.42.3
    Client MAC address: Microsof_f5:44:71 (bc:83:85:f5:44:71)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Request)
        Length: 1
        DHCP: Request (3)
    Option: (54) DHCP Server Identifier
        Length: 4
        DHCP Server Identifier: 10.20.60.22
    Option: (50) Requested IP Address
        Length: 4
        Requested IP Address: 10.20.42.134
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 65280
    Option: (55) Parameter Request List
        Length: 35
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (2) Time Offset
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (4) Time Server
        Parameter Request List Item: (5) Name Server
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (12) Host Name
        Parameter Request List Item: (13) Boot File Size
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (17) Root Path
        Parameter Request List Item: (18) Extensions Path
        Parameter Request List Item: (22) Maximum Datagram Reassembly Size
        Parameter Request List Item: (23) Default IP Time-to-Live
        Parameter Request List Item: (28) Broadcast Address
        Parameter Request List Item: (40) Network Information Service Domain
        Parameter Request List Item: (41) Network Information Service Servers
        Parameter Request List Item: (42) Network Time Protocol Servers
        Parameter Request List Item: (43) Vendor-Specific Information
        Parameter Request List Item: (50) Requested IP Address
        Parameter Request List Item: (51) IP Address Lease Time
        Parameter Request List Item: (54) DHCP Server Identifier
        Parameter Request List Item: (58) Renewal Time Value
        Parameter Request List Item: (59) Rebinding Time Value
        Parameter Request List Item: (60) Vendor class identifier
        Parameter Request List Item: (66) TFTP Server Name
        Parameter Request List Item: (67) Bootfile name
        Parameter Request List Item: (97) UUID/GUID-based Client Identifier
        Parameter Request List Item: (128) DOCSIS full security server IP [TODO]
        Parameter Request List Item: (129) PXE - undefined (vendor specific)
        Parameter Request List Item: (130) PXE - undefined (vendor specific)
        Parameter Request List Item: (131) PXE - undefined (vendor specific)
        Parameter Request List Item: (132) PXE - undefined (vendor specific)
        Parameter Request List Item: (133) PXE - undefined (vendor specific)
        Parameter Request List Item: (134) PXE - undefined (vendor specific)
        Parameter Request List Item: (135) PXE - undefined (vendor specific)
    Option: (97) UUID/GUID-based Client Identifier
        Length: 17
        Client Identifier (UUID): c3d3c87f-5bab-fb24-5f25-d0fb46014244
    Option: (94) Client Network Device Interface
        Length: 3
        Major Version: 3
        Minor Version: 16
    Option: (93) Client System Architecture
        Length: 2
        Client System Architecture: EFI BC (7)
    Option: (60) Vendor class identifier
        Length: 32
        Vendor class identifier: PXEClient:Arch:00007:UNDI:003016
    Option: (255) End
        Option End: 255

WEll snooping two different Surfaces I was able to get the following information"

Surface one UUID = 598FDD98-C837-7A56-48E6-130AE625101C

Surface two UUID = C3D3C87F-5BAB-FB24-5F25-D0FB46014244

So it doesn’t look like we can use that as a Condition. Not real sure what they are doing there but it looks totally different and could just be built off of a few factors of the hardware to generate that UUID.

@Wayne-Workman I didnt mean to convey it was wrong. I learned alot from the article. Just wanted to get it updated with more info. I think you did a great job when you wrote that as there was zero information I could find when I was working on the first UEFI stuff. You are the man!!!

@sebastian-roth said in Microsoft Surface Pro 4:

Thanks heaps for reporting back on this…

@psycholiquid said in Microsoft Surface Pro 4:

I am using ipxe7156.efi

Yes we still have those old binaries around as we couldn’t figure out what’s wrong with the newer iPXE versions. I beg you to help us finding what’s wrong and finally get rid of those ugly extra binaries!!

Please take 15 minutes (I am pretty sure it shouldn’t take any longer) to test a couple of binaries for as as we devs don’t have those devices to test with. Find the files to test here. Please try out 04_ipxe.efi (should work) and 05_ipxe.efi (should have an issue, hanging on init.xz) and report back. Then if you have another 20 minutes, please also test the binaries called svnXXXX_ipxe.efi and let me know which ones work and which don’t.

Yeah I can do that for ya, I have all sorts of fun toys to play with here. I am working on Vendor classes today so there is alot of rebooting going on. I will report back with results.

So the question is do you want me to try it with or without the extra USB NIC?

@george1421 said in BIOS and UEFI Coexistence HP 850 G3 i219v nic:

OK so now what I would do is see if you can identify the hardware by the uuid value? For example a surface pro 3 has a uuid of xxxx, pro 4 yyyy, hp (whatever) zzz. Once you have that, looking at the fog wiki page you should be able to create additional test conditions like with the arch 7, 9, whatever. And then combine them into a new policy like in step 6. That new policy may be arch7 and uuid xxxx == file name aaa (sorry about all of the abstractions but I don’t have a solid answer just yet). It seems logically like it should work.

Sounds like a plan I will work it out and post back with what I find out, with pictures!!! I love pictures. LOL

No snark taken, I get you I have the Wireshark snooping I just run it directly from the DHCP server to get a good baseline of what the clients are asking for.

The option 97 is a very good idea, so I could put equals variable “and” instead of “or” equals 97 answer.

Ill give this a try and see what I can come up with. I agree the Wiki is not persay wrong. I even tried multiple vendor-class-identifications and none with all the information worked even though M$ says they should. Go figured Windows lied (LOL)

But a second filter on the ARCH:00007 should help with that I would think.

Off how I miss the days of it just working. Damn you UEFI!!! But thank you for the idea and clearing that up. Not sure how to tackle the wording on the Wiki to better explain that. I can see someone trying it and getting confused. Please keep in mind I have Asperger Syndrome so I read things alot differently than most.

Here is an example of a Surface hitting the DHCP server while being snooped:

I also use no exit style it just works out of the box.

I know this is old but I have about 40 Surface Pro 4s I have to image once a quarter. This is my setup and it seems to work:

Surface Pro 4 on MS Dock. This boots to FOG without issue.

From menu I hit Register or it goes into the imaging process on its own.

From there the NIC on the dock stops working and I have a specific USB NIC I use:

https://www.startech.com/Networking-IO/usb-network-adapters/USB-2-to-Gigabit-Ethernet-NIC-Network-Adapter~USB21000S2

This is plugged in on the side at the same time as the dock is connected.

This NIC picks up and starts the image or registering the device.

I have to point out that I had to ignore this device in the FOG server settings so it wont show errors as multiple MAC addresses and cause issues here:

I haven’t had an issue since I went to this setup. and I am using ipxe7156.efi as my default efi in DHCP so it works for most of my workstations and Laptops. But the ARCH UEFI DHCP vendor class settings can be used also on ARCH:00007 so long as you don’t have other devices that can conflict. For instance the HP 850 G3 i210v network port.

I have run across an instance that the following does not apply or is now incorrect:

https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

The ARCH:00007 works with Surface Pro4 and now with the Intel i219v

I have tried the following to get around it but Windows is being a pain and not acepting such granular options:

Enter full vendor-class-identification as text or hex:

Example of Intel:

Option: (60) Vendor class identifier
Length: 32
Vendor class identifier: PXEClient:Arch:00007:UNDI:003010

Enter the above in the vendor class all the way to the UNDI just breaks it and the client defaults back to the default efi file in DHCP.

Example of Surface Pro4:

Option: (60) Vendor class identifier
Length: 32
Vendor class identifier: PXEClient:Arch:00007:UNDI:003016
or
0000 50 58 45 43 6c 69 65 6e 74 3a 41 72 63 68 3a 30 PXEClien t:Arch:0
0010 30 30 30 37 3a 55 4e 44 49 3a 30 30 33 30 31 36 0007:UND I:003016

Same result. Almost like Windows DHCP doesn’t allow such granular specifics on the Vendor Class Identification.

To get around this I have now set my default to ipxe7156.efi and added a vendor class for the i219v (HP 850 G3 Elitebook)and set that boot file to intel.efi. That seems to get around the issue. Problem being if something else comes along using ARCH:00007 that differs from both not sure what will happen then.

So in short I guess the wiki needs to be fixed (amended?) and looking for ideas on how to be more granular on the Vendor class. Stuck using DHCP form Windows for now, but for some reason I think Linux would probably handle this without a problem.

@Sebastian-Roth I would say yes, The network wasn’t down at all. I was able to ping and checked the Linux firewall to be sure it was disabled.

It started doing it again this morning. But everything works. So I will chalk it up to have a system that has been updated more times than I would like to think about unless you guys want to look into it further.

OK to freaking weird, it just showed back up out of no where.