Surface Pro 4 won't get to registration menu

[george1421]

@sarge_212 Just for clarity if you use this process to create a usb boot media https://forums.fogproject.org/topic/6532/usb-boot-target-device-into-fog-debug-os/19
AND your target is in efi mode AND you boot from the usb drive, the debug kernel will be in UEFI mode. That flash drive process will create a multi boot bios / uefi boot device. Now understand the only thing this will get you is the FOG debug kernel running on your surface. You can’t do anything but debug which is not very exciting or productive. The thought though is if you can boot into the debug kernel and confirm that you are picking up and IP address then we know the surface is a viable option once the devs can get past the chain loading bit. But I think they already proved that the surface pro 4 boots the kernel, (not sure if they checked for an IP address). This needs to happen over a usb ethernet adapter since wifi is not a possible solution for pxe booting.

[sarge_212]

@george1421 Cool. Give me just a few moments and I’ll boot the debug stick and let you know if I do have an IP. I thought I remembered getting one previously, but I’ll check now to just be sure. Thanks!

[sarge_212]

@sarge_212 It doesn’t look like its getting an IP from the DHCP server.

[george1421]

@sarge_212 OK so the debug kernel doesn’t have the network adapter available for the surface pro 4. If you do an ip addr show, does it show what ever would be eth0 or does it only show the loopback adapter? (The good thing is that it boots). Do you have a usb 2.0 ethernet adapter you could insert into the surface and then boot the debug kernel again?

[sarge_212]

@george1421 I do have a 2.0 USB ethernet adapter. I’ll try that next and see if I can get an IP. I am using the dock with it so hopefully that’ll boot the kernel debug usb stick while the ethernet USB adapter is in the surface’s single usb port. I’ll report when I have deets. Thanks!

[sarge_212]

@george1421 Success!! USB 2.0 adapter works, it gets an IP from the DHCP server! Awesome. I think the problem now is the chainloading bit. Let me know where you guys get, thanks!

[george1421]

@sarge_212 OK, first of all, please tell the make and model of the network adapter or no help for you!

Now where do you get the IP address, is this running the ipxe kernel or the fog client OS? If its the ipxe OS then you are good to go, if it is the fog client OS then, you are half the way there (but not the half we can fix right now).

If you can get the ipxe kernel to pull an IP address then we can create a ipxe usb boot flash drive (I don’t like the name of that one either). That will chain load into the FOG menu. I created one this morning and it worked to USB efi boot an e6420 (uefi but no uefi network boot) into the FOG menu.

[sarge_212]

@george1421 Make and model of network adapter is a Linksys 200M ver 2 USB to ethernet adapter.(just like this one: http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=1030257) How do I tell where I’m pulling the IP address from? I believe it is from the fog client OS. This is booting off the fog debug USB stick I’ve made earlier.

[george1421]

@sarge_212 when you boot off that usb stick, you will see a screen with a bunch of text. Press enter a few times until you get to a command prompt. Then key in ip addr show It should list the loopback adapter and eth0. If eth0 has an IP address appropriate for you network then the fog live boot OS (still searching for the best name) will work no problem on that device.

The next issue we need to manage is the hand off from ipxe (not a fog project product) to the fog live boot kernel you just proved boots on your device.

[sarge_212]

@george1421 ip addr show indicates the following:

1: lo loopback
2: eth0 <NO-CARRIER, BROADCAST,MULTICAST,UP> but doesn’t indicate an IP
3: eth1 gives information that I would think would be on eth0, such as an IP address on my network

So according to this and your response, I think the fog live boot OS (FLOS fog-live-oS, good name?) will work. So, where do we go from here?

[george1421]

@sarge_212 OK you are seeing two ethernet adapters, I will assume eth0 is the built in wireless adapter and eth1 is the add on adapter. So the FLOS (its growing on me) image is viable.

So now you have the same issue is another poster, the handoff between ipxe (not a fog project product) and the flos kernel is not happening correctly. Let me try something in my lab, I want to see if I can update/the ipxe kernel to get this handoff to work. You are still using FOG 1.2.0 (stable) right?

[sarge_212]

@george1421 Yep 1.2.0 stable with some mods though, eg playing with kernels and the like and I’ve pulled the /tftpboot directory from a recent trunk version but I don’t know how much of an effect that will have. At this point it all seems to be working normally, eg still imaging other hardware without issue.

[Sebastian Roth]

@george1421 said:

I will assume eth0 is the built in wireless adapter and eth1 is the add on adapter.

I don’t think this is the case as Tom does not add wireless drivers to the kernel AFAIK. So it’s a really good question what eth0 is. Can you please boot again and run the following commands:

ls -al /sys/class/net/eth0/device/driver/ | grep module
...
ls -al /sys/class/net/eth1/device/driver/ | grep module
...

This should at least show us which drivers are used for those devices and hopefully we then understand which is which.

[sarge_212]

@Sebastian-Roth do this in the FLOS usb? (the one debug Fog Live OS I created?)

[Tom Elliott]

@sarge_212 Maybe we could call it FLOGGER?

[george1421]

@sarge_212 Yes that command is a linux command so you need to boot into flos (flogger) and get to the command prompt. Then run the ls command that will display all files in that location and then just filter out the ones that have module

[Sebastian Roth]

@sarge_212 said:

do this in the FLOS usb? (the one debug Fog Live OS I created?)

Yes I’d say so.

[sarge_212]

@Sebastian-Roth I like flos better, no offense @Tom-Elliott. I’ll boot into that and get you all the output of those 2 commands. may come in cell phone selfie form, but hey, that’s okay, right?

[Sebastian Roth]

Yes, whichever you like. Picture is great because we see exactly what you have on screen!

[Tom Elliott]

@sarge_212 Aww man,

I was just thinking of a way to phrase it as an acronym and all.

Free Live Opensource Ghost/Ghosting environment replacement.