Surface Pro 3 PXE:

[Matt Edwards]

Morning,

I’ve tried again using the modified ipxe.efi file created from the website - When I set that as the bootfile and boot up the Surface Pro 3 I get…

Checking Media Presence…
Media Present…
Start PXE over IPv4

It flicks then to saying

Downloading NBP file… (this appears for a second or two)

Then moves onto

Checking Media Presence…
Media Present…
Start PXE over IPv6

Before continuing to boot up the Surface Pro 3.

I don’t get any Fog Menu

Thanks

Matt

[d4rk3]

Try making a 32-bit EFI bootfile with a script that only has these contents:

#!ipxe

dhcp
shell

If that doesn’t work either, make a 64-bit one with the same script.

One of those should bring you to an iPXE shell.

[Matt Edwards]

Thanks - will try this tomorrow when I’m back in work.

If I manage to get it working, will this then boot up the fog menu or will I need to enter some command in the iPXE shell to load fog? If so, what will I need to enter?

Thanks

Matt

[Sebastian Roth]

You’ll end up in an iPXE shell…
dhcp, ifstat, ipstat and ping will be helpful to debug you network connection. When it is up you can just chainload default.ipxe (chain tftp://<tftp-ip>/default.ipxe) OR run all the commands by hand (see d4rk3’s earlier post #45).

[d4rk3]

Correct. Once we get you to a shell we can go from there.

On that note, once you are able to boot to an iPXE shell make a note of the architecture of the EFI bootfile. Go back to [url]https://rom-o-matic.eu[/url] and re-compile an EFI bootfile with the correct architecture for your Surfaces.

Keep us posted.

[Matt Edwards]

I’ve tried doing this…

I first tried with the 32 bit and it flashed up saying downloading NBP File very quickly then moved onto IPv6 before continuing to load up Windows…

I then tried using the 64 bit version, again it came up with Downloading NBP file and appeared to be doing a little more then the 32 bit version, but then it continued to load up Windows!!

What else can I try??!?!?

Thanks

Matt

[d4rk3]

Ok, I just re-read this thread and I missed your earlier message:

“I then tried the snp.efi which booted to a very basic looking menu”

The snp.efi is what you’ll want to use for these.

Now, we just need to find a good kernel for these to boot with and you should be all set.

[d4rk3]

Ok. I just re-read it again and Tom is correct, you’ll need to upgrade to the latest SVN for these to work.

[CODE]apt-get install subversion
svn co https://svn.code.sf.net/p/freeghost/code/trunk/ /opt/trunk
cd /opt/trunk/bin
./installfog.sh[/CODE]

Once upgraded use the snp.efi bootfile and see if you’re able to register the Surface with FOG.

[A Former User]

I am experiencing a similar issue.

I was able to get a Surface Pro 3 to PXE boot and recognize my FOG server, but when I attempted to either Quick Host Register or Full Host Register, I received the following error:

“Error ident-mapping new memmap (ox13ac72000)!
i8042: No controller found”

Then, at the usual FOG registration screen, it says:
“An error has been detected!
Cannot find HDD on system”

I tested using a USB keyboard instead of the Surface keyboard, and made sure that the server could still register and deploy images to other computers.

I also tried snp.efi and ipxe.efi with no luck. FOG 1.2 and my trunk is up-to-date as of yesterday (9/22/15) and the FOG server has been restarted.

Any ideas out there?

[Sebastian Roth]

There are several other threads about Surface Pro 3 in the forums (https://www.google.com/?gws_rd=ssl#q=site:fogproject.org+surface) but non of them is talking about HDD problems I wonder.

AFAIK there is a SSD drive in the Surface Pro 3, right? Please add the device as a new host with it’s MAC address by hand in the webinterface. Then boot it up in a debug session (Host -> Basic Tasks -> Debug) and issue the following command:

dmesg | grep sd

What do you see?

[A Former User]

Thanks Uncle Frank . Please see the attached image of what I saw after entering the debug command.

[Sebastian Roth]

What about this:

dmesg | grep ATA

Sorry, this is just guessing in the dark so far. Probably best if you could upload the whole output so we can have a look. Again, boot into debug mode and then:

mkdir -p /mnt
mount -o nolock <your-fog-server-ip>:/images/dev /mnt
dmesg > /mnt/dmesg.txt
umount /mnt

Edit: Just for the records, here is what dmesg on a Surface Pro 3 might look like: https://gist.github.com/altercation/30776be1078eac2b0cc6

[A Former User]

Here’s what I got:

tech@fog14VM:/images/dev$ less dmesg.txt
[ 0.000000] Linux version 4.2.0 (root@debian64) (gcc version 4.9.2 (Debian 4.9.2-10) ) #8 SMP Thu Sep 17 09:02:24 EDT 2015
[ 0.000000] Command line: bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=10.2.16.9/fog/ consoleblank=0 mac=c0:33:5e:73:cf:a2 ftp=10.2.16.9 storage= storageip= web=10.2.16.9/fog/ osid= consoleblank=0 irqpoll hostname=MIC-SURFACE-02 mode=onlydebug
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] x86/fpu: Legacy x87 FPU detected.
[ 0.000000] x86/fpu: Using ‘lazy’ FPU context switches.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000008f000-0x000000000008ffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x000000000009dfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000020200000-0x00000000ba96efff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000ba96f000-0x00000000bac6efff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000bac6f000-0x00000000bad6efff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000bad6f000-0x00000000bb3bffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000bb3c0000-0x00000000bbaccfff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000bbacd000-0x00000000bbad0fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000bbad1000-0x00000000bbad1fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000bbad2000-0x00000000bbffffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000e3ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fea00000-0x00000000feafffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed03000-0x00000000fed03fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed06000-0x00000000fed06fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed08000-0x00000000fed09fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1cfff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fedbffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved

[Sebastian Roth]

This obviously didn’t get posted at full length. Please try to add dmesg.txt to your post as an attached file using the upload button just obove the text entering box (right of the smily :-))

[A Former User]

Separate question, but do you have any tips on exporting a file in Windows or Mac machine from a Linux box? Haven’t had to do this yet.

[cml]

@tnunn

You can either use WinSCP, or copy the file to /tftpboot and get it via tftp from windows.

 tftp –i x.x.x.x get dmesg.txt

Where x.x.x.x is the IP of your FOG server.

[A Former User]

Please see the attached dmesg.txt file. Thanks again for any insight here

[Wayne Workman]

@cml said:

@tnunn

You can either use WinSCP, or copy the file to /tftpboot and get it via tftp from windows.

 tftp –i x.x.x.x get dmesg.txt

Where x.x.x.x is the IP of your FOG server.

You can also output it to your /var/www/html directory

then just browse to it in a web browser and download it. x.x.x.x/dmesg.txt

[Sebastian Roth]

Didn’t know that there are Surface Pro 3 devices with eMMC HDD…

...
[    2.163894] mmc0: MAN_BKOPS_EN bit is not set
[    2.187891] mmc0: new HS200 MMC card at address 0001
[    2.188108] mmcblk0: mmc0:0001 HCG8e 58.2 GiB 
[    2.188172] mmcblk0boot0: mmc0:0001 HCG8e partition 1 4.00 MiB
[    2.188245] mmcblk0boot1: mmc0:0001 HCG8e partition 2 4.00 MiB
[    2.217676]  mmcblk0: p1 p2 p3 p4 p5

To make this work you have to set 'Host Primary Disk tp ‘/dev/mmcblk0’ (without the quotes!) in the host settings of this particular devices/host. Please report back.

[A Former User]

The ‘Host Primary Disk’ change did the trick! Thanks Uncle Frank! I’m working on testing a Windows 10 deployment.