Surface Pro 4 won't get to registration menu
-
@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!
-
@Sebastian-Roth Awesome, I’m trying now!
-
@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.
-
@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!
-
@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 !
-
@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.
-
@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?
-
@sarge_212 yes.
-
@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.
-
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.
-
@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.
-
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.
-
@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 -
@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.
-
@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.
-
@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.
-
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??
-
@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.
-
@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!
-
@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!