Posts made by neodawg

I discovered this bug too when updating. My solution was just to create a group of all computers and then update the default AD credentials under Fog Settings. Then I just cleared it and repopulated the fields in Fog Settings. Then used the group of all and modified it for all computers at once. I even used the same password as I was.

My speculation is that the new password encryption measure put in are breaking it, the length when the password is shown is way off of what it should be when its updated correctly.

It appears the github download link is broken on the fogproject.org website? Is this an error or is this because 1.5.1 has a big bug? I realize I can pull it from a github zip, I just always use the tar.gz files in my install script.

Thanks,

@george1421 Yep, I have had the best luck with GRUB vs SANBOOT, probably not as fast but works.

Thanks for the info, we can close this case!

@george1421 Thanks, that is what I did.

So for legacy its set to GRUB and EFI its set to REFIND_EFI

@george1421 Thanks, that worked. I see there is more settings under the system for exit types, so I just changed the whole EFI part of the server to REFIND_EFI. So we will see what that breaks.

Server

• FOG Version: 1.4.4
• OS: CentOS 7

Client

• Service Version: NA
• OS: NA

Description

Fog iPXE screen is having a chain loading issue when trying to boot from the local disk. They get the error and then reboot in 10 seconds and then just keep looping forever.

Computer models with issue are Dell Latitude 5580 and 5289

I am using GRUB as the Exit type in FOG.

Computers are UEFI booting to iPXE.

Here is a shot of the error. Picture

Thanks,

Here is the errors from the FOG client.

7/14/2017 11:44 AM Service Sleeping for 334 seconds
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 7/14/2017 11:49 AM Middleware::Response Success
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&mac=F8:59:71:B0:43:44|F8:59:71:B0:43:43|F8:59:71:B0:43:47&newService&json
 7/14/2017 11:49 AM Middleware::Response Invalid host
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?clientver&newService&json
 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?newService&json

 7/14/2017 11:49 AM Service Creating user agent cache
 7/14/2017 11:49 AM Middleware::Response Module is disabled globally on the FOG server
 7/14/2017 11:49 AM Middleware::Response No Printers
 7/14/2017 11:49 AM Middleware::Response Module is disabled globally on the FOG server

Hello,

Server version is 1.4.4
Using EFI PXE booting rather than legacy

I am having issue where using a USB-C dock with NIC in it to image. The problem is that when you register and image the computer it uses a4:4c:c8:aa:9e:c5 MAC, which is fine and they image fine.

When its done imaging and windows boots, then the dock uses the ‘correct’ MAC d4:81:d7:8a:44:64 that is actually printed on it and is actually associated with the dock and not the laptop, which is its own problem.

So I thought a solution was to approve the wireless card MAC and let the FOG Client use that MAC to identify and join the domain, the problem is that it doesn’t unless I make it the primary MAC, which then breaks the iPXE part of imaging fog. So I cant have both working.

So my question is what is the point of the additional MACs if FOG cant use them to identify and perform tasks using other MAC than the primary one? I thought that was the point so that we didn’t end up with ‘duplicate’ clients in FOG.

I understand that if the MAC is NOT approved it shouldn’t be able to do any functions, however once approved why cant it?

Thanks,

I heard back from the local tech with the CentOS 7 box and downgrading rpcbind fixed the issue on that server as well. I guess we will have to wait until RedHat/CentOS fixes the rpcbind package

@Sebastian-Roth and @george1421

Yes, the service will start and run, but shortly after a client tries to connect the service will die.

The link you listed sound exactly what is happening, however i didn’t test different versions of NFS protocol, ie v3 vs v4.

On one of the fog servers the tech was able to actually image one computer successfully and then the next computer it failed on, because the rpcbind service had died.

So for fun or insanity, i downgraded rpcbind.x86_64 0:0.2.0-13.el6_9 to rpcbind.x86_64 0:0.2.0-13.el6 on the CentOS 6 box I am local to and I think that may have fixed the issue. The image is currently uploading in debug mode, going to try pushing it out as soon as its done.

The other thing I haven’t ruled out is having open-vm-tools installed. I dont know why this would break things but I read something somewhere on some forum about it.

I did yum downgrade rpcbind on the CentOS 7 box and the services are still running, but the local tech hasnt tried imaging again yet.

Resolving Dependencies
--> Running transaction check
---> Package rpcbind.x86_64 0:0.2.0-38.el7 will be a downgrade
---> Package rpcbind.x86_64 0:0.2.0-38.el7_3 will be erased
--> Finished Dependency Resolution

EDIT: it appears this process fixed the CentOS 6 box, it was able to deploy the same image after an immediate capture of it.

@george1421

Sorry its not the the NFS process its the rpcbind process, NFS stays active until I restart it, which will fail if I dont restart rpcbind first.

@george1421

No, I dont see much that is any help to me, I have tried Googling most all of these errors

Jun  5 13:39:55 fog systemd: Stopped NFS server and services.
Jun  5 13:39:55 fog systemd: Stopping NFS Mount Daemon...
Jun  5 13:39:55 fog systemd: Stopping NFSv4 ID-name mapping service...
Jun  5 13:39:55 fog systemd: Stopped NFSv4 ID-name mapping service.
Jun  5 13:39:55 fog rpc.mountd[16751]: Caught signal 15, un-registering and exiting.
Jun  5 13:39:55 fog systemd: Stopped NFS Mount Daemon.
Jun  5 13:39:57 fog systemd: Starting Preprocess NFS configuration...
Jun  5 13:39:57 fog systemd: Started Preprocess NFS configuration.
Jun  5 13:39:57 fog systemd: Starting NFSv4 ID-name mapping service...
Jun  5 13:39:57 fog systemd: Starting NFS Mount Daemon...
Jun  5 13:39:57 fog systemd: Started NFSv4 ID-name mapping service.
Jun  5 13:39:57 fog rpc.mountd[22526]: Version 1.3.0 starting
Jun  5 13:39:57 fog systemd: Started NFS Mount Daemon.
Jun  5 13:39:57 fog systemd: Starting NFS server and services...
Jun  5 13:39:57 fog kernel: NFSD: starting 90-second grace period (net ffffffff81aa0e80)
Jun  5 13:39:57 fog systemd: Started NFS server and services.
Jun  5 13:39:57 fog systemd: Starting Notify NFS peers of a restart...
Jun  5 13:39:57 fog sm-notify[22545]: Version 1.3.0 starting
Jun  5 13:39:57 fog sm-notify[22545]: Already notifying clients; Exiting!
Jun  5 13:39:57 fog systemd: Started Notify NFS peers of a restart.
Jun  5 13:42:50 fog systemd: rpcbind.service: main process exited, code=killed, status=6/ABRT
Jun  5 13:42:50 fog systemd: Unit rpcbind.service entered failed state.
Jun  5 13:42:50 fog systemd: rpcbind.service failed.
Jun  5 13:43:29 fog xinetd[19177]: START: tftp pid=23930 from=172.20.33.226
Jun  5 13:43:29 fog in.tftpd[23931]: tftp: client does not accept options
Jun  5 13:43:29 fog in.tftpd[23932]: Client 172.20.33.226 finished undionly.kpxe
Jun  5 13:43:36 fog in.tftpd[23935]: Client 172.20.33.226 finished default.ipxe
Jun  5 13:43:46 fog systemd: Starting RPC bind service...
Jun  5 13:43:46 fog systemd: Started RPC bind service.
Jun  5 13:45:37 fog in.tftpd[24294]: tftp: client does not accept options
Jun  5 13:45:37 fog in.tftpd[24295]: Client 172.20.36.5 finished undionly.kpxe
Jun  5 13:45:44 fog in.tftpd[24315]: Client 172.20.37.161 finished default.ipxe
Jun  5 13:57:50 fog systemd: rpcbind.service: main process exited, code=killed, status=6/ABRT
Jun  5 13:57:50 fog systemd: Unit rpcbind.service entered failed state.
Jun  5 13:57:50 fog systemd: rpcbind.service failed.
Jun  5 13:58:08 fog systemd: Starting RPC bind service...
Jun  5 13:58:08 fog systemd: Started RPC bind service.
Jun  5 14:00:21 fog in.tftpd[28625]: tftp: client does not accept options
Jun  5 14:00:21 fog in.tftpd[28626]: Client 172.20.33.226 finished undionly.kpxe
Jun  5 14:00:28 fog in.tftpd[28671]: Client 172.20.33.226 finished default.ipxe
Jun  5 14:01:01 fog systemd: Started Session 3 of user root.
Jun  5 14:01:01 fog systemd: Starting Session 3 of user root.
Jun  5 14:05:07 fog yum[29343]: Installed: perl-Encode-Detect-1.01-13.el7.x86_64
Jun  5 14:05:07 fog yum[29343]: Installed: perl-IO-Tty-1.10-11.el7.x86_64
Jun  5 14:05:28 fog kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
Jun  5 14:12:50 fog systemd: rpcbind.service: main process exited, code=killed, status=6/ABRT
Jun  5 14:12:50 fog systemd: Unit rpcbind.service entered failed state.
Jun  5 14:12:50 fog systemd: rpcbind.service failed.

@george1421

[root@fog ~]# cat /etc/exports
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

I should mention I also have several other fog servers out there running CentOS 7 and running versions of fog from 1.3.x to 1.4.1 and they are working fine, but I have not done a yum update -y on them recently.

Yep, i did the same thing. Cept I did a yum update -y on the server.

The server i am working on is running on vmware.

the firewall and selinux and both stopped and disabled, and rebooted.

Server

• FOG Version: 1.4.2
• OS: CentOS 6 and 7

Client

• Service Version: latest
• OS: Windows 10

Description

Having an issue where I cant upload or download any images. I have narrowed down the issue to being that rpcbind service keeps crashing on the OS, doesnt matter if its CentOS 7 or 6. the issue is the same.

I have dug in the logs and cant find much or things i have found dont seem to fix the issue.
The service dies on the server with a very generic error:

CentOS 6 = rpcbind dead but pid file exists

CentOS 7 = ● rpcbind.service - RPC bind service
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: enabled)
   Active: failed (Result: signal) since Mon 2017-06-05 14:27:50 CDT; 1h 5min ago
  Process: 1138 ExecStart=/sbin/rpcbind -w $RPCBIND_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 1139 (code=killed, signal=ABRT)

Jun 05 14:15:23 fog. systemd[1]: Starting RPC bind service...
Jun 05 14:15:23 fog. systemd[1]: Started RPC bind service.
Jun 05 14:27:50 fog. systemd[1]: rpcbind.service: main process exited, code=killed, status=6/ABRT
Jun 05 14:27:50 fog. systemd[1]: Unit rpcbind.service entered failed state.
Jun 05 14:27:50 fog. systemd[1]: rpcbind.service failed.

I even went as far as to reformat the server and setup fog from scratch again, I have several servers out there and I think I have ruled the issue down to something from yum update that is breaking fog or something, I assume it something with nfs server or rpcbind.

These are the errors i see on the client, this is in a capture-upload mode, doesn’t matter if its upload or deploy, errors still the same.

This is what i see on the server:

root@fog ~]# service rpcbind restart
Stopping rpcbind:                                          [FAILED]
Starting rpcbind:                                          [  OK  ]
[root@fog ~]# service rpcbind status
rpcbind (pid  8011) is running...
[root@fog ~]# service rpcbind status
rpcbind (pid  8011) is running...

After a little while and some trial and error on fog clients i get the errors listed above.

Here is a pic of the client side: picture

Good to know… Thanks

Just wondering if fog automatically resets the encryption data for the host when deploying an image or if that needs to be done manually. If it isn’t done automatically it, is there a reason it isn’t?

Just curious what will happen to the existing computers that would happen to have duplicate MACs between hosts? Will it wipe out any dups after the first host that uses it? Or does it leave it be until its host item is manipulated in some way (changed).