Surface Pro 4 won't get to registration menu

[sarge_212]

Hello kind FOG gents!

We’re trying to image some Surface Pro 4’s here in our environment. We successfully had the Surface pull the snponly.efi file and it gets an option menu. However, when selecting “Perform full host reg” it gets to /init.xz…/%17 and then never finishes | or drops back to fog menu. We are using FOG 1.2.0 on CentOS 7. My guess is that there isn’t a kernel yet for this new device, however we’re up for trying most anything EXCEPT upgrading to trunk. I hope this will be possible as we would like to continue using the stable version of FOG.

[Wayne Workman]

@sarge_212 said:

we’re up for trying most anything EXCEPT upgrading to trunk

Ouch. Why?

we would like to continue using the stable version of FOG.

You don’t have to tear down your old server. Leave it be, set up a 2nd fog server. Don’t touch your DHCP settings either. If you want a single client to use the new server (like the ethernet adapter you have), just create a DHCP reservation for that MAC address, and set the reservation to use the new server’s IP address for option 066. That’s it.

And obviously there are a thousand other solutions too that work around your old server. Like setting up a fog server on an isolated network (aka just a mini switch) - believe it or not, this is more difficult to do.

[sarge_212]

Wayne,

I appreciate the feedback and I’m not trying to be a stickler. However, the “powers at be” would prefer only one FOG server in production. Will the latest kernel work with FOG 1.2.0 as well as this shiny Surface Pro 4? Also a side note, how do I tell what kernel I’m currently using? Thank you again, and FOG really does rock it.

[Wayne Workman]

@sarge_212 The latest kernels would, but the latest inits would not. This is why the very latest kernels and inits are not listed in 1.2.0’s kernel update area.

Knowing what you’re using is not as easy in 1.2.0. 1.3.0 you just go to fog configuration and it’s right there.

I suppose you could do a debug upload or debug download, and at the CLI, you could issue commands to figure out what kernel is being used. uname -r is one command to do it, there are others.

[george1421]

While it would take a little time to setup. I still think seeing if the trunk version of FOG solves your problem. This would not be a second FOG server just a test system to ensure that the new inits work on the surface pro 4.

The idea is if we have one set of inits that fail and another that works, then there is a path to see where things fall down. If the new inits work, but there is a technical issue with the older inits where they can’t be fixed then the answer will be to wait until fog 1.3.0 is release before you image these systems.

I guess a question for the OP is, are you running the latest kernel and inits for the 1.2.0 build?

[Tom Elliott]

@sarge_212 I think one of the biggest things to think is you’re now working with systems that were created AFTER 1.2.0’s release. While kernels are easily updated, and yes I think new kernels will be required, the fact is you’re not even getting that far. You’re still waiting for ipxe to catch up to download the files to get you into the imaging environment. So I would recommend updating your tftpboot files. The files I build in trunk versions should still work even in older versions of fog because the way these operate is unchanged between the different versions. While output may be vastly different the way the checks happen from ipxe to and from the fog server remains the same. So if updating the ipxe files still cause the same problem using the snponly file, maybe try one of the other .efi files?

[george1421]

@Tom-Elliott (just trying to create a procedure around this)

So just for clarity here, you are recommending the OP to:

1. tar up the current /tftpboot files
2. Download the current trunk files (or specifically the /tftpboot files
3. Copy these files to the /tftboot directory on the FOG 1.2.0 server

A also assume
4) Update the kernels and inits for the newest ones supported under FOG 1.2.0 stable

[Tom Elliott]

@george1421 all of the above would do, but only worry about the tftpboot files from trunk, too much else has changed to say just get all of them.

Then, yes, update the kernels.

[sarge_212]

You guys rock, seriously. So I can use updated files in /tftpboot and keep other things the same? That is cool. I will download the trunk version today, install it, and scp those files or something over to that server. A small note, how does one go about updating the kernel? Wouldn’t that be done in the FOG web UI > FOG Configuration > Kernel update? Question there is, how do I know which one to choose, and how to tell currently what kernel I am using? Also, any ideas on when 1.3.0 will be released? Pure curiosity there. Thank you fine gentlemen again!

[george1421]

@sarge_212 For the kernel update, your steps are how it works in the trunk build, I can’t say for sure in 1.2.0 since its been almost a year since I’ve personally ran that version. I would assume the kernel update function will only let you install the kernels specific to 1.2.0.

As for the release date of 1.3.0. That is still in flux. There are no new features planned for 1.3.0 than what is in the current trunk build. The more people we can have test the trunk build and find the remaining bugs the faster the dev guys can finalize the system and then move on to fog (version next).

[Wayne Workman]

@george1421 said:

I can’t say for sure in 1.2.0 since its been almost a year since I’ve personally ran that version.

wget would be the way to do it.

[sarge_212]

Update:

Copied over the contents of a fresh trunk install to /tftpboot/ on FOG 1.2.0 server
Updated Kernel from 3.19.3 to 4.1.2 as seemed good in FOG UI
Tried imaging, it pulled ipxe.efi down from dhcp and we got our customized FOG menu(different than before)
Went to register and the machine kernel panic’d:

i8042: No Controller found
cdc-ether 2-2.2:2.- eth0 kevent 12 may have been dropped
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Kernel Offset: disabled
-----[ end Kernel panic – not syncing: VFS: unable to mount root fs on unknown-block(1,0)]----

I am not familiar with kernel panics, but I will be googling today for sure. If you gents can make sense of that or provide any insight, I’m sure it’d be helpful. Thank you.

[george1421]

We may need Tom’s feedback on this. But the kernels is actually 2 parts there is the bzImage and the inits. The root fs (root file system) is located in the inits. You need to ensure that you have the matching inits to go with the kernel you selected. There should be a 32 bit and 64 bit inits.

[sarge_212]

@george1421 – I’ve seen these in directories in I believe /var/www/html/fog/service/ is that the correct path where all these are stored? Good information, thank you. /me tips hat! I suppose we’ll wait for Tom’s feedback, which is great because that machine is bricked so I will need some time to rebuild the win10 image and get it on that machine. Thanks again!

[george1421]

@sarge_212 Yes these files need to be placed in /var/www/html/fog/service/ipxe You need to have bzImage bzImage32 init_32.xz and init.xz (taken from my trunk build production server 1.2.0 might be different)

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