@zyzhang When a deploy fails it will set this value to zero. I know this is not great behaviour but that’s how it was in FOG 1.5.4. Nothing we can do about it. You’d need to update to the latest developer version (called dev-branch on github) for it to be fixed.

@CpServiceSPb said in ERROR: Not able to find a network interface that is up on your system:

And is got the same error.

What exactly do you mean by that?

Please run ip a s as root and post full output here.

@davide1611 said in No configuration methods succeeded: DHCP failed:

Thanks Sebastian and sorry for asking something already resolved

You are welcome. No trouble at all. It might not be too easy to find the answer to this in the forums if you don’t know what is causing this.

@Mightmar said in New computers- no configuration methods succedeed:

I got a new problem now

May I ask you to open a new topic for this? We try to keep things sorted here so others can find solutions to same or similar issues better.

@altitudehack To me it looks like you have found and fixed what was causing the error in your case. So I’ll mark this solved. Thanks for posting here. I am sure it will be useful for others in the future!

@Sebastian-Roth Thank you

@JYost As far as I know the inner workings of the fog-client installer I don’t hink you actually need to uninstall older versions first. Just install 0.11.19 and it will take care of an older version if it is installed - remove it and install the newer version.

@JYost The images themselves have not much to do with the fog-client software. It just does the host management (reboot on imaging tasks, domain join and so on).

But I do understand your question! Between 1.5.0 and 1.5.8 there were many changes in FOG and FOS (FOG Linux OS) which does all the actual work when imaging. We moved to newer versions with many tools in FOS, especially also partclone. But as far as our testing shows you should be able to use your old images without any change. Give it a try, just do a deployment to one of your hosts and see if it works. It should.

@alansopro Do you still see the issue happen?

@Sebastian-Roth
I have found the error by myself, it was a misconfiguration of the variable no_proxy. I have change it and restart fog, it’s ok now:
export no_proxy=127.0.0.1,IP.OF.SRV.FOG,[…]
Thank you for your help!

@FuriousGamer065 So did you use my tutorial and config file exactly to setup your dnsmasq service? https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

@george1421 Hi! I’ve received a shipment of the laptops I am using this for, and for whatever reason those ones are booting from FOG properly. The computers I was testing on (which have the same BIOS software) did not boot from it. I am guessing that this was due to some BIOS configuration error on my part, as the computers have the same BIOS. Thanks for your help, though!

@george1421 I found a solution. I am not totally sure why the problem occur, but now i know what i have to do to get the PXE boot running. There is selfbulid captive portal running on 10.0.2.2 that uses IPTABELS to allow access to the internet. By logging on captive portal an other rule is added to the IPTABELS PREROUTING nat chain

ACCEPT all -- anywhere anywhere MAC 44:37:E6:B8:85:78

In this chain there are some standard rules on top and bottom.

DNAT tcp -- anywhere anywhere tcp dpt:domain to:10.0.2.2 DNAT tcp -- anywhere anywhere tcp dpt:domain to:10.0.2.2 ACCEPT all -- anywhere anywhere MAC 44:37:E6:B8:85:78 ACCEPT all -- anywhere 10.255.255.255 ACCEPT all -- anywhere 224.0.0.252 NFLOG all -- anywhere anywhere DOCKER all -- anywhere anywhere ADD RTYPE match dst-type LOCAL ACCEPT tcp -- anywhere anywhere tcp dpt:ssh DNAT tcp -- anywhere anywhere tcp dpt:https to:10.0.2.2:443 DNAT tcp -- anywhere anywhere to: 10.0.2.2:80 DNAT udp -- anywhere anywhere to: 10.0.2.2:42

Usually it is not a problem to reach IP addresses in the LAN if you are not logged in to the captive portal. I explicitly tested it today. If I am in windows and am not logged in to the captive portal, I can access all other websites in the LAN in the browser, except the FOG management portal on 10.0.32.180.

It looks the same with the boot process. If the computer is logged on to the captive portal then the PXE boot works without any problems.
If the computer is not registered on the captive portal then I always get the “TFTP timend out” message.

I just didn’t get the captive portal to play a role in this.

Many thanks to george1421 und Sebsatian Roth for the help.

@Wayne-Workman Yes i’ll be changing the client check in time after posting the required information from MySQLtuner for @george1421.
Yes 4 Cores would be nice, however due to fog not a being a critical server on our production environment it’s best not to take away resources from other servers. This might change in future though

@george1421 Let me know if this is good info for you, I’m looking to update fog in the next couple of weeks. Maybe to the latest development version

Server has been up for ~8 Days

>> MySQLTuner 1.7.19 - Major Hayden <major@mhtx.net> >> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering [--] Skipped version check for MySQLTuner script Please enter your MySQL administrative login: root [OK] Currently running supported MySQL version 5.7.28-0ubuntu0.19.04.2 [OK] Operating on 64-bit architecture -------- Log file Recommendations ------------------------------------------------------------------ [OK] Log file /var/log/mysql/error.log exists [--] Log file: /var/log/mysql/error.log(106B) [OK] Log file /var/log/mysql/error.log is readable. [OK] Log file /var/log/mysql/error.log is not empty [OK] Log file /var/log/mysql/error.log is smaller than 32 Mb [OK] /var/log/mysql/error.log doesn't contain any warning. [OK] /var/log/mysql/error.log doesn't contain any error. [--] 0 start(s) detected in /var/log/mysql/error.log [--] 0 shutdown(s) detected in /var/log/mysql/error.log -------- Storage Engine Statistics ----------------------------------------------------------------- [--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA [--] Data in InnoDB tables: 17.3M (Tables: 55) [OK] Total fragmented tables: 0 -------- Analysis Performance Metrics -------------------------------------------------------------- [--] innodb_stats_on_metadata: OFF [OK] No stat updates during querying INFORMATION_SCHEMA. -------- CVE Security Recommendations -------------------------------------------------------------- [--] Skipped due to --cvefile option undefined -------- Performance Metrics ----------------------------------------------------------------------- [--] Up for: 8d 2h 27m 17s (521M q [744.370 qps], 11M conn, TX: 468G, RX: 112G) [--] Reads / Writes: 98% / 2% [--] Binary logging is disabled [--] Physical Memory : 3.8G [--] Max MySQL memory : 2.7G [--] Other process memory: 0B [--] Total buffers: 192.0M global + 17.1M per thread (151 max threads) [--] P_S Max memory usage: 72B [--] Galera GCache Max memory usage: 0B [OK] Maximum reached memory usage: 1.1G (29.54% of installed RAM) [OK] Maximum possible memory usage: 2.7G (70.22% of installed RAM) [OK] Overall possible memory usage with other process is compatible with memory available [OK] Slow queries: 0% (0/521M) [OK] Highest usage of available connections: 37% (57/151) [OK] Aborted connections: 0.00% (117/11896308) [!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance [!!] Query cache may be disabled by default due to mutex contention. [!!] Query cache efficiency: 0.0% (0 cached / 477M selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (15 temp sorts / 146M sorts) [OK] No joins without indexes [!!] Temporary tables created on disk: 97% (11M on disk / 12M total) [OK] Thread cache hit rate: 98% (210K created / 11M connections) [OK] Table cache hit rate: 96% (1K open / 1K opened) [OK] table_definition_cache(1400) is upper than number of tables(334) [OK] Open file limit used: 0% (6/5K) [OK] Table locks acquired immediately: 100% (102 immediate / 102 locks) -------- Performance schema ------------------------------------------------------------------------ [--] Memory used by P_S: 72B [--] Sys schema is installed. -------- ThreadPool Metrics ------------------------------------------------------------------------ [--] ThreadPool stat is disabled. -------- MyISAM Metrics ---------------------------------------------------------------------------- [!!] Key buffer used: 18.2% (3M used / 16M cache) [OK] Key buffer size / total MyISAM indexes: 16.0M/43.0K [!!] Read Key buffer hit rate: 50.0% (6 cached / 3 reads) -------- InnoDB Metrics ---------------------------------------------------------------------------- [--] InnoDB is enabled. [--] InnoDB Thread Concurrency: 0 [OK] InnoDB File per table is activated [OK] InnoDB buffer pool / data size: 128.0M/17.3M [!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal to 25% [OK] InnoDB buffer pool instances: 1 [--] Number of InnoDB Buffer Pool Chunk : 1 for 1 Buffer Pool Instance(s) [OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances [OK] InnoDB Read buffer efficiency: 100.00% (12493296749 hits/ 12493297691 total) [!!] InnoDB Write Log efficiency: 44.2% (2737439 hits/ 6192657 total) [OK] InnoDB log waits: 0.00% (0 waits / 3455218 writes) -------- AriaDB Metrics ---------------------------------------------------------------------------- [--] AriaDB is disabled. -------- TokuDB Metrics ---------------------------------------------------------------------------- [--] TokuDB is disabled. -------- XtraDB Metrics ---------------------------------------------------------------------------- [--] XtraDB is disabled. -------- Galera Metrics ---------------------------------------------------------------------------- [--] Galera is disabled. -------- Replication Metrics ----------------------------------------------------------------------- [--] Galera Synchronous replication: NO [--] No replication slave(s) for this server. [--] Binlog format: ROW [--] XA support enabled: ON [--] Semi synchronous replication Master: Not Activated [--] Semi synchronous replication Slave: Not Activated [--] This is a standalone server -------- Recommendations --------------------------------------------------------------------------- General recommendations: Restrict Host for 'fogstorage'@% to fogstorage@SpecificDNSorIp UPDATE mysql.user SET host ='SpecificDNSorIp' WHERE user='fogstorage' AND host ='%'; FLUSH PRIVILEGES; Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1 When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries which have no LIMIT clause Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU Variables to adjust: query_cache_size (=0) query_cache_type (=0) query_cache_limit (> 1M, or use smaller result sets) tmp_table_size (> 16M) max_heap_table_size (> 16M) innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

@anon01013 Yes I agree, tell us what your dhcp servers are 10.0.0.8 and .9 . What is the manufacturer and version? Do you have access to change the configuration on these devices? Also please identify what is device 10.0.0.34.

Lets start with there, then we can chart the next steps.

BTW: your packet capture really tells us the story of what is going on with your network. Without the pcap it would be impossible to help you with FOG on your network.

@robo Good to know you have fixed this another way. Though I am still wondering if this is a reproducible issue and we might want to fix that in the code. On the other hand 1.2.0 is really old and I am not sure how many people still use it.

@plegrand Ops, I forgot to post here. This should be fixed in dev-branch now…

@Wayne-Workman Thanks heaps for mentioning this here! We should really update that wiki page to help people fix this. Newer versions of MySQL/MariaDB behave very different and we have changed the old way of using an empty DB password.

@Sebastian-Roth Machine was working fine after re-image and then started having performance issues mainly with Office and did Office repair. We are probably going to pull machine back and do another RAM test along with Lenovo diagnostics. Maybe just even replace RAM.

We do want to upgrade but we have been pretty swamped withe people working from home, so hopefully we can do this when things settle down 🙂

For anyone running into this. We’ve just pushed some changes to dev-branch and working-1.6 to make updating from Debian 9 to 10 easier. You should not be able to do this following the steps outlined here:

sudo -i apt-get update && apt-get upgrade apt-get dist-upgrade reboot sed -i 's/stretch/buster/g' /etc/apt/sources.list apt-get update && apt-get upgrade apt-get dist-upgrade reboot apt-get --purge autoremove cat /etc/debian_release cd fogproject git checkout dev-branch git pull cd bin ./installfog.sh