Surface Pro 4 won't get to registration menu

[sarge_212]

@Tom-Elliott Ok. I have no idea why image uploads are failing for a colleague of mine. I’ll to have research and see what he’s doing. Thanks for all your help.

[Tom Elliott]

Do you know if there’s an Error message with it?

This seems, to me, to look potentially like a slightly previous build. But I’m fairly sure this has since been corrected, though I do need to test to sure.

[sarge_212]

@Tom-Elliott Yes, there is actually an error message. Well, at first we got the image to push to the FOG 1.2.0 server. Then, we tried to deploy the image. On boot, there is an error stating that winload.exe can’t be found. After that, trying to push the win10 image to the server won’t work at all. Though pushing deployments seem to work fine. Also, in conjunction with this, the surface starting pushing to the server but I killed that push as I didn’t have an extra 250G space. That is tomorrow’s project, getting the surface (whole 254G) to push to a storage node that has enough space.

[Tom Elliott]

Also,

If I recall correctly (yeah I know i could re-read as needed), you’re still in 1.2.0 correct? If this is the case, the likely reason of the other image failing to upload (for resize at least – are you sure MPS ( Single disk) isn’t working? MPA (All disk) and MPS use more or less the same code base, with MPA only varying by iterating the all the disks.

The resizable fails as resize in 1.2.0 only allows a max partition count of 3. Windows 10, default install does 4 partitions.

[Sebastian Roth]

@Tom-Elliott @sarge_212 Reading through most of the posts here again I saw that I’ve kind of lost track where we are with this right now. So I try to recall things. Please correct me where needed!

We started off with trying to boot and capture a Surface 4 on FOG 1.2.0. Updating iPXE files in /tftpboot and the kernel (via web interface from 3.19.3 to 4.1.2) got the kernel booting but failed with the well known kernel panic “Unable to mount root fs on unknown-block(1,0)”. After a lot of forth and back trying to boot the kernel from USB and things like that it turned out (at least from my point of view) that we were only missing the kernel parameters init=/sbin/init initrd=init.xz. Wonder if they were lost when editing the boot menu php file or if FOG 1.2.0 is missing those?

Somewhere along the way the OP also updated kernel and init files by hand (wget) and should be using fairly new (maybe 4.3.0) files right now. So web interface is still 1.2.0 but kernel and init are pretty much trunk - but not the very latest.

@sarge_212 You might want to update those kernel and init files to the very latest version because Tom has fixed a couple of things in the time since you last updated.

cd /var/www/fog/service/ipxe
mkdir bak2
mv bzImage* init*.xz *.sha512 bak2
wget -O kernels.sha512 https://fogproject.org/kernels/index.php
wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32
sha512sum -c kernels.sha512
wget -O inits.sha512 https://fogproject.org/inits/index.php
wget https://fogproject.org/inits/init.xz
wget https://fogproject.org/inits/init_32.xz
sha512sum -c inits.sha512

[Tom Elliott]

@Sebastian-Roth He is, to my knowledge, using the original 1.2.0 init’s. He has tried using the more recent versions of the init’s, but there is a lot of changes and I’m not 100% sure that it would work on 1.2.0. The init=/sbin/init and initrd=init.xz parameters were only introduced (granted a while ago for us) in the trunk versions and was not present in any regard on 1.2.0. This can be relatively easily fixed though but would required editing the db taskTypes table to add that for each task type as well as editing the boot menu options to correct for it.

It’s because of this, however, that resize uploads are failing on Windows 10. 1.2.0 still used the assumptive code and only allowed an upload of a 3 partition layout. 4 partitions was not a viable option during that layout style.

[sarge_212]

@Tom-Elliott I’ll try updating the kernel and inits via wget today and see where that gets me. You are correct in your assumptions of where we are at.

[sarge_212]

@Tom-Elliott Here is the output from the surface on trunk:

(sorry about the glare!)

Also, we’re testing this on a desktop too, and it seems to be working…eg its on the step of saving original partition table and its been there a few minutes.

[Sebastian Roth]

You mean a full FOG trunk install or just the init’s being updated to the latest? Really confusing anyway. I think I’ve seen this in the last days already but why would the newer kernel not recognize your NIC??

[Tom Elliott]

@Sebastian-Roth I am trying to see the same thing. This is a separate and FULL fog server \0/. At any rate, I don’t know, yet, if it’s kernel doesn’t recognize the nic, or if it’s related to the nic being usb.

[sarge_212]

@Tom-Elliott Hey Tom, good morning! I tried to do the debug push to the surface and it is not able to grab that. I’ll try today on the USB-ethernet adapter. Thanks!

[sarge_212]

@Tom-Elliott So, we had to order some USB -ethernet adapters. We’re waiting on those. On the USB dock, I get this when trying to do debug push:

Is this something with the inits? Let me know, thanks!

[Tom Elliott]

@sarge_212 Don’t use Advanced -> Debug to do a debug task.

Schedule your task like you normally would, but before confirming check the “Schedule as debug” checkbox.

[sarge_212]

@Tom-Elliott Okay, I’m in debug mode. What information will help? I’m using the USB dock. I did an ip addr show and on eth0 I’m not seeing inet address.

[george1421]

@sarge_212 said:

@Tom-Elliott Okay, I’m in debug mode. What information will help? I’m using the USB dock. I did an ip addr show and on eth0 I’m not seeing inet address.

I’ve been kind of loosely following this thread. So you are booted into debug mode. How many ethernet adapters do you see when you do an ip link show?

Do you have the usb ethernet adapter installed?

Do you only see eth0 and can you confirm by the mac address this is the usb ethernet adapter or is this the wifi ethernet adapter?

[sarge_212]

@george1421 This is the Surface USB dock I’m using right now as I am waiting for some usb ethernet adapters from amazon. My old one broke… The eth0 is the usb one, that is the one that I’ve registered in the webGUI. I’ll have to see if its any different once those usb adapters get in.

[Wayne Workman]

@sarge_212 Please keep us informed on exactly the USB adapter vendor and model and version number. This is important stuff and we don’t have enough info about it.

[sarge_212]

@Wayne-Workman Thanks Wayne. We just ordered an Amazon Basics Ethernet 2.0 USB adapter, the one found here:

http://www.amazon.com/AmazonBasics-USB-Ethernet-Network-Adapter/dp/B00M77HLII/ref=sr_1_4?ie=UTF8&qid=1455902388&sr=8-4&keywords=ethernet+usb+2.0+adapter

It works in the OS, just not when trying to PXE boot. The interesting thing is, the Surface dock, when connected via that, I do get it to PXE boot.

[george1421]

@sarge_212 said:

It works in the OS, just not when trying to PXE boot. The interesting thing is, the Surface dock, when connected via that, I do get it to PXE boot.

I’ve been loosely following this thread, so this may have already been answered, but why not just add the surface dock nic to the FOG kernel?

If the usb nic you are purchasing does not work for pxe booting, but does work in FOS, then you can just usb boot the surface into the fog menu. (It would sound logical to $Donate$ to the FOG project and request that the nic for the surface pro 4 be added to the list of supported devices. That way you won’t have to mess with it as you add to your fleet of systems.

[Tom Elliott]

@george1421 The NIC is already in the kernel, and I suspect the same for all of the nic’s that have been tested.

However, i think it’s the has_usb_nic thing that needs to be retested to see if we can get things working again.