Surface Pro 4 won't get to registration menu
-
@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.
-
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.
-
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.
-
@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!
-
@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)
-
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!
-
@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.
-
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.
-
@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.
-
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!
-
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.
-
@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.
-
@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).
-
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.
-
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.
-
@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] -
@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.
-
@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}
-
@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
-
@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…