@alexamore90 Is this a typo with IP, gateway and DNS all set to the same address?
You might want to run systemctl status isc-dhcp-server
(Debian/Ubuntu) or systemctl status dhcpd
(Redhat based distros) and post output here.
@alexamore90 Is this a typo with IP, gateway and DNS all set to the same address?
You might want to run systemctl status isc-dhcp-server
(Debian/Ubuntu) or systemctl status dhcpd
(Redhat based distros) and post output here.
@alexamore90 Did the installer finish all the way to the end? When running it there is a point where you need to open the browser and let it populate the database. If you skip this the installer will fail and needs to be run again.
The node offline sounds like the installer didn’t finish properly.
@ksrvpvl As soon as the machine is registered in the FOG web UI a task can be scheduled. This would send WOL packets to wake up the machine and let it PXE boot straight into the scheduled task.
@Tauric From the pictures we see that FOG recognized the filesystem as NTFS and should be able to resize it. It’s still strange the size was larger. Good you got this fixed by reinstalling the master to capture from. No idea what could have been wrong with the other one.
@tomynocker Looks like you used the wrong field. Such an options need to go in Kernel Parameter.
@matthewadams12 It depends on the partitioning and filesystems used. If Ubuntu is installed with LVM it will be captured sector by sector (large). But if you choose plain GPT or MBR partitioning FOG should be able to capture the used space only.
@w2log Does this SuperMicro X12 have more than two NICs onboard? Then it’s probably a bug in FOG fixed in the latest dev-branch version already.
@infotc While a clean migration would surely get you to a nice clean system you can first try to get this fixed manually.
There is some logic in the FOG installer that should take care of the different package names that have changed over the years (php-mysql vs. php-mysqlnd).
Please run the following command to see what PHP packages exactly are installed at the moment:
dpkg -l | grep php
Post the output here.
Edit /opt/fog/.fogsettings
and make sure only php-mysql
(but not php-mysqlnd
) is in the packages line.
As well you might want to manually install the package needed - see if that gives you an error as well:
apt install php-mysql
@lan Which version of FOG do you currently use?
Quite possibly this is fixed in the latest dev-branch version already (fix on github).
@ludlud Do all the machines come back on or just some of them?
Check the log in /var/log/fog/fogscheduler.log
to see if jobs are somehow scheduled - like a plain WOL type job.
@RTOadmin I have to admit that I have not used the printer stuff myself really. Just trying to give you a hand.
Have you checked the user registry for old entries?
I know @Wayne-Workman used it in the past. Maybe he has better ideas.
Beside that I can tell you the fog-client runs as SYSTEM and uses the printui.dll to add the printers.
@mardonis200 Looks like we have at least three different topics on this issue (links see below). As far as I get this an update to iPXE was causing this issue. You might want to try iPXE binaries from FOG 1.5.9. While this is not great it’s a start.
https://forums.fogproject.org/topic/16850/problem-after-deployment-with-release-1-5-10
https://forums.fogproject.org/topic/16859/rhel-initramfs-unpacking-failed-kernel-panic-not-syncing
@limbooface As Rocky Linux released 8.8 the REMI repo also updated the latest repo RPM for version 8 to 8.8 which fails installing on 8.7.
Now this is one thing someone might want to look at - making the installer aware of minor versions as well and choose the correct REMI RPM.
I thought you did not need remi release for rocky8.7
With older versions we were using REMI to get a more recent PHP version. If I remember correctly RHEL 7 used PHP 5.6 by default, maybe even 5.4. We needed PHP 7 and the old ones were dated anyway.
Looking at the installer test logs for RHEL/Rocky/Alma I just noticed this is still the case in the installer. So currently PHP 7 is being used - essentially the default provided by the distro. But PHP 7 is history as we speak and while FOG still works with PHP 7 is not wise to be used anymore - no security updates.
@lukebarone Would you be keen to take a look at this?
@skyborne98 Thanks for testing and sharing you insights here!
I just added this info to the wiki: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Installing_-_Linux
@Alan-Lim Not exactly sure what your intend is here. In FOG you can assign snapins to hosts then then run the snapin as often as you want. But there is no “force” or “re-run if it fails” feature in FOG if that’s what you mean.
@RTOadmin said in Added Printers not showing:
deleted the manually assinged printers
Surely delete the printers that were created manually? Double check printer settings as well as registry for all the users.
@bballmcoe said:
When I run installfog.sh I get the following:
Can you please post the exact command(s) you use to hit this error?
Searching the web for the mentioned error brings me to the same point. Looks like the script is not being run with bash.
As well check out if this is really a bash shell or something else. Run the following commands and post output here:
/bin/bash --version
ls -al /bin/bash
which bash
ls -al $(which bash)
@bballmcoe This part of the installer script has not changed in a long time as far as I know. Maybe the shell used is causing this?! Please post the output of the following commands:
ps -p $$
echo $0
echo $SHELL
@_Goldenzweig said in new version e2fsck ?:
I took the current version from a laptop on Ubuntu 23.04
I guess the official Ubuntu binary is dynamically linked - it uses external libraries which are not included in the FOS init. It’s interesting @dvorak got this solved. Not sure which e2fsck binary was used.
Anyhow it’s probably time to update the FOS inits anyway. @rodluz Did you get to build some new ones based on the latest LTS buildroot version? I just started a build to see whether this is going to be an easy one or causing us trouble.
@ryanlewis2010 Do I get this right? You say the printer assignment done in the FOG web UI magically vanishes after a random time (1-30 minutes)?? Sounds really strange. I don’t think I have ever seen this happen.
The assignments are simple database entries and there is no specific FOG log you can look at I think. But you can enable MySQL/MariaDB logging and try to figure out why this is happening. Will still be hard to find out what is causing this even if you see it in the logs.
Do you use the FOG API by any chance? Some kind of scripting to automate FOG stuff?
If not it’s probably best to manually check the database tables on your FOG server:
shell> mysql -u root
mysql> use fog;
mysql> SELECT * FROM printerAssoc WHERE paPrinterID NOT IN (SELECT pID FROM printers);
mysql> SELECT * FROM printerAssoc WHERE paHostID NOT IN (SELECT hostID FROM hosts);
The later two (select) queries should return an empty result set. If you get results it means that there are assignments still in the database for hosts or printers that do not exist anymore. While this is not a problem in general it would still be wise to clean that up.
Now you can start looking a a certain host having printers assigned by: SELECT * FROM printerAssoc WHERE paHostID=123456
(put in the host ID you see in the FOG web UI (parameter in the URL when editing this host)
See if the assignment is in the database compared to what you see in the web UI.