Tom,
I’m sure that you are super busy but I would kind of like to revisit this. Would it be possible to make a similar modification so I can have “System Serial” as a variable in the quick registration process?

HP’s are a bear, but for Dell’s this would be so sweet as the “System Serial” is only 7 characters. So the end result would be:

SITE-ROOM-*

Where * is the “System Serial” variable that the FOG registration collects.

Thanks for any advice or input (MAYBE I could try to do it myself), you’re the best,
D.L.

PS - This is probably asking a lot, but maybe it could be truncated to 7 characters. Then it would work perfectly with Dell’s, and might work okay with other manufacturers…

Hi,
Apparently a “no password” setting does fix this issue across the board, reliably, every time.

I would much rather have a password in my situation, that is my goal.

The strangest thing is how it happens randomly - my new FOG installations have been fine being up all weekend, but I’m guessing that sometime this week it will happen again…

Thanks for any help and/or advice,
D.L.

Thanks for the reply,

Which system log should I use, and/or where would I find it?? I know that there are several in Ubuntu…

Below are the SQL logs…

From /var/log/mysql -> error.log

140606 09:35:05 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140606 9:35:38 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140606 9:35:38 [Note] Plugin ‘FEDERATED’ is disabled.
140606 9:35:38 InnoDB: The InnoDB memory heap is disabled
140606 9:35:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140606 9:35:38 InnoDB: Compressed tables use zlib 1.2.8
140606 9:35:38 InnoDB: Using Linux native AIO
140606 9:35:38 InnoDB: Initializing buffer pool, size = 128.0M
140606 9:35:38 InnoDB: Completed initialization of buffer pool
140606 9:35:38 InnoDB: highest supported file format is Barracuda.
140606 9:35:39 InnoDB: Waiting for the background threads to start
140606 09:35:40 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140606 9:35:40 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
140606 9:35:40 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140606 9:35:40 [Note] Plugin ‘FEDERATED’ is disabled.
140606 9:35:40 InnoDB: The InnoDB memory heap is disabled
140606 9:35:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140606 9:35:40 InnoDB: Compressed tables use zlib 1.2.8
140606 9:35:40 InnoDB: Using Linux native AIO
140606 9:35:40 InnoDB: Initializing buffer pool, size = 128.0M
140606 9:35:40 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140606 9:35:40 InnoDB: Retrying to lock the first data file
140606 9:35:40 InnoDB: 5.5.37 started; log sequence number 1676069
140606 9:35:40 [Note] Server hostname (bind-address): ‘127.0.0.1’; port: 3306
140606 9:35:40 [Note] - ‘127.0.0.1’ resolves to ‘127.0.0.1’;
140606 9:35:40 [Note] Server socket created on IP: ‘127.0.0.1’.
140606 9:35:41 [Note] Event Scheduler: Loaded 0 events
140606 9:35:41 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.5.37-0ubuntu0.14.04.1’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Ubuntu)
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140606 9:37:20 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
140606 9:37:20 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means ‘Resource temporarily unavailable’.
InnoDB: Some operating system error numbers are described at
InnoDB: [url]http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html[/url]
140606 9:37:20 InnoDB: Could not open or create data files.
140606 9:37:20 InnoDB: If you tried to add new data files, and it failed here,
140606 9:37:20 InnoDB: you should now edit innodb_data_file_path in my.cnf back
140606 9:37:20 InnoDB: to what it was, and remove the new ibdata files InnoDB created
140606 9:37:20 InnoDB: in this failed attempt. InnoDB only wrote those files full of
140606 9:37:20 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
140606 9:37:20 InnoDB: remove old data files which contain your precious data!
140606 9:37:20 [ERROR] Plugin ‘InnoDB’ init function returned error.
140606 9:37:20 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
140606 9:37:20 [ERROR] Unknown/unsupported storage engine: InnoDB
140606 9:37:20 [ERROR] Aborting

140606 9:37:20 [Note] /usr/sbin/mysqld: Shutdown complete

140606 09:37:20 mysqld_safe Number of processes running now: 0
140606 09:37:20 mysqld_safe mysqld restarted
140606 9:37:20 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
140606 9:37:20 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140606 9:37:20 [Note] Plugin ‘FEDERATED’ is disabled.
140606 9:37:20 InnoDB: The InnoDB memory heap is disabled
140606 9:37:20 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140606 9:37:20 InnoDB: Compressed tables use zlib 1.2.8
140606 9:37:20 InnoDB: Using Linux native AIO
140606 9:37:20 InnoDB: Initializing buffer pool, size = 128.0M
140606 9:37:20 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140606 9:37:20 InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

From /var/log/upstart -> mysql.log

140606 9:35:38 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
mysqld is alive
Checking for tables which need an upgrade, are corrupt or were
not closed cleanly.

Hi, thanks for the reply,
I’ve checked that and the MySQL password is correct. I know that this isn’t the problem because the FOG server works fine on boot up, but starts re-directing back to the schema update page at a random interval of time - essentially MySQL is failing after some random amount of time.

Since this command fails to restart MySQL, I know that there’s something wrong…
sudo /etc/init.d/mysql restart

Somewhere in another thread Tom mentioned that it is probably a Ubuntu problem with 14.04 but I just thought that I would ask if I should post the error log…

I’m thinking that no password on the MySQL database might fix the problem, but I really want to have a password going forward.

Thanks!
D.L.

Ubuntu 14.04 x64 FOG 1.1.0

Using the above software versions, MySQL continues to be a problem and just fails randomly. This command doesn’t help, but it does show the problem:

sudo /etc/init.d/mysql restart

• Stopping MySQL database server mysqld [ OK ]
• Starting MySQL database server mysqld [fail]

When this happens the web browser interface re-directs back to the Schema Updater:
[url]http://1.1.1.1/fog/[/url] ------> re-directs to -------->
[url]http://1.1.1.1/fog/commons/schemaupdater/index.php?redir=1[/url]

In FOG version 1.1.0, when you click “Install/Upgrade Now” it says “Update/Install Failed!” and “The following errors occurred”, followed by a huge text output of error messages.

My question is: Would it be useful to post this error log to the FOG forums, or is this just something that is a broken MySQL problem?

Thanks,
D.L.

Makes sense, and yeah, better to not have the domain in the username field if possible - reduces typing AND confusion.

I remember in 0.32 I tried District(Domain)\Username and I got mixed results; it seemed to work best with an FQDN District.county.k12.ca.us\Username

Thanks again!
D.L.

That did it, thanks Tom! As usual, you’re the best!

Forgive me if I sounded frustrated, I just want to get 1.0.1 in production ASAP, and I’ve hit quite a few bumps (the SQL crashing = the biggest, but I guess that’s a Ubuntu 14.04 issue).

It’s strange because in 0.32, the FQDN had to be there in my old environment: site.district.k12.etc\Username but we did have multiple domains in a forest…

Thanks again for all of your help and work,
D.L.

Okay, that was the problem with auto populate: the browser.

It doesn’t work in Chrome, which is based on Safari I guess, but you’re right, the auto populate is fine in IE 11.

But that doesn’t actually get it to register, auto join, etc.

From fog log (fog.txt):

6/4/2014 11:46 AM FOG::HostnameChanger Domain Error! (‘Unknown Error’ Code: 2202)

The other error code was (‘Unknown Error’ Code: 1355) although I’m not sure if the pretext was the same. It definitely was HostnameChanger, I just don’t know if it said “Domain Error”…

Joining AD worked perfectly in FOG 0.32 with the same settings, so I must be missing something…

It even works using FOG 1.0.1 as the imaging server, with the FOG service pointing to a 0.32 server containing the AD information, etc.

Ubuntu 14.04 x64 FOG 1.0.1

Thanks!
D.L.

Hi,
I’ve searched around and found some information, but is the Host Register function no longer working in FOG 1.0.1?

In my environment it has completely failed, stating ‘Unknown Error’ Code: 1355 or something similar (will post if I can replicate the other error code). Not only does it not work at all, but the “Auto Populate” of AD settings to the host from the “FOG Settings” menu isn’t working at all either.

At first I thought, “Okay the settings are not auto populating, that’s not the end of the world, I can just input them into groups as necessary”, but nope, that doesn’t actually make it work, make the hosts register - the AD integration system is broken, I guess…

I guess the place to start would be to actually get it working again, then worry about the auto populating…

Thanks for any advice or help,
D.L.

To add, actually it seems almost 100% stable with this modification, no crashes today…

Maybe the one crash after I made this change was a fluke and/or I had not rebooted yet, I cannot remember with all the different testing that I’ve been doing…

This has been plaguing me as well, especially because it is difficult to replicate the problem consistently.

Running the permission modification below does seem to stabilize SQL on Ubuntu 14.04 x64. Although it did still crash once, it certainly seems “better” after this modification:

sudo chmod 775 /var/lib/mysql

Your mileage may vary, but try that to start. I understand that the whole “it’s better but it still occasionally crashes” is not a scientific or conclusive answer at all, but that is all that I’ve been able to come up with so far…

Thanks,
D.L.

Hi,
Sorry I should have included more information. It’s Ubuntu 14.04 x64, fresh install of FOG 1.0.1.

There’s nothing in /var/lib/tftpboot, and there is no /var/lib/tftp directory, everything is in /tftpboot/

I don’t quite understand how iPXE works, but isn’t it pointing to /var/www/fog/service/ipxe for these files? That is what the screenshot seems to indicate. I know that it gets undionly.kpxe from /tftpboot/ but boot.php, bzImage, and init.xz are all in /var/www/fog/service/ipxe

Does FOG store operational data (to function) inside SQL? Because as strange as it sounds the problem seems to be related to SQL crashing as described in this thread:

[url]http://fogproject.org/forum/threads/mysql-tftp-stops-randomly-after-update-from-0-32-to-1-0-1-and-12-04-to-14-04.10558/[/url]

Once SQL stops working (with “unable to connect to database” message) the whole system becomes unstable and machines are no longer able to find the necessary iPXE/tftpboot files. I know that it sounds like the 2 issues should be unrelated, but this is just what I’ve experienced - perhaps the paths or some other data is stored in SQL that is needed during the boot process?

Thanks Tom, you’re the best,
D.L.

Okay,
I take it back, it is still happening, even with TFTP working…

The good news is that I’m pretty sure that everything is fine if you install 1.0.0 and upgrade, but if anyone has any advice I would definitely test/tweak further just for information, etc. because a direct install of the latest version is always the best way…

For now I guess I will use my 1.0.0 --> 1.0.1 box and go from there…

Thanks,
D.L.

Hi,
Yes I could log in to the web UI even with this error present.

After more digging, I’ve been told that this issue is the upstart TFTP problem again. For some reason I thought that TFTP’s work was done once the host was loaded into PXE, but I guess not.

After applying the upstart TFTP fix it seems to be working, I will test further.

THANKS FOG team,
D.L.

Hi all,
Thanks to the developers for all of your work, the new edition of FOG is great. I did search for this issue and I did not see it mentioned, but perhaps I didn’t search hard enough…
When building a new box I tried installing FOG 1.0.1 from scratch and on iPXE boot it has a message that boot.php or other iPXE files cannot be found:
[url]http://1.1.1.1/fog/service/ipxe/boot.php[/url]… file not found
It seems okay if you install FOG 1.0.0 and upgrade to 1.0.1 (still testing) but in my environment a direct install of 1.0.1 on a fresh installation is causing this issue.
I’ve attached a screenshot,
Thanks,
D.L.

[url=“/_imported_xf_attachments/0/868_20140602_083145-2.jpg?:”]20140602_083145-2.jpg[/url]

If anyone wants to do it the manual/gedit/nano way here is what I did:

/fog_0.32/lib/common/
gedit config.sh

where are the udpcast files from the download package?

udpcastsrc=“…/packages/udpcast-20071228.tar.gz”;
udpcasttmp=“/tmp/udpcast.tar.gz”;
udpcastout=“udpcast-20071228”;

You just change the date on the 2nd and 4th lines above from 20071228 to 20120424, save, navigate to /fog_0.32/packages/ and download the new UDPcast :

/fog_0.32/packages/
wget [url]https://svn.code.sf.net/p/freeghost/code/trunk/packages/udpcast-20120424.tar.gz[/url]

With this change, FOG will install/configure correctly on Ubuntu 14.04 with the newer UDPcast.
But even though it does install/configure correctly, I still can’t get it to PXE boot in my environment… it fails to PXE boot with a TFTP timeout error. I’m going to try it on 12.04 today or soon, but it is strange that it won’t PXE boot at all…

Thanks,
D.L.

PS - In 10.04 and 11.10 everything works great, so I know that it’s not my network setup that is the problem. Somewhere there is a PXE/TFTP/Linux/Ubuntu/FOG compatibility problem in 12.04+

Hi,
ifconfig lists the network interface it as eth0, is there somewhere else I should be looking?

Thanks!

Thanks for the reply Tom! I will find out…

It did ask if I wanted to change the default interface from eth0 on installation; not sure if that is plain text or a variable called up from the system…

You’re the best!

PS - Happy Friday! Beer’s on me!

So I finally got back to this… I combined the knowledge from this thread with the Wiki post on Ubuntu 14.04 found here:

[url]http://www.fogproject.org/wiki/index.php/Ubuntu_14.04[/url]

I was able to get the udpcastsrc path/config updated. I think that it is best to do it manually using gedit because there are 2 references to the old version inside config.sh:

/udpcastsrc=“…/packages/udpcast-20071228.tar.gz” to /udpcastsrc="…/packages/udpcast-20120424.tar.gz

and there is another entry 2 lines below this that also needs to be changed, I believe. My server is unavailable at the moment, but remember changing it twice (will post path later, if necessary).

The problem is however that under Ubuntu 14.04 I can’t get TFTP to work correctly, so I don’t yet have a working FOG server on this release. Under 11.10, everything works great. I’ve used the exact same network settings, with a different static IP, and everything else is the same (kernel, drivers, etc).

At PXE boot it just says:

TFTP. . .

The progress creeps slowly until a message saying TFTP timeout (or something similar) appears and it never reaches the FOG PXE menu…

Any help would be greatly appreciated! I plan on trying it on 12.04 on Monday…

Thanks again!