@EduardoTSeoane Thanks for this update! Can we mark this solved then? It’s probably not ideal but we have too many other things on the list to fix. If you really want to see this changed then please open a issue on github as things in the forum tend to be lost in the mass of requests easily.

@theland10 Then I suppose we are down to the bones and need to enable debugging in iPXE. When requesting a binary from rom-o-matic there is a field Debug build. Put intel into that field and you should get some more output - fancy in colors.

@ErwinBullen said in Imaging from Storage node fails:

I tried to mount and extract the image, but do not get beyond this error

Sorry for that. Please try this:

mkdir -p /mnt/images
mount -t nfs 192.168.100.32:/images /mnt/images
zcat /mnt/images/B-Blok-v18-v4/d1p2.img | partclone.ntfs --restore --restore_raw_file --ignore_crc -N -f 1 -s - -O /tmp/d1p2_deployed.img

Hint: Again make sure you do this on a system where you have enough space in /tmp or where ever else you have enough room to dump the extracted image for testing. Maybe best to mount an empty extra disk in /mnt/test/ and write the output file there.

As well please run ls -alR /images on your storage node and post output here.

@theland10 said in FOG USB Boot media with Intel NUC7i5BNH:

TX:8 TXE:2 RX:0 RXE:0

That’s the interesting part of the output. It tried to send eight packets (transmitted packets) and got two errors (TXE). While error sounds bad it really does not have to be in all cases. I am not a iPXE hacker and only know the code a bit but as far as I remember there are many situations where TXE count doesn’t actually mean a problem. But the issue I see is that there is no RX (received packets) whatsoever. I have no idea why that might happen.

Did you do the link check I asked you to in the last post? As well tried intel.efi yet?

@bnorwood said in Basic Image Capture Stuck in Loop:

I also reset all the username and passwords to match after seeing the error code. I think the storage one may have been bad.

We try to tell people to not mess with the FOG service account (called fog up to 1.5.5 and fogproject since 1.5.6). If you change the password of that account you run into trouble. Make sure you read and understand this: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Probably best if you open a new topic for the HyperV performance issue so we keep things sorted and other users will find the answers to their questions more easily.

@jrm Enabling HTTPS means that you need to recompile the iPXE binaries as well to add your local CA certificate. We added that functionality to FOG in 1.5.5 and fixed it in 1.5.6. I am sorry but we can’t put much effort into backporting those changes to 1.5.2 as we have way too much to do with current changes and requests.

Let me suggest you look into the current version of the iPXE compile script that comes with FOG 1.5.6. Maybe download and try this: https://github.com/FOGProject/fogproject/blob/master/utils/FOGiPXE/buildipxe.sh

But as well you probably need to adjust apache configs manually.

@marcolefo It’s very strange it does not expand. The latest issue we had (and fixed in the inits) did only occour when the images was captured from NVMe drives. So shouldn’t be an issue in your case anyway.

Between 1.5.4 and 1.5.6 we changes the way FOG discovers fixed size partitions. So it’s probably an issue with that in your particular case.

Looking at the partition layout information you posted I don’t see anything that could go wrong with that. So I am wondering if those came from when you captured the image with 1.5.4 or 1.5.6??

@Quazz Would you find the time to have a look at this as well?

@tehresman It simply cannot find your disk/controller. It’s kind of strange because we have reports that it does work when changing from RAID to AHCI: https://forums.fogproject.org/topic/12906/dell-optiplex-7060-getharddisk-error

@george1421 Would you have an idea why it’s that slow?? You have more experience with HyperV than I have!

@bnorwood I remember we had a performance issue some time ago but this was fixed. As I see you are running version 1.5.5 I don’t think this is the same problem. Here are the details just for reference: https://forums.fogproject.org/topic/6695/performance-decrease-using-hyper-v-win10-clients and maybe https://forums.fogproject.org/topic/6966/uploading-an-image-from-hyper-v-is-extremely-slow

@imagingmaster21 Please post the following three files for both the images you see this issue with: d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions

@theland10 As well please do a simple link check. Boot to the point where it tries to get an IP twice and drops you to a shell. Now check the LED. Link on? Pull the cable, wait 3 seconds, plug it back in and wait to see if the LED comes back on?!

Now run ifstat in the iPXE shell and post output here.

@theland10 Intersting, the iPXE lists this NIC as supported: https://ipxe.org/appnote/hardware_drivers

Can you try using intel.efi?

@MFuchs135 Please run the following commands and post a picture of that here:

sudo -i
cd /home/user/FOG-Imaging-Server/tmp
ls -al
cat binaries1.5.6.zip.sha256

@geardog Please schedule a debug capture task on this host, boot it up and when you get to the shell run:

ntfsresize --no-action --expand --verbose /dev/sda2

Note that I am guessing the partition letter sda2 here. Might be different on your system. If you are not sure take a look at the partitions using parted -l /dev/sda first.

If the above command does not throw an error you might run it again but this time leave out the --no-action command line parameter and it should do its job.

@theland10 From what you have tried and told us so far it’s very likely iPXE simply doesn’t like/support the network interface card. Do you know the exact network chip you have in those models? Please try booting a Live Linux from CD/DVD, run lspci -nn | grep -i -e ethernet -e network and post output/picture here.

@bnorwood What? 7 hours for not even 35 GB? There Muster be something wrong with virtualization or disk controller or network drivers.

@bnorwood Please take a picture of the last few messages you see on the client screen before IT reboots and post it here.

@geardog There are two things, partition size and the size of the actual filesystem within that partition. Seems like it resized the partition back to it’s original size but not the filesystem.

Can you please post a picture of the disk management view in Windows. Just to make süße my guess is right.

@Qweeqweg Just to add to what has been said already, this account should not be used to login and work on your machine. It’s used by FOG itself and should be left alone!

@narek This is the most complete topic on booting different systems via PXE: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

You need to know that every ISO is a bit different and there is no solution that would work with each and every one.