Been using FOG for about 3 years now. In fact in got me a job out of college!
I used to be under the user mecsr, but I passed that baton and am setting up a new fog server at a new workplace.
@Sebastian-Roth Reading through your linked post I see that it is indeed the same version that is causing the error there. And when re-running the installer it would restart the service and that probably fixes the issue.
So I guess I’m in the same boat waiting for centOS to fix the rpcbind package.
Sorry for the duplicate post, didn’t come across that one in my search
@Sebastian-Roth said in random image share can't mount during image process error on 1.4.2:
rpm -qa | grep rpcbind
rpcbind-0.2.0-38.el7_3.1.x86_64
Random can’t mount image share error after a few days.
I can run normally and without issue and suddenly I get a can’t mount images share when I image a machine. If I rerun the latest installer on the server and the node it gets back up and running just fine. I haven’t touched anything on the server it just randomly does this. Perhaps it’s something I did a long time ago, or maybe it’s happening to someone else and it’s a bug as this didn’t happen before.
It’s done this twice now since the original update to 1.4.2.
Thought the first was a fluke, but then it just happened again.
I did check all the usual suspects like .mntcheck and permissions on the folders and /etc/exports and all looked as it should. So Any help would be appreciated.
Thanks,
-JJ
What else is the windows server you’re using do?
Maybe it’s simpler to just change it to a linux server?
Then using it as a storage node is nice and supported.
When imaging an intel compute stick it doesn’t expand the drive after imaging. This is a MMC embedded flash storage type device. Expanding it manually isn’t that big a deal but it would be nice to not worry about it. There was also a case of this happening on a esxi vmware vm recently, but the MMC is a more persistent issue.
@K.Hays Are you using the latest versions of the ipxe files?
Because if you are try some older ones, like the ones labeled -7156 if you don’t have any sitting around.
I was imaging a compute stick today and it wouldn’t boot into fox with the latest ipxe.efi file, it did work with an older one I still had that usb drive from a year ago when I wrote this post. I’ve had varying results of newer ipxe.efi files and the efi shell boot method.
If the 7156 versions provided don’t work let me know and I’ll post the ones that are working for me right now.
@JJ-Fullmer Well it wasn’t actually phpipam that was slowing it down.
I had some ssl logs running for a website running on that server. It was tracking access logs for every access of the ssl cert and site. Which was also adding up to over 400 GB of logs. I changed the apache configuration of the site to log much less. That solved the problem. So again, nothing wrong with zstd. Just wanted to have the right answer in case someone else happens to see a constant 5-8 Mbps transmit and receive on a storage node.
Figured I should add, my speed issue was related to running PHPIPAM (a ip management tool) on my storage node server. It was slowing my image deploys down, not the zstd. It’s crazy fast at compression level 19 now.
@Junkhacker Well deploy is where speed is more important to me.
I gave 19 a go with the split and it actually had some weird error on the first deploy, I was in a meeting in my office so I didn’t really get to see the whole thing, but then it auto-retried the task and worked proper the second time. 2 minutes 18 seconds. The image size on the server seems to still be bigger than pigz was with 7.1 GB for a 15 GB image instead of 6.7 G for the old 18 GB image. But, don’t need to be too picky about it.
@Tom-Elliott Two minor issues I noticed. The first time (the slow deploy) I queued the image after doing a full host inventory via the pxe boot on the host. I had not specified any snapins and it randomly added like 10 of them. The second time I queued it from the gui and deleted the snapins and the problem didn’t repeat itself. However in both instances the drive didn’t resize itself.