@mpatel Well from the df-h command it shows that you have 192GiB of space assigned (mounted over) to /home. So your /images is connected to your root partition which is only 50GiB in size.
While I don’t know what instructions you used, I might suspect that the fog-home device should have been mounted over /images and not /home to provide storage for your images.
What I see from your dh -h your the FOG dashboard is seeing your file systems correctly.
@briancurry said in PXE Boot Errors:
Now the endpoint boots to what looks like the FOG imaging menu but then goes away after about 2 seconds.
There is a boot menu timeout that FOG has. The value is set in the FOG-Settings menus (sorry don’t remember off the top of my head). If you hit the up or down arrow within the 2 seconds you should be able to navigate the fog ipxe menu
Your best bet to have a standalone solution is to deploy the image to a temp computer and then capture the image with clonezilla. Both FOG and Clonezilla use partclone to capture the image, but FOG uses an image compression format not understood by partclone. You won’t have the FOG service capabilities with clonezilla but imaging will work standalone.
@sebastian-roth It appears the -100 -200 -300 numbering is based on the FC release and not to indicate a patch level.
So that means I’m back to trying to figure out how to diff all of the files between FC version and linux version of 4.13.9.
@sebastian-roth Sorry its been a long day of poking and pulling the linux kernel.
Today I tried the setting from the Arch document with no luck in the ‘M’ release.
Then I tried just removing all of the power saving code out of the kernel as well as removing all acpi code, with no success. The ‘N’ release.
Next I was about to give up then I got the idea since the FC27 kernel worked when FC27 live was booted I decided to take the tar file you linked below and just straight copy over the ‘M’ config file and then built the kernel. I did this to test 2 ideas. 1) Did I have the right kernel options selected from the 4.17.13 release 2) Was the FC devs able to patch the 4.13.9 kernel to make it work with the OPs hardware. Both tests were successful. That is what @hlalex posted in the bzImage4139-300m.log log file. In another thread an OP had an issue with the current FOS kernel and an Microsoft usb network adapter. I added the patch into 4.17.13 M kernel build. That network driver was then discovered by FOS, but FOS still has the delayed creation of the GPT partition. So that mystery was not solved as of now either. I was kind of hoping the updated FOS kernel would have addressed that but not as of now.
Back on point so… It would be ideal to understand what the FC kernel dev guys did to linux 4.13.9 to create 4.13.9-300. I assume the -300 means there was 300 patches to the stock 4.13.9 kernel (??). The only thing I can think is to do a (mega)diff between linux 4.13.9 and the FC 4.13.9-300. To see what has changed.
@jemerson93 The mbr/gpt issue needs to be resolved, period. The truth may be this slow creation process may be a ‘feature’ of 4.17.x kernel and not a bug. I can tell you this issue is still on the developers plate (which is getting overloaded at the moment). Please give them a bit to get back from holiday and back in business.
@jemerson93 said in Issue imaging with Surface Pro:
I am back to the issue with the long erasing MBR/GPT partitions
Well that tells me the kernel patch I applied didn’t address the slow gpt partition creation (same issue with FOS 4.17.0)
@tom-elliott The nic was enabled by adding
{REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927)}
to drivers/net/usb/r8152.c
@jemerson93 To your adding other usb nics. The answer is sure, all you need to do is patch the linux kernel source from http://www.kernel.org and then compile the linux kernel.
@jemerson93 Back on point here. I looked and that usb ethernet adapter is not currently supported by the Linux kernel at least as of 4.17.13 (which is pretty new). I did find a FOG forum post ( https://forums.fogproject.org/topic/10943/surface-pro-4-registration-issues ) that discusses that exact network adapter. So it appears that the FOG Project may have a patch that enables that network adapter.
Please try this development kernel: https://drive.google.com/open?id=1WPv4HeMrWdWu9uyOyVaoJkBX3A9EGi-t
bzImage41713m into that field.I really don’t know if this will work (the FOG Project patch) or not for your install. This development kernel has quite a bit more hardware support added than previous releases of the FOS kernel. Will something else break? Probably…??, but it shouldn’t.
I did recompile the 4.17.13 kernel with the powersave setting from the Arch article, plus FOG kernel patches and then added support for Microsoft Surface network adapter (patch info found here: https://forums.fogproject.org/topic/10943/surface-pro-4-registration-issues ). This kernel is ‘M’ release. Please test it out.