Surface Pro 4 won't get to registration menu

[sarge_212]

@george1421 Yep 1.2.0 stable with some mods though, eg playing with kernels and the like and I’ve pulled the /tftpboot directory from a recent trunk version but I don’t know how much of an effect that will have. At this point it all seems to be working normally, eg still imaging other hardware without issue.

[Sebastian Roth]

@george1421 said:

I will assume eth0 is the built in wireless adapter and eth1 is the add on adapter.

I don’t think this is the case as Tom does not add wireless drivers to the kernel AFAIK. So it’s a really good question what eth0 is. Can you please boot again and run the following commands:

ls -al /sys/class/net/eth0/device/driver/ | grep module
...
ls -al /sys/class/net/eth1/device/driver/ | grep module
...

This should at least show us which drivers are used for those devices and hopefully we then understand which is which.

[sarge_212]

@Sebastian-Roth do this in the FLOS usb? (the one debug Fog Live OS I created?)

[Tom Elliott]

@sarge_212 Maybe we could call it FLOGGER?

[george1421]

@sarge_212 Yes that command is a linux command so you need to boot into flos (flogger) and get to the command prompt. Then run the ls command that will display all files in that location and then just filter out the ones that have module

[Sebastian Roth]

@sarge_212 said:

do this in the FLOS usb? (the one debug Fog Live OS I created?)

Yes I’d say so.

[sarge_212]

@Sebastian-Roth I like flos better, no offense @Tom-Elliott. I’ll boot into that and get you all the output of those 2 commands. may come in cell phone selfie form, but hey, that’s okay, right?

[Sebastian Roth]

Yes, whichever you like. Picture is great because we see exactly what you have on screen!

[Tom Elliott]

@sarge_212 Aww man,

I was just thinking of a way to phrase it as an acronym and all.

Free Live Opensource Ghost/Ghosting environment replacement.

[sarge_212]

@Tom-Elliott That is a better one. FLOGGER it is, Tom.

[sarge_212]

So, I think part of the problem is the surface doesn’t have hard wire ethernet, be nice if it did. I’m using a surface dock. Here is what I’m seeing (using the ethernet adapter on the dock, because I can’t use the usb 2.0 network-ethernet adapter on the surface because the usb FLOGGER is in that port) oh surface woes.

anyhow, I’m going to try and find a usb hub to plug them all in to the one single port on the surface. Anything else I can check while in the Flogger OS?

[Wayne Workman]

@Tom-Elliott said:

@sarge_212 Aww man,

I was just thinking of a way to phrase it as an acronym and all.

Free Live Opensource Ghost/Ghosting environment replacement.

I’m still partial to fog-too

[sarge_212]

Okay. Here is something else. I have the ethernet cable in the surface dock. I put the ipxe usb boot only, eg only thing on flash drive is /efi/boot/bootx64.efi into the single usb port and booted. Was able to get to a registration menu. Keyboard didn’t work, but surface touch did. Arrowed down to perform full host registration and inventory and received the following:

This is using the kernel with FOG 1.2.0, I believe 3.19.8 but I can check that if needed.

[Sebastian Roth]

So now we are back to eth0 only (driver seams to be r8152). But what was the other eth device just some hours ago?? Where is it gone. Maybe because you changed back to an older kernel? Sorry man but I think you’ve lost me here. Not really sure what devices (dock, USB NIC) you have and kernels you switch forth and back.

[sarge_212]

@Sebastian-Roth The other eth device some hours ago was the USB 2.0 usb-ethernet adapter I was using. This helped us some how in the testing but I can’t remember how. I did go back to an older kernel. Here is the current config:

Surface Dock (ethernet cable plugged into that)
Older kernel
USB booting of flogger os in usb port ON surface

I can test a variety of other configs, I can’t remember what we were doing yesterday with the ethernet-usb adapter though…

[sarge_212]

Just playing with the Flogger os, and looking around at things. When I’m connected to the surface dock using the ethernet cable, I get this before the fog prompt:

r8152 2-2.2:1.0 eth0: v 1.08.2

I don’t know if that helps at all?

[Sebastian Roth]

Feels like we are going in circles with this. If you don’t remember what you tried yesterday how would we be able to keep track of what has been tried and which options we should look into. No offense here - just saying that it’s very hard to follow through so many posts and no real track to follow down.

Re-reading your initial post and one of your very early posts I find that were pretty close already. You had iPXE (snponly.efi/ipxe.efi) booting up to the menu but no kernel coming up at first. Then you posted:

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)]----

So we have seen the kernel panic already. So to me it actually seams like hand over from netbooted iPXE to the kernel is kind of working. At least we see some kernel messages! And the other thing we know (for sure?!) is that you were able to boot the most current FOG kernel from a USB stick. So kernel is fine on the device and netboot also seams good.

So we are left with the question what’s going on with this kernel panic?? What this panic actually means is that the root device given (in the case of FOG it is a ramdisk where init.xz is loaded into) cannot be mounted. There can be other reasons for this but in most cases this is due to a corrupted or wrong init file.

So lets try to download and check most current kernel and init files by hand. Just to make sure those are fine. Run those commands as root on your FOG server:

cd /var/www/fog/service/ipxe
mkdir bak
mv bzImage* init*.xz bak
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

Pay attention if you get ‘OK’ as results from the sha512sum commands. This is really important! Then try booting your device via netboot (not via USB stick!) in UEFI mode like you have already done several times.

[sarge_212]

@Sebastian-Roth I understand that I “may” have gone in circles. Thanks to @george1421 I’m documenting all the changes I’m doing from here on out so we don’t have that problem. I will do this now, thanks again for all your awesome suggestions and indications of where its going wrong, I really do appreciate it!!

[sarge_212]

I “wgot” the kernels and inits. I sha’d them to make sure they were okay and they both checked out. Chown’d them to fog:apache and the UEFI booted the surface. Here is what I have:

This second picture is a Optiplex 9020 on the new kernels and inits. It seems there is an issue when I try to go to the new kernels and inits with the stable FOG 1.2.0 and grab the undionly.kpxe. So in order to image the other machines we have in production(Optiplex 9020 and Latitude E7450, E7470) I drop back down to the other kernels. Thoughts?

[Tom Elliott]

@sarge_212 I still want to help!!!