Great!!! Let’s see if this quick fix will be enough for you to capture and deploy those devices. I really hope it will as getting it fixed by HP or the BIOS vendor (Insyde) may take weeks. Please keep us posted as you try deployment as well.

@pencils Worked loading in a different browser… my issue.

The PCAP dump looks pretty good! DHCP is fine and I see the client requesting a file via TFTP. The filename is undionly.0!! Did you copy that file as Tom suggested?

sudo cp /tftproot/undionly.kpxe /tftproot/undionly.0

@Fabreazy I lost track of this issue but it was raised by another user and Tom just pushed a fix. Can you please update to the very latest version and see if kernel updating is working again? Sorry for the long delay.

@educapole Are you behind a proxy server? You should find install error log files in your install directory, sub directory ~/fogproject/bin/error_logs/ in your case… Please upload those so we can have a look!

Well, I’d suggest updating to the latest version on a daily or maybe weekly basis! Because we need you people to find the bugs so we can figure out a solution and fix them!! Otherwise mean bugs might be in the release and people will run into them later. Sure not everyone is keen to do that but we need you!

@JJ-Fullmer Did you recently upgrade your CentOS system? Maybe this is related? When you see the mount issue, please run this command on the server service rpcbind status to see if it is running or not.

As well please run rpm -qa | grep rpcbind and post the output here.

@Wayne-Workman said:

I’m convinced this is a network issue.

+1 from me!

@JJ-Fullmer Don’t worry about this duplicate post. It was just a lucky guess of mine that this could be connected. As well it’s good that you brought up this issue again as I would have forgotten about it. Checking the CentOS repo now I see a new package being available since 13th of June - search for rpcbind here.

I am sure Wayne meant lsusb to get the USB NIC information.

@josh-martin said:

…initializing devices…

That’s a good starting point. You already got past one of the biggest hurdles of PXE booting your Yoga via a USB NIC. Well done! But there are a couple more hurdles to pass. The message means that iPXE is trying to find your NIC. How long did you wait when seeing this message. Sometimes it takes a longer time. Just give it a minute or so to see if it is really stuck. As well you can try different iPXE binary. I guess you are using undionly.kpxe right now. Edit your /etc/dhcp/dhcpd.conf and try undionly.kkpxe (note the double ‘k’) or ipxe.pxe/ipxe.kpxe…

@Joe-Gill The message “We need memory” is not an error. The issue you are running into is because you are trying to deploy an image from a source disk/partition that was bigger to a smaller destination disk/partition.

The image type is set to?? Resizable or Non-resizable? Make sure you set image type to resizeable if you want to deploy that image to a smaller (or larger) disk later on. You need to recapture the image when changing the type!

Just for clarification when others are reading this in the future: ipxe.pxe comes with native NIC drivers where undionly.* uses the NIC’s UNDI interface. Seems like the mentioned realtek NIC has a “buggy” PXE implementation which causes the undionly binary to fail…

@Tywyn I see two different interfaces in your post. enp3s1 in the dhcpd log messages and ens33 in the .fogsettings file. So I supposed you changed IP and interface. Please check /etc/default/isc-dhcp-server file. The INTERFACES=... variable might be set to the wrong interface.

@blue_steel I think there is a typo. Shouldn’t it be . /usr/share/fog/lib/funcs.sh or source /usr/share/fog/lib/funcs.sh? So no space between the first slash and ‘usr’ I’d say.

@sgwk Please search the forums for “Booting from SAN device 0x80”. There are a lot of posts about this. Try different exit styles for this host. See in the other posts.

@michaeloberg said in Fujitsu T939 Tablet not PXE Booting:

As mentioned earlier I am currently running my DNS/DHCP services on a Windows 2008 r2 server.

Right, forgot about that. Then I’d suggest you first try setting option 67 to ipxe.efi just to see if the Fujitsu T939 PXE boots fine in UEFI mode. If it does you might look into what I said about dnsmasq earlier! Please tell us which Linux OS and version you have.

@msi This is what George is referring to: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support

He provided instructions on how to compile and configure dnsmasq… As a starter you could skip the compile step and install dnsmasq from your official package repository sudo yum install dnsmasq. When you get this up and running you can still go ahead, save the config, purge/uninstall dnsmasq and compile the latest version as suggested because it has fixed UEFI/BIOS support.

@george1421 said:

The easiest thing for users would be for the devs in the fog program to either use dd or some process to capture a functioning usb and make that available for download for testing.

That’s exactly the point why I thought about an ISO image. Sure you can take an image (using dd or other tools) from a good prepared USB stick but to me that seams a bit like putting the cart before the horse (please don’t get me wrong, not meaning to be offensive here!)

Generating an ISO that is multiboot on BIOS and EFI (32bit and 64bit!) is possible without much effort. So Tom can add this step to his kernel compile/upload toolchain and we will have current kernel/init.xz and bootable ISO file ready to download for users all the time.
Hugh advantage would be that we only need one “simple” description of how to dump this ISO onto USB sticks. As well a generated ISO is just big enough to take up all the things needed. Whereas an image file (dd or what) is usually created with a fixed size. Sure you can grow/shrink it to suit your needs but it adds some unnecessary inconvenience to it.

Thanks heaps for all the effort you are putting into this and all the tutorials you wrote. I am sure users will find this really helpful even if we end up providing an easy to handle ready to go ISO file!

I’ve played with syslinux (http://www.syslinux.org/wiki/index.php/Isohybrid) for about two hours just to find out that its UEFI support is still kind of young. Does not mean it is impossible to achieve but I found a way easier solution using GRUB2. To generate a FOG debug ISO I downloaded the kernel/init files, wrote a grub.cfg like you have, put it all in a local directory called ISO_root and called grub-mkrescue -o fog_debug.iso ISO_root/. This is on Debian Jessie. Out comes a ready to go ISO file which I can boot in qemu! Testing it on USB Stick now…

Edit: Sorry, I was wrong. This simple command only generates an ISO usable on BIOS machines - at least on my BIOS machine right now. Might take some extra effort to generate BIOS/UEFI ISOs or just the right packages installed. Reading on…

Edit2: Needed to install grub-efi-amd64-bin and grub-efi-ia32-bin to have grub-mkrescure build a multiboot ISO. Here is a first try which also tries to detect 32/64bit Arch (grub cmd cpuid): https://drive.google.com/folderview?id=0B-bOeHjoUmyMM2c4LV90Z1NyNWc&usp=sharing (wow, 60 MB just for a plain BIOS/EFI 32/64bit debug ISO… may I ask you guys to give this a try on various platforms? Just dump it on USB stick using dd/win32 disk imager/unetbootin etc.)

@LPetelik Trying to contact you on forum chat…

By the way, “.” is just the current directory, meaning the sum of all subdirectories within your /images folder is growing or possibly is just a file directly in /images?!?

@george1421 said:

The one thing that is missing (I think) is once you have your usb flash drive, is a way to refresh the kernels as new kernels are released over time.

I really hope that we can get this streamlined into Tom’s compile tool chain. So if he builds new kernels and inits and uploads those to the website he could also add a current ISO to https://fogproject.org/isos for example. Self updating process within the ISO is not worth the scripting effort I reckon as we will have lots of trouble with NIC issues and people behind proxies. So if we update the kernel people just need to download the most current ISO again.

@Wayne-Workman said:

Just be sure to include “troubleshoot” in the name / menus so that people don’t get the wrong idea and think this is the way to go for every time they wanna use fog.

Sure we will! But this is still a very early stage and I am not sure how well this will work. Would you mind giving it a try? Just download the ISO, dump it onto an empty stick and try booting it on various machines/architectures. I don’t have access to different machines right now as I am not working at university anymore…

OMG!!! Thank god we figured this out. I thought I was lost in this.