@Arrowhead-IT Thanks for providing information about those devices and helping us. Can you please run another debug session and post the full output of lsblk -pno KNAME,MAJ:MIN -x KNAME? We need the exact output (especially dev names - which you already provided - AND the IDs. Just take a picture and post it here if you don’t want to bother about typing it all.

Thank you guys for working together and getting this fixed in just about 24 hours! This is amazing!

@Arrowhead-IT Great! Thanks again. I am sure @Tom-Elliott will push the fix pretty soon. Should be fairly easy in your case. But I am a bit worried about these ‘mmcblk0rpmb’ device from the other thread! Tom, should we only look at minor ids smaller than 8?? Might cause issues with GPT systems??

As you can see here multicast has it’s very own “address space”. It’s designed to use those addresses to work properly I suppose. I guess you can use different addresses if you really know what you are doing. But using a subnet broadcast address does not sound right to me.

@Arrowhead-IT We are working on this and try to get this fixed for mmcblk devices as well (another thread). Unfortunately those devices are even more special than your nvme drive but pretty similar naming-wise! As we are all doing this in our free time there is no timeline I can give you. We are onto it and I hope we can give you something to test in the next couple of days. So please bare with us.

@cnbgeren We have seen this happening with weird DHCP setups. Please make sure you have only one DHCP server answering within your subnet! As well you might want to try out FOG trunk as we are pretty close to a new release and many things have changed since version 1.2.0! See here on how to install trunk: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

@Arrowhead-IT Here we go. I found some time to look into this more closely!
Download init.xz/init_32.xz test files from https://drive.google.com/folderview?id=0B-bOeHjoUmyMazJLZDhGaEl5VTQ&usp=sharing and put into place in /var/www/fog/service/ipxe/ or /var/www/html/fog/service/ipxe/ (probably a good idea to rename the original files instead of just overwriting them!)

Please test and report back if capturing/deploy is working (Image type: Multiple Partition - Single Disk, Host Primary Disk: /dev/nvme0n1).

Possibly the project just needs a bit more money to be able to afford a server with a more reliable connection… All the companies using FOG would like to donate 10 bugs each??

@Arrowhead-IT Thanks for testing and reporting. Tom has been working on this as well and I think that he’s going to update the official init files pretty soon.

@jhuesser Now I see. From what I remember (check out this post) the cdc_ether kernel module is not working nicely and therefore Tom and I decided to through it out kernel config. AFAIK there should be a patch added to the kernel that adds support for those 045e:07c6 and 045e:07ab Microsoft devices to the r8153 driver included in the kernel already. @Tom-Elliott do we still add this patch??

As well read through this and see if your DHCP config is fine.

@Arrowhead-IT Tom has just updated the unofficial inits on his server again. Re-worked download and improved upload a little more. See here: https://forums.fogproject.org/topic/6036/hp-stream-11-pro/65

Please try those and let us know! Thanks in advance.

@Buzer1 Knowing the version of FOG you are running would definitely help us pointing you the right way but as well please read trough this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP (credentials and permissions)

I think George meant you better create grub.cfg config yourself and put it in /boot/grub/grub.cfg
Here is his example config:

set timeout=10
set default=0
insmod all_video

menuentry "FOG 32-bit Debug Kernel" {
 linux  /boot/bzImage32 loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
 initrd /boot/init_32.xz
}

menuentry "FOG 64-bit Debug Kernel" {
 linux  /boot/bzImage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
 initrd /boot/init.xz
}

@Buzer1 Checked the FTP credentials? Download and upload are two completely different things. If one works it does not mean the other is working as well. Please go through the mentioned wiki article and thouroughly check your FTP credentials!

@Fabreazy George is absolutely right here! FOG 1.2.0 comes with kernel 3.15.6 but according to this http://cateee.net/lkddb/web-lkddb/IGB.html those I210 NICs are supported only since 3.16 and newer kernels.

One way would be to upgrade or setup a new system with FOG trunk https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

But you could also just try installing newer kernels in FOG 1.2.0. Should be easy doing this: FOG configuration -> Kernel updates

@welcomyou If you want to do it the ‘hackish’ way there is always an option to do so. Add this to your /etc/hosts file on the FOG server and replace x.x.x.x with an IP pointing to a local webserver within your private network:

x.x.x.x fogproject.org

Assuming you have all the packages for your distribution properly installed beforehand, plus put checksums, kernels and initrds on your local webserver, you should be able to run the FOG installer script.

I am not saying this is easy but definitely doable…

@george1421 I am pretty sure the .xz image format does not need to be understood by iPXE. This is handled by the kernel (later on in the process). See my post with the C comment a little further down! As well the message “format not recognized” does not play a roll for us. See the C code here if you like. This might be a minor print out bug in iPXE which does not cause any issue!

@Matthieu-Jacquart Meanwhile I compiled a new iPXE binary with some added custom debug output. Please put this in your /tftpboot and same procedure… hopefully we will see messages after boot!

@dureal99d Sure it is possible. There is a description in the wiki on how to extend space for images if you are running FOG in a vmware environment. But you can follow this pretty much to the point except that you need to buy and pop in a secondary physical disk instead of adding a virtual one… https://wiki.fogproject.org/wiki/index.php?title=Add_%26_Extend_a_2nd_Virtual_HDD

@Quazz Thought about that too, but tested with and without space and it’s fine either way.

@hdhzero Can you please get us a full partition table listing? I’ve never seen a loop happening and we better find out what this is about. So please boot into a debug image upload session (like you schedule a normal task but select debug just before you hit “Create Task” select the debug checkbox).

When you get to the shell run sfdisk -d /dev/sda. Please post a picture here.