Surface Pro 4 won't get to registration menu

Tom Elliott

@george1421 technically it won’t hurt anything but it will a bring back the old data structures and assumptions I’ve been working so hard to be rid of.

sarge_212

Thanks again @tom and @george1421 for your input(s). I will hold tight. Good news, I didn’t brick the Surface, just takes an incredibly long time to reboot!

Sebastian Roth

Looking forward to see if FOG can handle this device! We’ve made a lot of progress with those gadgets lately. You might end up setting up a FOG trunk at some point. But keep trying with ipxe and kernel binaries from trunk to see how far you get.

sarge_212

@Sebastian-Roth Can I use kernels from trunk with FOG 1.2.0? I didn’t think that was a good mix together, but at this point we’re open to that I think.

Tom Elliott

@sarge_212 Kernels can be used cross all versions of fog.

Only time to be concerned about kernels is the arch when dealing with old versions of FOG (e.g. FOG 0.32 and prior, in which you MUST use the 32 bit kernels).

sarge_212

Well that’s really nice. I’m testing now with new kernels and FOG 1.2.0, will update you all when that’s been done.

sarge_212

Tested with the new kernels from trunk FOG. This resulted in the same kernel panic on the surface. I’m open to any other suggestions.

george1421

@sarge_212 Just for clarity you are updating the bzImage as well as the inits at the same time?
[Edit] wait… do these kernels work on a regular computer and they are only blowing up on the surface? [/Edit]

sarge_212

@george1421 Yes. I downloaded and installed FOG trunk on a separate server. Copied the bzImage, bzImage32, init.xz, init_32.xz to the /var/www/html/service/ipxe folder. Kernels do work on regular computer, yes.

Sebastian Roth

@sarge_212 Do you still see the ‘cdc-ether…’ messages as well? This should not be the case if you are running the latest kernels!

Edit: Can you please show us what you see on your modded 1.2.0 server issuing this command: ls -al /var/www/html/service/ipxe/{bzImage,bzImage32,init.xz,init_32.xz}

sarge_212

@Sebastian-Roth Here is the output from the modded 1.2.0:

#  ls -al /var/www/html/fog/service/ipxe/{bzImage,bzImage32,init.xz,init_32.xz}
-rw-r--r--. 1 fog apache  6847456 Jan 21 15:20 /var/www/html/fog/service/ipxe/bzImage
-rw-r--r--. 1 fog apache  6759504 Jan 21 15:20 /var/www/html/fog/service/ipxe/bzImage32
-rw-r--r--. 1 fog apache 15448272 Jan 21 15:20 /var/www/html/fog/service/ipxe/init_32.xz
-rw-r--r--. 1 fog apache 16476332 Jan 21 15:20 /var/www/html/fog/service/ipxe/init.xzere

testing again to see if I still get the cdc first

george1421

@sarge_212 said:

@george1421 Kernels do work on regular computer, yes.

OK, great. I was afraid we broke you FOG server.

So the root of the issue is that the current kernels and inits are panicking the kernel. I’m wondering if these devices have a weird hard drive structure/ definition that is causing this issue. With that said, it would be interesting to know if we could live boot linux on one of these devices…

sarge_212

@george1421 no, no FOG broken here However, it is using the most current inits and kernels I believe as I am no longer getting the cdc-ether error @Sebastian-Roth . That’s a step in the right direction. And @george1421 I do believe they DO have a weird hard drive structure. I think Windows preloads 3 separate partitions on these surfaces:

A recovery partition, system partition, and the actual partition where the OS is.

That being said, I think I’m going to play with blowing away these partition schemes, USB image it, and then try and register the image with the FOG server. That might just do it. You guys have been so helpful!

Sebastian Roth

@sarge_212 I really don’t think that partition scheme comes into play at this early stage of loading the kernel! Feel free to do whatever you think is right but I doubt that a simple partition layout will help in loading the kernel any further.

That said you might want to try cranking up the kernel debugging level and maybe we see some more information then.

sarge_212

Well shucks.

Sebastian Roth

Are you happy to play with the code, as FOG 1.2.0 does not have this included in the WEB GUI yet (just another reason for FOG trunk). Take a look at /var/www/fog/lib/fog/BootMenu.class.php

Search for loglevel=4 and change all (three) to loglevel=7. Plus add debug as well. For example around line 442 would be:

				"osid=$osid",
				"loglevel=7",
				"debug",
				"consoleblank=0",

And line 247:

        print "$this->kernel loglevel=7 debug ".implode ...

george1421

@sarge_212 Don’t get discouraged here. You are doing pioneering work that hasn’t been done before with fog and the surface 4. “Some times you will get a little bloody walking on the bleeding edge of technology”

As Sebastian said, go into the fog settings and crank the debug level up to max and see if it will provide any additional information.

It would still be interesting to see if you can get a live linux to boot on this thing. That may be a path if the debugging doesn’t provide any more data. You can live boot linux from a usb flash drive so there won’t be anything installed on the surface. The live linux would give us a chance to run a few commands as well as tell use that booting linux on the tab is possible.

sarge_212

@george1421 You guys rock, and thanks for the encouragement. Don’t worry, I’m far from giving up! Sebastian, thanks for the tips on getting a higher level of debugging going, I will do that. Thanks FOG team!

sarge_212

I changed the debugging up to level 7 and there isn’t any more output on the surface after I try to register it. Any suggestions on a minimal ISO that I could drop on a USB stick and live boot it to run a few commands? Thanks all!

george1421

Similar issue in another thread. https://forums.fogproject.org/topic/6525/pxe-boot-hp-x2-210-hybrid-tablet-windows-10-pro/10

Not sure if they are related or not, but OP in that thread was able to live boot ubuntu.

Surface Pro 4 won't get to registration menu

260

11.6k

17.1k

154.6k