Fog Installer - Distro check
I have a VM environment at home with clean snapshots for various Linux distributions that I use for testing. I’ll be testing the fog installer on various distributions for each of the release candidates, and for updated and newer distributions in the future to see if it installs or not according to steps in the Wiki, and if not the steps I took to correct it.
Each of these tests will be from a clean snapshot that is fully updated with all standard updates. All tests use the command
./installfog.sh -yto use all defaults and install unattended.
@wayne-workman Well done on the stats. I think we have a good bunch of winners already.
Wanted to post a quick status of the testing’s streaks. You can see them in the link in my signature.
Currently, we have 4 Linux distributions that are neck & neck for the title of ultimate stability on the FOG Master branch.
We have a current streak of 40 for these Linux distributions:
- CentOS 7
- Debian 8
- Debian 9
- Ubuntu 16
We will see which Linux distribution pulls ahead in the long haul these coming months (and years). The race is ON!
FYI, lots of failures last night. On master branch, all Fedoras and Ubuntus failed, and then Ubuntu 17 failed on Dev branch - this is the only one that returned a log, it’s the ‘alter user’ mysql issue.
I am re-running the tests for the master branch to see if the same results happen or not.
Between 1:40 AM and 2:44 AM CST, the Arch team likes to make changes. I can tell because working branch runs first, and succeeded with Arch, but later dev-branch and master failed with the same error.
Arch bombed out this morning on all branches - something to do with NFS. This is typical for Arch - one day it’ll just bomb out hard across the board on the same item, a couple days later it’s fixed. Once it was related to mariadb problems, today it’s NFS.
Not trying to bash Arch here, there is a very small team working on Arch and they overall do a good job when you take into account their team size. Also stuff is going to break occasionally when you’re always making stuff better.
On a side note, the streak counts seem to be working.
@george1421 I think I already know which ones will be most stable. I’ll keep quiet though and we’ll see how it goes.
Very nice job!! After some time we should be able to identify the most stable OS for FOG installs. This will really come in handy when thinking about which OS we might support in the future.
Streak counts are now public.
Soon, the fog installer dashboard (see my signature) will have streak counts for each item. There will be a current success streak and a record success streak.
I’ve been wanting to do this for a while, I think it’ll be fun to watch the counts stack up. I’m monitoring the files for a couple days to be sure everything is working right before I put the values into the tables.
The issues appear to have been non-issues in the latest tests. SELinux was not set to permissive (my fault).
SElinux is disabled on those machines I suspect?!
I forgot to disable it on those two VMs… that is my bad. I’ll get that fixed.
@sebastian-roth I suspect it was my “fixing” code that is now “fixed” but causing a problem with latest updates. Just a guess. My fixing code just made it so fedora could install, and basically all it did was make sure the path it was looking for during startup existed. Now it looks like it’s the reverse, it’s trying to create a file that already exists, hence permission denied… (as it’s likely in use then too).
Seems like they had several issues with rpcbind over the last year or so: https://bugzilla.redhat.com/show_bug.cgi?id=1401561 and https://bugzilla.redhat.com/show_bug.cgi?id=1415496 (Not sure if those are related or not!)
@Wayne-Workman SElinux is disabled on those machines I suspect?!
Fedora 25 and 26 are not working with the installer right now, something to do with rpcbind.
I’ve not found the time to look at it. The failure logs are here if anyone want’s to take a peek:
Of course, I’m still testing the Linux distributions that FOG tries to support, it’s all automated now. You can find daily results in the dashboard link in my signature.
After re-running the tests, Ubuntu 16 appears fine. Must have been a fluke. Anyone want to donate a server? I’m using an old Poweredge r410.
Just so people are aware, I’m still testing the distributions. I’ve automated this & the results are available daily to the fog team only. I’ll post here with concerns.
Right now - Fedora 25 is broke, it’s a bug in the OS, nothing we can do about it. It’s related to rpcbind.
And it appears that starting last night something is wrong with the fog installation on Ubuntu 16. It’s related to the alter user command in MySQL.
Janurary 31st, 2017
Release Version: FOG 1.3.4
Debian 8.7 - fully updated - installed without issues.
Ubuntu 14.04 - fully updated - installed without issues
Ubuntu 16.04 - fully updated - installed without issues
CentOS 7 - fully updated - installed without issues per wiki instructions
Fedora 25 - fully updated -
* Setting up and starting RPCBind.............................Failed!
Below is the error log.
This is what shows in
journalctl -xeafter I run
systemctl restart rpcbind
-- Unit rpcbind.service has begun starting up. Jan 31 21:39:21 localhost.localdomain rpcbind: rpcbind: /run/rpcbind/rpcbind.lock: No such file or directory Jan 31 21:39:21 localhost.localdomain audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' Jan 31 21:39:21 localhost.localdomain systemd: rpcbind.service: Main process exited, code=exited, status=1/FAILURE Jan 31 21:39:21 localhost.localdomain systemd: Failed to start RPC Bind. -- Subject: Unit rpcbind.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpcbind.service has failed. -- -- The result is failed. Jan 31 21:39:21 localhost.localdomain systemd: rpcbind.service: Unit entered failed state. Jan 31 21:39:21 localhost.localdomain systemd: rpcbind.service: Failed with result 'exit-code'.
Also have tried uninstalling
rpcbind, the service still will not restart.
December 30th, 2016
Release Version: FOG 1.3.0
There is a minor hiccup in the FOG 1.3.0 installer that causes problems with detecting the router address on Arch, Fedora 24, Fedora 25, CentOS 7, Debian 8, and Ubuntu 16.04. While using the
-yargument of the installer, most of these distributions will go into an infinite loop on a fresh installation. They will install without the
-yargument but you will need to answer
nfor setting a router address or type in the actual router address when it asks. Ubuntu doesn’t seem to loop for me but still the router address is wrong in the settings.
There is a workaround for all of the distributions for using the
-yargument. You would simply fill the
routeraddressvariable manually while you start the installer. My router address is 10.0.0.1 thus the answer is:
routeraddress=10.0.0.1 ./installfog.sh -y
You can use this method for a successful unattended installation.
Other than that, everything appears to be fine.
@Quazz Yes. Under the working-1.3.0 branch of course.