PXE error Undefined index extraargs

[steveballantyne]

I was attempting to update to the latest SVN (I was running SVN previously, just hasn’t been updated in months). I keep running into this error message which means nothing to me. I know it has something to do with the StorageNodes which I have always had a problem with (because my images are on an NFS attached NAS).

When PXE booting a client, I get an error that says “http://x.x.x.x/fog/service.ipxe/boot/php… ok Type: 8, File: /var/www/html/fog/lib/fog/bootmenu.class.php, Line: 5 57, Message: Undefined index: extraargs”.

My Apache log says “[Fri Apr 22 12:55:35.274482 2016] [:error] [pid 15302] [client x.x.x.x:50485] PHP Warning: array_map(): An error occurred while invoking the map callback in /var/www/html/fog/lib/fog/storagegroup.class.php on line 43”.

Can anyone provide me clues of what I might be doing wrong here?

[Wayne Workman]

You say you were attempting to update to the latest, did the update succeed? what OS are you on?

When did this happen? Have you tried again since? Minor bugs come and go all the time in FOG Trunk - they usually get fixed pretty fast. There’s a chance that what your seeing may be one of these instances. But we can’t know until we know what version your on, and if you’ve tried the latest or not.

Also, what PHP version are you running? php -v

[Sebastian Roth]

@steveballantyne I’ve just done a complete new install from scratch, FOG trunk on Ubuntu 14.04 and cannot reproduce the error you see. Please upgrade to the very latest and see if you still have the error.

[steveballantyne]

@Sebastian-Roth I’m running the latest release of Debian (fresh yesterday). I just did a refresh on the svn trunk and re-installed. Got the same error.

@Wayne-Workman I installed 1.2.0 just to see if I would have trouble with the stable branch, and I did. So I immediately went to the svn. So it wasn’t a clean install, it was an update.

php -v tells me …
PHP 5.6.19-0+deb8u1 (cli) (built: Mar 14 2016 10:22:33)
Copyright 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright 1999-2016, by Zend Technologies

[steveballantyne]

… also I should note, that I get this error when trying to use my external NAS as the default Storage Node. Although if I change the IP to the FOG server itself, I get this error when PXE booting a client, “The storage groups associated storage node is not valid”.

[steveballantyne]

@Sebastian-Roth Why are you installing Ubuntu 14, when 16 is current? I tried installing with 16 and I ran into problems with web services not able to start. So then I tried it with 14 and I ran into another familiar problem where I end up with a blank web page when I attempt to install/update my database schema (I have seen this error dozens of times, and I usually just fold and start over).

I don’t remember fog ever being this delicate. Maybe in the past I was just lucky and installed just the right version of the right distro and the packages in the right order.

Is there a guide somewhere that lists specific releases that are KNOWN to work? And perhaps what I should be installing, and in what order?

[Sebastian Roth]

@steveballantyne said:

Why are you installing Ubuntu 14, when 16 is current?

I didn’t really explain what I meant, sorry. I tested some kind of automatic install system (fresh OS and FOG in VM) to hopefully better check if our installer is working on a few mainstream distros - kind of like a nightly test build system. So what I was actually trying to say is: I am testing my automatic install system with Ubuntu 14.04 right now (because a lot of people still use 14.04) and I don’t see the ‘extraargs’ issue with FOG trunk.

Maybe in the past I was just lucky and installed just the right version of the right distro and the packages in the right order.

I didn’t mean to say you should go with Ubuntu. Stay with whichever distro you are familiar with (using debian myself here) and we will work on making FOG work for you if you report bugs that you see in the latest FOG trunk!! Ubuntu is known to likely cause DB issues - which we can’t do much about beside providing help via forum and wiki. The FOG installer is taking care of installing all the packages and there shouldn’t be a “right or wrong” when it comes to the order of package install. Please let us know if you can confirm any issue with that. Even if some of the needed packages are already installed before running ./installfog.sh it should still all be fine (as well updating the packages).

Is there a guide somewhere that lists specific releases that are KNOWN to work?

As I said we are working on getting FOG trunk to play nicely with all major systems (several versions of debian, ubuntu, fedora, centos, RHEL, arch). Choose whichever you like and tell us if you are running into problems so we can fix them.

I’ll have a closer look at the errors you posted! Seems to be two independent I reckon…

[Sebastian Roth]

I feel like I need to tell you a little bit about how FOG is being developed. We are all volunteers doing this in our free time just for the fun of it (as Linus Torvalds would put it). As we only have limited free time we are lacking the possibility to do extensive testing. And this is exactly where we heavily depend on people who are willing to jump in and try out FOG even though it still has a few bugs here and there. We are just not able to find those without all the people out there - it’s that simple really! FOG is pretty active right now (as you might have already seen in the forums) and we usually fix reported issues within a couple of hours or maybe days at most.

Ok, now about your issues. I just (auto) installed a fresh debian jessie VM with current FOG trunk. I am unable to reproduce the “Undefined index: extraargs” (which is just a notice not an error by the way) unless I set error_reporting to E_ALL and enable display_errors. Possibly you’ve modified your php.ini - FOG does not enable it by default I am pretty sure!

About the “The storage groups associated storage node is not valid” issue: AFAIK this message only comes from “Quick Image” and only if there is no valid image found on the server. I know, the error message might be a bit confusing. But quick image (deploy) without having first uploaded/captured an image from another client does not make much sense.

The array_map warning might be caused by a faulty NAS storage configuration. Please post a screenshot of the settings so we can have a look.

[steveballantyne]

@Sebastian-Roth said in PXE error Undefined index extraargs:

I feel like I need to tell you a little bit about how FOG is being developed. We are all volunteers doing this in our free time just for the fun of it

Yes, and I greatly appreciate your work. Please don’t mistake my complete and utter frustration for snarkiness. I am just having a bad week with imaging and I am losing my mind. We used Acronis for a short while, and it was painful to pay so much and get such horrible support. I have found that there is much better support for this free and volunteer driven product. And honestly, I have been running this for years without an issue. So I am sure that there is something I am doing to screw this up!

Ok, now about your issues. I just (auto) installed a fresh debian jessie VM with current FOG trunk. I am unable to reproduce the “Undefined index: extraargs” (which is just a notice not an error by the way) unless I set error_reporting to E_ALL and enable display_errors. Possibly you’ve modified your php.ini - FOG does not enable it by default I am pretty sure!

I have not modified any php files.

About the “The storage groups associated storage node is not valid” issue: AFAIK this message only comes from “Quick Image” and only if there is no valid image found on the server.

Okay, that makes sense. I have started over so many times, I am likely trying to quick image where there is no image. I have kept a great number of images for various hardware, and I am hoping to reconnect them once I straighten out my issues.

The array_map warning might be caused by a faulty NAS storage configuration. Please post a screenshot of the settings so we can have a look.

I will do that! Because I am almost positive that my problems are 80% if not 100% in my Storage Node settings.

In the past I have connected to a NAS that has all my images on it. To make this work though, I had to do some ugly hacks in several PHP files to point some references in “FOGFTP” settings to use the static IP address of the Fog server whereas the default would use the Storage Node IP (which is the IP of my NAS). But I don’t want to get into all that at this point. I can save that for another thread. At this point, I just want things to work out of the box with a brand new image on the local machine.

One thing I wanted to ask — when I am installing the Debian/Ubuntu OS, should I NOT check LAMP server? I have been checking this at install time but I keep running into MySQL issues. So I am thinking I should be leaving that unchecked, and let Fog do all the PHP, MySQL and Apache stuff itself.

[Sebastian Roth]

@steveballantyne said:

I have not modified any php files.
…
I had to do some ugly hacks in several PHP files

Did you mean you didn’t modify php.ini files in your first statement? To be able to help you best we need to know exactly if you use the code provided by us or a modified version (which would be a lot harder to debug as I don’t know your modifications). Possibly installing LAMP did modify the php.ini file? Just a wild guess. Take a look and see if it has those options set (on Ubuntu that should be in /etc/php5/apache2/php.ini - restarting apache is needed if you change php.ini settings).

In the past I have connected to a NAS that has all my images on it. To make this work though…

There are a few articles in the wiki on how to connect NASs to your FOG server. Please give that a shoot!

One thing I wanted to ask — when I am installing the Debian/Ubuntu OS, should I NOT check LAMP server?

It’s not needed but should not hurt either as FOG still tries to install those and therefore would update the packages if needed. Although I have to admit that we cannot actually test all those different setups (like pre-installed LAMP). I have done it with pre-installed LAMP a couple of times in my auto installer setup! So I think this should be fine…