@Greg-Plamondon said in FOG User Tracking -Search:
what repo is 1.6 in?
should be able to do a git checkout working-1.6
, if I recall.
@Greg-Plamondon said in FOG User Tracking -Search:
what repo is 1.6 in?
should be able to do a git checkout working-1.6
, if I recall.
Newly installed and updated Ubuntu 18.04 box throws a couple of error messages during fog installation
From foginstall.log
:
* Setting up and starting TFTP Server.........................Too few arguments.
Too few arguments.
OK
* Setting up and starting VSFTP Server........................OK
Results in TFTP daemon not restarted after configuration change. Running configuration points to directory /var/lib/tftpboot. Configuration is corrected on service or server restart.
Traced to functions.sh#L458-L459
systemctl is-active --quiet && systemctl stop tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1 || true
systemctl is-active --quiet && true || systemctl start tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1
Probably should be:
systemctl is-active --quiet tftpd-hpa && systemctl stop tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1 || true
systemctl is-active --quiet tftpd-hpa && true || systemctl start tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1
I believe you are misunderstanding that result from df
. That line says that there is a volume of size 88GB with a filesystem currently housing 33MB of data that is mounted under the directory /Images
. Separating the content of /images (where FOG keeps the captured image data by default) is a common practice, but in your case it seems there may be a capital ‘i’ in the directory name. If you installed FOG without reusing the previous settings, it may be the case that you are not seeing all the space that was available to you previously due to this naming mismatch. If you want to use this volume for storing you images, you can change the location of the image store to /Images
in your storage node configuration.
@dylan123
typically mariadb defaults to /var/lib/mysql/
for the data files.
It looks like your boot partition may be full. While this wouldn’t necessarily cause you issues with day to day operation, it can play havoc with apt if you have a kernel update in the queue when running updates. I have had more than several update sequences bork due to this, and depending on where it borked, I could see packages that have a number of dependencies such as mariadb being left in a non-startable state. I would suggest doing an apt autoremove
to remove the unneeded kernels, but be aware you may need to manually give apt a little room in /boot by manually deleting an old kernel or two then running a apt -f install
(I think) to cleanup from the dirty state. I believe Ubuntu generally keeps the current and one or two previous kernels by default.
If you want to see if this might be an issue prior to digging around, a apt upgrade
should complain at you.
@Sebastian-Roth Nice call.
Installation, both under the auspices of a sudo su -l
in terminal and as root
through ARD, appear to be behaving after a manual kick to launchctl. The newest iMacs don’t seem to be triggering a pending host notification, but they are logging the communication on the client and in the apache logs. I suspect there might be too many mac addresses, but I am thinking that is a Monday problem.
@mikeakin44 and what happens if you make the same boot order change on your reference machine?
If you would please, answer the following:
Which boot method are you using (Legacy BIOS or UEFI)?
What is the boot order, or boot orders if there are separate sequences for normal, automatic, and error?
What are the settings for the image type and the partition targeted?
What is the content of the d*.partitions files in the folder for the acquired image?
hmm, must have missed that one. Last commit I see on zazzles was for some library updates. Don’t see any specific references to service stops on 1903 in the commit notes , but could be related. Don’t see any commit notes regarding service stops on fog-service either.
Were you thinking of https://forums.fogproject.org/topic/13704/fog-service-quits-running ?
@Sebastian-Roth I have a couple units I can probably play with and might be able to find a little time to cobble something together.
Installing the release msi interactively and targeting a non-https FOG installation is successful and functions as expected on one of my test systems, so I don’t think there is anything inherently wrong with the installation logic. Going to spin up an https fog instance to test against
@TaTa The data being pulled in for the password is out of urandom, so it is not implausible that, as the log indicates, a given line may not include a digit or upper case letter. You may be able to run the installer a few more times and get a random password that conforms to the system’s password requirements. You may also be able to create a partial /opt/fog/.fogsettings
with strong passwords compliant with your systems password policies. Format and settings are available in the Wiki. I haven’t tested this, but my understanding is that anything not set in .fogsettings
is requested by the installer.
Edit: the setting you are likely interested in is password=
.
The smart installer is capable of installing the fog client on Windows, macOS, and Linux.
That log file may be /var/log/php7.1-fpm.log
on Debian / Ubuntu
@renanserrou Seem to be a number of http error 500 reported in the log. Can you post the apache error and php-fpm logs from the fog server as well?
I have a lab of Lenovo M73 and am currently using SANBOOT and REFIND_EFI
@kmonroe79 said in Starting cmain( )...:
What exit type or other FOG configuration settings need to be applied, so that computers will boot REGARDLESS of model?
I don’t think there is one answer to this question. There are far too many combinations of hardware, firmware, and site configurations for one set of settings to work for everyone. I suspect that is why the exit settings exist for both the server (FOG Configuration \ iPXE Menu Settings \ Boot Exit Settings) and the individual hosts; the server can be configured to take care of the bulk of machines and exceptions made for those that don’t work with those settings.
Do you have your network configured for Gigabit ethernet to the client and server? The magnitude of that change that sounds suspiciously like a change in media speed someplace down to 100MBit.
Are these unicast or multicast deployments?
Have there been any changes to the network infrastructure or switch configuration?
Are you able to see if your switches are auto-negotiating to the correct speed with the clients you are deploying, the fog server, and any intermediary switches?