Thanks for the input. I read that exact thread right before I posted… I suppose my question was whether or not these minor changes could be done without editing PHP code (something I admit I know very little about). If it isn’t possible to just edit a line or two in a file to make these changes, I’ll just deal with it. It’s just a cosmetic thing, anyways.
Thanks!
Hello all!
In my last FOG setup in .32, I had the menu background changed, removed the descriptions of the functions, and changed the wording for some of the functions themselves through an easily edited text file. If I recall, the file was called default.something and was located somewhere inside the pxelinux folder.
Now, with the new FOG 1.0.1 moving things around, I’m a bit lost. I found where the background goes after a bit of digging, but I’m wondering where I go to change the font color, highlight color, edit the text, etc. I know about the webUI PXE menu edit field, but this just adds extra text to the bottom… not what I’m looking to do right now.
Any help is appreciated!
That may be true, sorry for misinformation.
Like I said before, I’ve built a few of these fog servers, so I sometimes get the passwords and such mixed up between them all.
Fixed!
Turns out it was completely my error. In the new config.php file, it had DATABASE_USERNAME already set as root, and password blank. I assumed this was correct and pulled from the previous configuration of FOG. HOWEVER, I didn’t realize it was asking for the machine root user password and NOT the SQL password. I’m not sure if this was caused by something I did, or if the new config.php doesn’t (can’t?) update this information from a previous install.
In the var/www/fog/commons/config.php file, I typed the password for the machine’s root user in the DATABASE_PASSWORD field. My DATABASE_USERNAME was automatically filled with root. I then restarted the MySQL service and was able to log on to the management console and do the upgrade.
So, in reality my issue was with the root user credentials located in var/www/fog/commons/config.php, and NOT with the SQL creds. Again, not sure if this was my error or just how the new install pulls its info from previous builds.
In any case, give this a shot and see if it helps.
I commented out the bind-address command which was set to the default 127.0.0.1. I restarted the mysql service and nothing changed. Went ahead and uncommented it so that I’m back to initial state.
P.S Thanks for the locate command tip
After remembering the root password for the machine, the code generated the SQL version and the listing of commands that are possible. It then listed variables below:
[CODE]Variables (–variable-name=value)
and boolean options {FALSE|TRUE} Value (after reading options)
auto-rehash TRUE
auto-vertical-output FALSE
character-sets-dir (No default value)
column-type-info FALSE
comments FALSE
compress FALSE
debug-check FALSE
debug-info FALSE
database (No default value)
default-character-set auto
delimiter ;
enable-cleartext-plugin FALSE
vertical FALSE
force FALSE
named-commands FALSE
ignore-spaces FALSE
init-command (No default value)
local-infile FALSE
no-beep FALSE
host 192.168.11.241
html FALSE
xml FALSE
line-numbers TRUE
unbuffered FALSE
column-names TRUE
sigint-ignore FALSE
port 3306
prompt mysql>
quick FALSE
raw FALSE
reconnect TRUE
socket /var/run/mysqld/mysqld.sock
ssl FALSE
ssl-ca (No default value)
ssl-capath (No default value)
ssl-cert (No default value)
ssl-cipher (No default value)
ssl-key (No default value)
ssl-verify-server-cert FALSE
table FALSE
user root
safe-updates FALSE
i-am-a-dummy FALSE
connect-timeout 0
max-allowed-packet 16777216
net-buffer-length 16384
select-limit 1000
max-join-size 1000000
secure-auth FALSE
show-warnings FALSE
plugin-dir (No default value)
default-auth (No default value)
[/CODE]
And where would I find the my.cnf file you suggested?
Also, during the install of 1.0.1 it never prompted me to type in a new MySQL password or confirm my existing one. The whole setup was automatic minus the two Y/N choices and the enter to confirm settings (which were all correct).
When I type the command
[CODE]mysql -u root -p’<YOURMYSQLPASSWORD>’ -h<FOGSERVERIP> fog[/CODE]
in terminal, it asks for my password (I’m assuming SQL password, which is blank, so I just hit ENTER.
It returns with
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘192.168.11.241’ (111)
I typically sudo commands, so I’m not used to changing to root. It’s very possible I just mistyped the command, or forgot my root password if that’s the one it’s asking for.
I remember the old section of “MYSQLPASSWORD” in one of the config.php files, but since these settings have been consolidated to elsewhere I’m not sure where to look to make sure my settings are correct as far as passwords and usernames are concerned (I’ve made a few FOG machines, so I have some trouble remembering the UN and Pass for each sometimes).
Hi all!
I recently upgraded to FOG 1.0.1 from .32 following the steps on this page:
[url]http://www.fogproject.org/wiki/index.php/Upgrade_to_1.0.0[/url]
Everything seemed to work fine as far as the installaton, but when I try to type in my FOG server address to get to the management console, it gives me a white screen with the message “Unable to Connect to Database”.
When I type in the server ip without /fog/management, I get the regular IT WORKS! screen. But it gives me no hints as to why I can’t connect to the database.
I checked the var/[url=“http://www…config.php”]www…config.php[/url] file, and it seems as though the SQL username and password are the same as they were before. It never prompted me during the installation to change any settings, so I assumed it used the same variables. I also noticed that it says many of the settings were moved to the database, and must be changed within the management console. All well and good… if I could load the console.
Any suggestions? I really don’t want to have to do a clean install -.-
I set up one of the desktops alone with monitor, keyboard, and mouse all hooked up. Updated the kernel, which I think is why the “[I]checking in”[/I] error occurred. Fog worked fine.
However, as a test I pulled out the VGA cable and plugged it back in during an image deployment, and [I]“irq#16: will be disabled” [/I](or something along those lines) message popped up in the FOG screen. So, even though I don’t understand how or why, it appears that this error is, in my case at least, related to monitor connections or the video cards. It’s possible that if the output changes in some way, FOG isn’t sure how to handle it.
For assurance’s sake, we will just have our desktops fully hooked up from now on. Strange FOG would barf over something so trivial, but who knows.
Thanks for your help Tom!
Here is the thread mentioned by Raff:
[url]http://fogproject.org/forum/threads/minor-change-great-improvment-multicast-i-love-you.8005/[/url]
We haven’t tried it at our place yet, but the theory of it makes sense.
Hi there! We are fairly new to FOG, so we are still in the experimental phase of implementing this. But overall… so far so good!
Anyways, we’ve sucessfully imaged hundreds of laptops and a handful of desktops in the past few weeks. Today, we tried imaging 6 desktop computers by stacking them on top of each other, then plugging in power and cat5 cable. We set the BIOS to pxe boot by default. So theoretically, the desktops should start up, pxe, queue in the multicast, and then begin downloading the image automatically.
Problem is, we kept getting the error:
“[FONT=Verdana][COLOR=#333333][I]irq#16: nobody cared (try booting with the “irqpoll” option)[/I]”[/COLOR][/FONT]
[COLOR=#333333][FONT=Verdana]It would then roll through some of the normal FOG gargle, and then at the end would hang at “[/FONT][I]Checking in”[/I] with multiple asterisks as it counts down.[/COLOR]
[COLOR=#333333]Anyways, after tinkering and googling for a while, I found that the irq might be due to some sort of I/O error with a port (internal or external) on the desktop. We plugged a monitor, keyboard and mouse into both computers (we reduced the load to 2 for testing purposes) and restarted the whole process. Both went off without a problem.[/COLOR]
[COLOR=#333333]My question is, is hardware such as monitors, keyboards, and mice necessary for FOG to complete its self-checkup and begin the process? Or is this error due to a separate problem altogether? [/COLOR]
[COLOR=#333333]P.S This is the very first time I’ve seen this type of error, and the other desktops we’ve done were already hooked up with monitors, mice, etc. So that’s another reason we’re thinking this is the problem.[/COLOR]
[COLOR=#333333]Thanks for any feedback![/COLOR]