Posts made by nrg

@Middle said in Very slow cloning speed on specific model:

nvme set-feature -f 0x0c -v=0 /dev/nvme0

so the solution was to put that under fog general settings?? I tried and it didn’t work on my end.

I’m also facing the same issue. I have 5 hp 840 g6 and only 4 of them has this issue. One of them does not have this issue. They’re all identical laptop in hardware and software. even the bios is the same.

I can fog to the rest of my 800 computers perfectly fine at normal speed. It’s just these new G6.

disk drive: Samsung MZVLB256HAHQ-000H1
NIC: Intel Ethernet I219-LM
bios ver: R70 Ver. 01.03.04 11/06/2019

FOG server: 1.5.6 on ubuntu 18.04.3 lts

@tom-elliott not sure how the fog version got mixed… I just ran the git pull and rerun the installfog.sh in command to update to latest in dev-branch.
maybe something in 1.5.0 rc10 that I had that screwed it up going to 1.5.4??
btw, I’ve been running 1.4.4 and been updating in command line ever since.

coming in this morning, the replicator is looking normal. the node usage pie chart is normal compare to the main server chart. before it would show 20-40% as it was constantly deleting and replicating. replicator logs are saying No need to sync which is good.

Interesting to see others in here experienced the same issue updating to 1.5.4

I appreciate the offer but I have to get these computer labs up and running soon. Love the support and fog has been a life saver.

i went back to 1.5.0 final release. so far it has fixed my issue. imaging is back to normal. node is now copying things over and wont know until tomorrow if it fixed the cycle of replicating. imaging 10 clients right now and the web gui is smooth. iPxe boot is back to normal too. the command line screen during imaging doesn’t sit at deleting mbr/gpt anymore. new feature??

current Load Average 18.16, 10.60, 4.86

with 1.5.4, loads were in the high 19 across all three. constantly staying around 9 while nothing was imaging.

will wait next year for 1.8.0 =D. anyways thanks.!

@george1421 Yes, it’s an exact identical hardware/software as my master fog server. I disabled the node server and there’s still an unresponsive issue with the main server. the repeated replicating was giving the main server a load time of 10. After shutting it off and disabling it, the average load of the main server was normal. Then I tried imaging up to 10 computers and up to the 7th computer, the web GUI was unresponsive. The waiting in line slot message on the client computer stopped responding. I believe there’s a huge issue with this release.

will try the php tweaks then if that doesn’t work. will figure out a way to go back to 1.5.0 rc10. redo the node fresh.

edit:
i edit the memory to 256 but could not find “/etc/httpd/conf.d/fog.conf” anywhere to edit.

@george1421 will try it. but I think it might be an issue with my node. Going to rebuild my node (or disable it) to stop it from replicating over and over. Before 1.5.4 update, my node was stable with hard drive use of 70%. Now I can see it constantly deleting images because it says it’s not matching. it would go from 20%-40% hard drive usage use so it’s cycling through images that it think doesn’t match.
will report back.

I’m having the same exact issues ever since updating to 1.5.4.

server: 14.04 LTS ubuntu.

I had 1.5.0 rc10 and it was running smooth. I only updated because I was having issues with 1709 not restarting after getting a host name. I needed .10.16 client and the latest 1.5.3 had it.
Before, with 10 slots open, i could image all 10 computers with an average of 1.5gbp/min. now it’s barely holding at 200mbp/min on each client. the entire web GUI is unresponsive. I also have some computers queued up in line waiting for a slot to open and it would time out mid way.

I have a server node and updated both the main server and node to 1.5.4 and ever since, it’s been busy replicating over and over.

Also the PXE boot bz img part takes much longer to do. I’m going to go back to 1.5.0 rc10

how would I go about downgrading?

Re: Can’t image from storage node
Not sure what happened but it seems to be working now. Well imaging from the storage node works when I tried it last week in another group of computers from a separate image that’s stored on the server. I saw the storage node IP on the client computer when imaging.
I have not touched or updated neither the main or node servers.
I have not tried to image from LABGEN from storage node. so 50% working from the main issue. Will follow up or capture a new iamge for LABGEN image soon.

thank you everyone!

@sebastian-roth said in Can’t image from storage node:

memtest

did a badblock test on all three sda partition on the storage node. no errors.

administrator@31-FOGNODE1:~$ sudo badblocks -v /dev/sda1
Checking blocks 0 to 524287
Checking for bad blocks (read-only test): done                                                       
Pass completed, 0 bad blocks found. (0/0/0 errors)
administrator@31-FOGNODE1:~$ sudo badblocks -v /dev/sda2
Checking blocks 0 to 483710975
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)
administrator@31-FOGNODE1:~$ sudo badblocks -v /dev/sda3
Checking blocks 0 to 4149247
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)

btw, i have my fog storage node running Ubuntu EFI installed. could that be an issue?
also, i couldn’t find memtest in the grub menu. i also tried putting it back and installing it without success. guess im SOL.

don’t think there’s anything wrong with the client I tried to image from the storage node. Reason, I was able to image from the master node just fine.

everyone, thank you for all your efforts

edit: I ran memtest86 and there is no errors. pass perfectly fine. so no hard drive issue or memory issue… dont know whats wrong =\

@sebastian-roth

master node:

822a5ed907cb41c30631dc6c160f243f  /images/LABGEN/d1.fixed_size_partitions
dc9ea3b81f67be37d7d63b297dec1941  /images/LABGEN/d1.mbr
69d95b8f7a25b7cb62095f3cd358e55c  /images/LABGEN/d1.minimum.partitions
b293627989626a35e2d6631747b45faf  /images/LABGEN/d1.original.fstypes
d41d8cd98f00b204e9800998ecf8427e  /images/LABGEN/d1.original.swapuuids
72c1e188a1f4c3594d7712c41657d227  /images/LABGEN/d1.original.uuids
2c72b745cb040e72a8f0de0cabc18120  /images/LABGEN/d1p1.img
9fa1331ab13e0b4f0798289b26752109  /images/LABGEN/d1p2.img
2021c4a6186077ef7e52320ff7718ef5  /images/LABGEN/d1p3.img
1fd435efeeb55203f8277a883ff1c17c  /images/LABGEN/d1.partitions

Storage Node:

822a5ed907cb41c30631dc6c160f243f  /images/LABGEN/d1.fixed_size_partitions
dc9ea3b81f67be37d7d63b297dec1941  /images/LABGEN/d1.mbr
69d95b8f7a25b7cb62095f3cd358e55c  /images/LABGEN/d1.minimum.partitions
b293627989626a35e2d6631747b45faf  /images/LABGEN/d1.original.fstypes
d41d8cd98f00b204e9800998ecf8427e  /images/LABGEN/d1.original.swapuuids
72c1e188a1f4c3594d7712c41657d227  /images/LABGEN/d1.original.uuids
2c72b745cb040e72a8f0de0cabc18120  /images/LABGEN/d1p1.img
9fa1331ab13e0b4f0798289b26752109  /images/LABGEN/d1p2.img
2021c4a6186077ef7e52320ff7718ef5  /images/LABGEN/d1p3.img
1fd435efeeb55203f8277a883ff1c17c  /images/LABGEN/d1.partitions

The logs look fine.
[12-01-17 8:10:21 pm] | LABGEN: No need to sync d1p3.img file to 31-FOGNODE1
[12-01-17 8:10:21 pm] | LABGEN: No need to sync d1p3.img file to 31-FOGNODE1
[12-01-17 8:10:21 pm] | LABGEN: No need to sync d1p2.img file to 31-FOGNODE1
[12-01-17 8:10:21 pm] | LABGEN: No need to sync d1p2.img file to 31-FOGNODE1
[12-01-17 8:10:20 pm] | LABGEN: No need to sync d1p1.img file to 31-FOGNODE1
[12-01-17 8:10:20 pm] | LABGEN: No need to sync d1p1.img file to 31-FOGNODE1
[12-01-17 8:10:20 pm] | LABGEN: No need to sync d1.partitions file to 31-FOGNODE1
[12-01-17 8:10:20 pm] | LABGEN: No need to sync d1.partitions file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.original.uuids file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.original.uuids file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.original.swapuuids file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.original.swapuuids file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.original.fstypes file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.original.fstypes file to 31-FOGNODE1
[12-01-17 8:10:19 pm] | LABGEN: No need to sync d1.minimum.partitions file to 31-FOGNODE1
[12-01-17 8:10:18 pm] | LABGEN: No need to sync d1.minimum.partitions file to 31-FOGNODE1
[12-01-17 8:10:18 pm] | LABGEN: No need to sync d1.mbr file to 31-FOGNODE1
[12-01-17 8:10:18 pm] | LABGEN: No need to sync d1.mbr file to 31-FOGNODE1
[12-01-17 8:10:18 pm] | LABGEN: No need to sync d1.fixed_size_partitions file to 31-FOGNODE1
[12-01-17 8:10:18 pm] | LABGEN: No need to sync d1.fixed_size_partitions file to 31-FOGNODE1
[12-01-17 8:10:17 pm] | Image Name: LABGEN

for the LABGEN image, it was first captured Jun 15th 2016 on the master node and it works fine.
the LABGEN image was replicated on the storage node on Nov 9th 2017. The reason why you see Dec 1st on the two files on the storage node is because I manually deleted d1p3.img on the storage node and had the masternode replicate the file again. I knew that it runs the replicator service every 30mins? so if the server did not see the file, it would replicate itself again. that explains the date.

NOTE: WTF? why does the logs show duplicated lines? bug?

This is from the storage node 10.31.1.16:

total 18148960
drwxrwxrwx  2 fog fog         4096 Dec  1 09:07 .
drwxrwxrwx 15 fog root        4096 Nov  9 15:14 ..
-rwxrwxrwx  1 fog fog            4 Dec  1 09:07 d1.fixed_size_partitions
-rwxrwxrwx  1 fog fog      1048576 Nov  9 15:14 d1.mbr
-rwxrwxrwx  1 fog fog          629 Nov  9 15:14 d1.minimum.partitions
-rwxrwxrwx  1 fog fog           15 Nov  9 15:14 d1.original.fstypes
-rwxrwxrwx  1 fog fog            0 Nov  9 15:14 d1.original.swapuuids
-rwxrwxrwx  1 fog fog          215 Nov  9 15:14 d1.original.uuids
-rwxrwxrwx  1 fog fog     11614954 Nov  9 15:14 d1p1.img
-rwxrwxrwx  1 fog fog      2171231 Nov  9 15:14 d1p2.img
-rwxrwxrwx  1 fog fog  18569660631 Dec  1 09:10 d1p3.img
-rwxrwxrwx  1 fog fog          629 Nov  9 15:14 d1.partitions

this is from the master node 10.31.1.15:

total 18148960
drwxrwxrwx  2 fog root        4096 Jun 15  2016 .
drwxrwxrwx 15 fog root        4096 Aug 17 12:41 ..
-rwxrwxrwx  1 fog root           4 Jun 15  2016 d1.fixed_size_partitions
-rwxrwxrwx  1 fog root     1048576 Jun 15  2016 d1.mbr
-rwxrwxrwx  1 fog root         629 Jun 15  2016 d1.minimum.partitions
-rwxrwxrwx  1 fog root          15 Jun 15  2016 d1.original.fstypes
-rwxrwxrwx  1 fog root           0 Jun 15  2016 d1.original.swapuuids
-rwxrwxrwx  1 fog root         215 Jun 15  2016 d1.original.uuids
-rwxrwxrwx  1 fog root    11614954 Jun 15  2016 d1p1.img
-rwxrwxrwx  1 fog root     2171231 Jun 15  2016 d1p2.img
-rwxrwxrwx  1 fog root 18569660631 Jun 15  2016 d1p3.img
-rwxrwxrwx  1 fog root         629 Jun 15  2016 d1.partitions

You can see the date change of d1p3 on the storage node because I deleted the file and had fog replicate it again today. replicating works, mysql and ftp works.

I believe fog is designed to jump to the storage node on the 2nd computer when imaging.
reading through the wiki, it says that computer 1 = MasterNode, computer 2 = Storage node.
I can see the IP of the storage node on the 2nd computer in the partsclone screen.

kernal parameter

master node/server: fog 1.5.0-RC-10
os: ubuntu 14.04 LTS

storage node: fog 1.5.0-RC-10
os: ubuntu 14.04 LTS

both server hardware and software are identical.

master server images perfectly fine and have been using it all year long. Just recently added the storage node and it replicated all the images fine according to the logs. Then when trying to image two computer, the 2nd computer one fail with an error. It connects to the storage node, pulls the image and does the calculating bitmap and right when it gets to d1p3.img file it says “read Error: no such file or directory”

I check the folder and the file is there. I believe it’s a file integrity issue.

pigz: skipping: <stdin>: corrupt -- invalid deflate data (invalid code lengths set)  pigz: abort: internal threads error```

I get that error in the partsclone window on computer 2.
then a warning message shows
read ERROR:No such file or directory
args Passed: /images/LABGEN/d1p3.img* /dev/sda3

then I get the ntfs volume failed error but that’s because it didn’t image sda3 correctly.

i reboot computer two and set it to image by itself so it can talk to the master node and it images perfectly on the same selected image.

I saw this thread: https://forums.fogproject.org/topic/6318/image-file-integrity/6 but cannot understand its solution. maybe its a tool to replicate and do a checksum after?

thanks.

@Wayne-Workman My main server was 1.5.0 RC9 and my node was 1.5.0 RC10 which is why it didn’t work. I did update my main server after Jgallo mentioned it and has resolved most of the issues.

I think the “(“A valid database connection could not be made” 1.5.0-RC-10)” might be a bug. I’ve found two other threads that mention the same thing but their solution didn’t work on my end. As long as the server is replicating, i’m all good.

please marked as solved thanks.

@JGallo
( image url)

check this out. see that error under kernel? well it looks like the entire info is on the wrong row.
storage node name is right, the IP is right, the “a valid database…” message shouldn’t be there, so now the Kernal 3.13…" message is pushed down a row. uptime is on the wrong row. So i think it’s an bug in the php code somewhere. the node works and connects and replicates fine. I’ve checked the settings you mention and dont see an issue.

max connection is 151, show status has a current connetion of 37, max used connection of 1 and threads connected of 1. everything else is 0.

will read the other thread. both node and main server are 1.5.0-rc10.

thank you, you’ve been a big help.

ah thank you for that.
updated now and my main fog sees the node
but it still gives this message under the storage node disk usage drop down menu: “A valid database connection could not be made”@@general"
It must be a bug when reading for the kernal info. But i’m able to see the node’s disk useage correctly.

http://fognodeIP/fog still shows error 500 but that might be by designed. in 1.2.0 it showed a small text message.

other than that. it’s replicating! thank you. solved!

Main fog server running perfectly fine on ubuntu 14.04.5 LTS with FOG 1.5.0-RC-9

i’m trying to setup a fog node using another ubutu 14.04 LTS server. I first setup fog 1.2.0 and it ran setup perfectly fine. had the mysqluser (fogstorage) and pass (fs********) setup correctly. I was able to even go to the (fog node ip)/fog and it would show the little message that there’s no GUI. OK good, up and running but not replicating. I figured that my main server is 1.5.0 and my node is 1.2.0; which is why it wont work together.

then on the fog node, I did the update to trunk and it updated to 1.5.0-RC-10 and now it the node doesn’t function.

Under my main fog configuration, it says "FOGNODE1 FOG version (“A valid database connection could not be made” 1.5.0-RC-10)
I try to access the node IP/fog and it gives me a error 500. and the URL goes to /fog/management/index.php?node=schema

I check the apache2 error.log and find this:

[Wed Nov 08 08:55:59.852106 2017] [php7:error] [pid 698] [client 10.*.*.*:49558] PHP Fatal error:  Uncaught Error: Call to a member function lastInsertId() on boolean in /var/www/html/fog/lib/db/pdodb.class.php:447\nStack trace:\n#0 /var/www/html/fog/lib/fog/fogcontroller.class.php(460): PDODB->insertId()\n#1 /var/www/html/fog/lib/fog/hookmanager.class.php(63): FOGController->save()\n#2 /var/www/html/fog/lib/fog/fogpage.class.php(219): HookManager->processEvent('PAGES_WITH_OBJE...', Array)\n#3 /var/www/html/fog/lib/pages/schemaupdaterpage.class.php(39): FOGPage->__construct('')\n#4 /var/www/html/fog/lib/fog/fogpagemanager.class.php(381): SchemaUpdaterPage->__construct()\n#5 [internal function]: FOGPageManager->{closure}('/var/www/html/f...')\n#6 /var/www/html/fog/lib/fog/fogpagemanager.class.php(386): array_map(Object(Closure), Array)\n#7 /var/www/html/fog/lib/fog/fogpagemanager.class.php(79): FOGPageManager->loadPageClasses()\n#8 [internal function]: FOGPageManager->__construct()\n#9 /var/www/html/fog/lib/fog/fogbase.class.php(481): ReflectionClass->newInstanceArgs(Array)\n#10 /var/www/html/fog/management/index.php(2 in /var/www/html/fog/lib/db/pdodb.class.php on line 447``

I check the fogreplicator.log and it shows that it’s not online.
/var/log/fog/fogsnapinrep.log

[11-08-17 5:01:21 pm] FOGNODE1 Server does not appear to be online.
[11-08-17 5:11:21 pm] * Starting Snapin Replication.
[11-08-17 5:11:21 pm] * We are group ID: 1. We are group name: default
[11-08-17 5:11:21 pm] * We are node ID: 1. We are node name: DefaultMember
[11-08-17 5:11:21 pm] * Attempting to perform Group -> Group snapin replication.
[11-08-17 5:11:21 pm] | Replicating ssl less private key
[11-08-17 5:11:21 pm] * Found Snapin to transfer to 1 node
[11-08-17 5:11:21 pm] | File Name: ssl/fog.csr
[11-08-17 5:11:21 pm] FOGNODE1 Server does not appear to be online.

I edit my server ip and host name alittle for the sake of security.

with 1.2.0, PHP is 5. with 1.5.0 PHP is 7. is it a PHP error?

Under the storage node settings when adding, the IP, username and password is all correct.

help… thanks.

Thank you Tom for the explanation. I will redo the image on a 128gb ssd from now on with my setup. consider this solved

Server

• FOG Version: 1.4.2 SVN 6074
• OS: Ubuntu 14.04 LTS

Client

• Service Version: 0.11.12
• OS: win10 enterprise build 1703

Description

Image created on a 120GB SSD, syspreped, setupcomplete command, and has no unallocated space on the image.
When the image is deployed to a client computer with 128GB SSD hard drive, there seem to be a random 38MB unallocated space. I did not notice this until I used the same image on a 1TB SSD computer. It showed a random 6GB of unallocated space. So there must be a bug where it’s not imaging and resizing 100% of the drive.

I did find this issue on most of my client computers. I’m manually extending the hard disk to get rid of the unallocated space. I did not see this issue before going to 1.4.2 on my other images.

i always make my image on 120gb ssd because I have multiple computers with 128gb and 256gb ssd.

The image is set to
ImageType ID: 1 Name: Single Disk - Resizable
Parts clone.
partition everything. compression 6

thank you.

When I select Network Printer, it doesn’t go to the network printer menu. I tried this in chrome and IE. It doesn’t recognize my selection from the drop down menu.

with network printer, I only need to add a name and the print server location. ie: \print-server\prnt-rm101\

I’ve used this before and each of those selection would have different options when selected. It looks like all the selection are stuck on TCP/IP printer menu.

under stable 1.2.0, the printer management worked perfectly fine. Now with trunk, I’m not able to create a network printer. When I select the menu under the drop-down box under create new printer. it wont switch from TCP/IP Printer. It just pops up a message saying “printer type changed to: Network”
But the settings below are still on TCP/IP Printer.

Trying to point a group of computers to a print server for a classroom. Not using tcp/ip printers.

Help?

Trunk 8179