Surface Pro 4 unable to image
-
Running Ubuntu 14.04, on trunk 7386.
Was able to image Surface Pro 3s and 4s on an older trunk version. Just got in a new Pro 4, tried to image and am unable to do so. I have manually created the host (we are using the certified Surface usb ethernet adapters which worked previously). Added the has_usb_nic=1 paramater to the host kernel arguments. Changed boot file to a variety of different ones (snp.efi, snponly.efi, and ipxe.efi). Can get to the PXE menu, select Quick Image, and I get the attached screenshot.
The keyboard become unresponsive. I’ve unplugged nic as stated and press Enter…nothing. Left USB nic plugged in, pressed Enter…nothing.
The keyboard works as I can use it in the PXE menu.
Ideas?
-
I obviously added the photo in the wrong place.
Th last sentence should be, “The keyboard works as I can use it in the PXE menu.”
-
@Scott-Adams said in Surface Pro 4 unable to image:
I obviously added the photo in the wrong place.
Th last sentence should be, “The keyboard works as I can use it in the PXE menu.”
fixed.
And, 7386 is way behind. Can you please update to the latest before we dig in?
-
Just my guess as to why the keyboard doesn’t work.
Your BIOS is not using USB Legacy models?
-
Ok. So, checking BIOS on “new” Surface Pro 4, there is no option for USB Legacy models or anything like that. I have turned off Secure Boot and TPM as we have done previously.
I have also updated to 7543.
Now, I can’t even get to the screen in my original post. It just goes to a black screen.
Now, after I select Quick Image and put in my username/password, the following screen shows up before going to the image selection screen.
It only sits on thet screen for just a second or two, but this was not there before the update to 7543.
-
I just recently used FOG to create a surface pro 4 image. My workaround was to use a port replicator/hub to have both an external USB keyboard and Ethernet adapter plugged into the surface. It seemed to recognize both. It isn’t a permanent solution but It is how I did it.
-
@fry_p Thanks for the response. I would just hate to have to buy yet something else in order to get the functionality back. Imaging functionality did work many trunks ago (can’t remember the version we were on when we originally imaged, but I did create a thread on that as well back then).
-
@Scott-Adams I think this is from ipxe, and doesn’t appear to be impacting. They must’ve added some better error output and checking as it’s likely failing due to the other net information not existing. It shouldn’t show this message, but for whatever reason it is.
-
Similar thread: https://forums.fogproject.org/topic/6515/surface-pro-4-won-t-get-to-registration-menu/157
If I remember right the solution was to use an external usb ethernet adapter and/or the surface docking station. But I find it strange that the older surface pro 4s worked, and the new one doesn’t. I guess the question is did FOG change so that the older surface pro 4 now no longer image or did the firmware get changed on the new surface pro 4 and that has caused imaging to fail.
-
Not hijacking, hope to be adding too.
Using snponly.efi & Surface Pro4 + pro4 docking station for LAN -
@ITCC Does the keyboard not work, or you’re just noticing it can’t detect an uplink/ip address on that particular NIC?
-
keyboard works.
I have gone through the fog login and selected something from the menu. (using keyboard to nav)
it’s when it drops out to complete the task, this comes up. -
just updated to SVN 7561 and now there is no output at this time.
I have set an upload job from the GUI and it gets to the
init.xz…OK -
@ITCC That is where I am at as well. Updated yesterday to SVN 7543. Seems to load the bzImage and init.xz, and then it just hangs. I am using the Microsoft Surface Ethernet USB adapter and have tried multiple .efi boot files. I’m going to try to get my hands on one our prior Surface Pro 4s and see what happens with it.
-
@Scott-Adams and @ITCC Can you both please crank up the log level and enable kernel debug messages (FOG Configuration -> FOG Settings -> expand all and search for ‘DEBUG’ or ‘LOG’)? Hope we can get some more output.
-
These are both USB Nics, but my question about keyboard working is if it works in the FOS environment.
These units, most assuredly, need the kernel arguments with
has_usb_nic=1
until we can figure out a proper fix. -
@Sebastian-Roth I have set the kernel debug and have tried to start another task. Now, where do I get the logs that will help you? I’ve looked under log viewer in FOG configuration, but am not seeing anything specific for this job.
-
@Tom-Elliott I manually entered the host and added the has_usb_nic=1 argument. That will indeed get rid of the DHCP error that @ITCC was getting. My original issue of the image not attempting to start is still present. I have set the kernel debug check mark under FOG Configuration and trying to get some logs to help, but am not seeing anything specific to this particular task under Log Viewer in the WebUI.
-
@Tom-Elliott I should also add that I had the argument there from the beginning, as this was the fix the last time I had a thread on the surface (about 3 months ago). I have also set this host to use the kernel we were using at the time to see if that would help, and it did not.
-
@Scott-Adams The KERNEL_DEBUG and CONSOLE LOG LEVEL stuff will only impact the information printed on the client machine. There will be NO logs as we don’t store that information on the server. First it would BOG the server down especially when dealing with many tasks. Second, it would be quite difficult to filter out which log to actually look at.
If you up the levels and enable the DEBUG option, the simplest method to get us info is to take a picture and upload that here.