Surface Pro 4 won't get to registration menu

[sarge_212]

Would it be kosher to pull the bzImage, bzImage32 init_32.xz and init.xz from the trunk install and put them in the 1.2.0 install and see if that works? I’ll try that next, but wasn’t sure how that would affect things. I’m still learning all of this, thanks!

[george1421]

@sarge_212 No that would create bad karma.

The boot image from the trunk needs the trunk supporting code to function correctly. You need to stay with the kernels specific to 1.2.0.

[Tom Elliott]

Currently I’m at an appointment so I’m not able to give any good feedback yet. I will try to add a more suitable response when I am done with this appointment.

[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.