Surface Pro 4 won't get to registration menu

[george1421]

@Sebastian-Roth I would think if you could get the camera in a fixed postiion and then only try to record the bottom half of the screen (sharply) then that may yield better results. I did see that my iPhone 5 has a slow motion mode (120 fps) that would allow more time to try to read the information before it scrolls off.

[sarge_212]

@Sebastian-Roth Yeah I have an iPhone 6 with the Slo Mo, think that might be of help ? The bigger problem is a fixed position. IF only we had a selfie stick in the office!

[Sebastian Roth]

Doesn’t need to be in a self standing position I reckon. Would be a lot better if you can arrange things so that your phone is “standing” on ground (table, books, …). That way the shaking is a lot less. Best if you can cramp it in between two books to make it stand by itself… you will figure it out I am sure.

[sarge_212]

@Sebastian-Roth Genius! Give me a few minutes here…

[sarge_212]

Sorry for the delay all. Here is the latest output from the bzImage_epk argument:

https://www.youtube.com/watch?v=fg2cWbnVPaI

[Sebastian Roth]

@sarge_212 Well done!! Readable and now I am pretty sure what’s wrong. Two important kernel parameters are missing: init=/sbin/init initrd=init.xz (can’t see them when kernel command line is printed at around 0:30 in the video)

I am not sure why but just for testing can you please add those to the kernel options for this host and try again??

[sarge_212]

I also tried with the bzImage_rb as described here:

https://forums.fogproject.org/topic/6525/pxe-boot-hp-x2-210-hybrid-tablet-windows-10-pro/114?page=1

and I am still getting a kernel panic. I noticed that Matthieu finally got it working and I’m wondering what is different, eg (bzImage, ipxe.efi maybe) @Sebastian-Roth if you could let me know I would greatly appreciate it! Thanks!

[Sebastian Roth]

@sarge_212 Your device is totally different than Mattieu’s! From what it seams his tablet has a UEFI firmware bug. I am pretty sure you don’t have that and in your case it’s just the kernel options. See my previous post!

[sarge_212]

@Sebastian-Roth Awesome, I’m trying now!

[sarge_212]

@Sebastian-Roth A couple of questions good sir. When I set the parameters for the image, is it a single disk or multiple disk with partitions, there are 4 or 5 options there. Also, I am using bzImage_rb, should I be using that? It got to the point of NFS mounting and then failed with NFS mount. The NFS service is running, so I’m not sure why it’s failing.

[Sebastian Roth]

@sarge_212 Sorry got to head for a train very soon now. Just a few hints. I’d try “single disk multiple partitions” (non resizable!) first. If that works you can try other image types as well. All those bzImage_* kernels on my google drive are mainly with added debug output and should not run any better on your Surface than Tom Elliott’s standard kernel AFAIK. So try whichever you like but I really hope that the default kernel should work as well. Just the missing kernel options/parameters seam to cause the problem I think. About NFS: Can you upload from other PCs? Maybe it’s a generel NFS problem you see. Search the forum and wiki on how to troubleshoot NFS errors!

[sarge_212]

@Sebastian-Roth Update: I can get the image to upload now, but only with the option multiple partition image - not resizable options. This however wants to push the whole thing up to the server. Is that how it is supposed to work? I suppose the name implies that, however I thought it would be less than the 254G image. I haven’t let it just cruise through and upload yet, but I’ll do that soon when I can get some more space for images on one of the nodes I’m using. Another question. Does anything change in between the upload and deploy? Eg if I upload a spanking new win10 image to the server, will it deploy that exact same image to a machine? Just wondering what changes after the deploy or if that is all changes made to the image. Thanks @Sebastian-Roth !

[Tom Elliott]

@sarge_212 The size of the image varies based on the actual USED data. What you see on the partclone screen (254G) is only the device size. That’s important in that if you want to put the image on a partition/disk that’s smaller than that, it will potentially cause issues.

I’d be more interested, however, in figuring out why you can’t upload as resizable or MPS imaging.

[sarge_212]

@Tom-Elliott I’m not sure as to that Tom. Should the win10 image be able to do any type of image upload, eg resizable or multiple paritions?

[Tom Elliott]

@sarge_212 yes.

[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