Forget it, sorry to waste anyone’s time. Redoing it has worked on all machines. I am guessing applying just the snapin via group wiped the key fields for each host.

Never mind. It was an OS issue. Solved.

@carlesgm You see that sda5 your linux system partition is resized/shrunk but the following swap partition (sda6) is not moved forward. We usually don’t move partitions as it can cause really bad issue (unbootable system).

Not sure what to advise in this situation. Could you remove the swap partition before capturing the image and then re-create it (and fix your entry in /etc/fstab) after deploy?

Hello guys, here again returning for feedback.

The multicast worked fine!! very good. Thanks for all devs and people who help us. Thanks!

Now, as said in the first topic, i´m very happy with this and thinking of doing my course completion work(TCC in portuguese) of University graduate about the use of FOGServer in computers lab.

@sebastian-roth shoot I should have tried that, no I kinda give up. And used fedora 26.

This error is very much like other when FOG admins change the linux user (service account) fog’s password. Understand this is not the webui default admin called fog this is the linux user called fog. That account should only be managed by the fog install script.

@vanlue-it-guy Leave that at 0 for disabled. It’s for those people who are using the 224.0.0.1 and want to use a different multicast address, (say for example 234.0.0.1)

SOLUTION:
Shrink the data partition
Move any partitions after the data partition to the left (so unallocated space is all at the right)
Capture using Multiple Partition Image - Single Disk (Non resizable) (or all disks if that’s your setup obviously)
Deploy to the SSD
Move the previous partitions back to the right.
Expand the data partition
Recapture with Single Disk - Resizable
Deploy to the rest.

@p4cm4n OK now that you have the password parts worked out, you should be able to go into FOG Settings->FOG Kernel and from there you can downgrade to the 4.15.2 kernels, just download both bzImage and bzImage32 for the PC platform. From there it will download the kernels. You can check by going on the FOG server console to

cd /var/www/html/fog/service/ipxe file bzImage

That should print out version 4.15.2. If that is the case you are golden. FWIW, you CAN do this while you are imaging as long as you don’t currently have a system pxe booting.

@tom-elliott Image Manager Partclone Gzip

I was confused about what to choose. Because as you can see in the screen shot that the compression for basic image is Partclone Compressed. So I just went into that image definition and saw the Gzip.

With FOG installed you should go to FOG Configuration under settings and find the Proxy settings and fill those in if you haven’t already. Hopefully it will all be good with that.

@jemerson93 Have you already tried using kernel version 4.15.2 as opposed to 4.16.6 and 4.17.0?

@fogmania said in Can't do Quick Image After creating Users:

I’m using a storage node that is working well but it has not been updated to the last version. Should I do this too?

Absolutely - it’s required in most cases.

But the image history still shows that the user that is logged in is the one that made all imagings. Any idea?

Others have complained about this too, see this thread:

https://forums.fogproject.org/topic/11596/host-imaging-history-lists-the-current-image-name-on-every-line

Prompt time is the checkin time for the client. Anything below 60 seconds is invalid, and we won’t allow the client to go below that point. (Using Default = 60s)

Error code 2691 = The machine is already joined to the domain.

So this is likely true. When creating the master image, I would highly suggest disabling the “Join Domain” feature of the host. (Host Page->Edit relevant Host->Active Directory->Uncheck Join Domain) then disjoin that machine from the domain manually. Then capture your image. If you’re sysprepping your images, it’s also recommended to disable the fogservice from starting on the machine, and having a setupcomplete.cmd script that re-enables the service once sysprep process is complete.

@svalding What would be interesting to know is what is different between the two docks.

Please do the following

Schedule a debug deploy/capture (tick the check box for debug before you submit the task) for the nic of the working dock. It doesn’t matter if its a capture or deploy because we are not going to do either. PXE boot the target computer, after FOS boots you should see several screens of text press enter a few times until you get to the linux command prompt. Key in
lspci -nn | grep etwork Record what you see there for the network adapter. The hex codes are important. Repeat the same process with the non-working dock. You may get warning messages about not able to access the network, but it still should allow you to get to the linux command prompt. Collect the output of the lspci command from above. Please post the output of those two systems in this thread.

0_1530763109245_33e20c39-f273-4851-b3f1-fedd0e4bbeed-image.png

Got this working over the weekend with QNAP. The NFS shares are slightly different in v4.3.3 of the QNAP software on the TS-231. You don’t have to specify the full local path. Only the shared path location.

@p4cm4n Glad you figured out what the issue was and a way to resolve the problem. Glad to help program this for you, among others. I know how useful it is and how it has impacted jobs.

Now if only I could find a job that requires FOG as a part of it, I think I’d be a shoe in lol.

@plegrand UEFI implementations can be a real pain. It’s meant to be Kind of universal but everyone is just doing his/her own thing. So some UEFI clients work great while others just don’t want to play nicely. There is not much we can do about it. Well, you can try using rEFInd and start playing with the config file. If you are lucky it’s justa matter of finding the right options.

echo Installiere Acrobat Reader DC + Font Pack
“%source%\AcroRdrDC1801120035_de_DE.exe” /sAll /rs
msiexec /qn /i “%source%\FontPack1500720033_XtdAlf_Lang_DC.msi” REBOOT=ReallySuppress

i’ll write a quick tutorial as soon as i have everything working. I guess i can’t use -no–describe in uefi, but i can allways use wimbot to boot to an envoirment and then mount iscsi devices and go from there.
memdisk is a nice kernel but loading the ENTIRE iso into the ram is network consuming and big isos will eat up my ram at best.
running from iscsi is the way to go! it’s like a physical device , but mounted virtually, via a network, it’s like using a pen, but -no-describe ruins some of the feautres i want to use, well… if i want to use it in uefi mode anyway.