To avoid conflicts with the FOG installer/updater, I just added the following line to my /etc/apache2/sites-available/000-default.conf file:
RedirectMatch ^/$ /fog
To avoid conflicts with the FOG installer/updater, I just added the following line to my /etc/apache2/sites-available/000-default.conf file:
RedirectMatch ^/$ /fog
When I load my Dell diagnostics ISO into WinISO, it lists it as “Bootable”. When I load the ISO you referenced into WinISO, it says “Non-bootable”. Are you certain this is not one of those Dell ISOs that’s meant to run within the Windows environment?
I may have an older Dell Diagnostics ISO but mine is only 8MB. This is what my PXE menu entry looks like:
[CODE]:delldiag
initrd ${boot-url}/iso/diags.iso
chain memdisk iso raw ||
echo failed to boot
prompt
goto MENU[/CODE]
Are you using the correct memdisk parameters as above? I have also had better luck compiling my own memdisk execuatable. Here’s mine if you care to try it…
[url=“/_imported_xf_attachments/1/1051_memdisk.zip?:”]memdisk.zip[/url]
Have you explored all of these - including the .INTEL one?
[url]http://sourceforge.net/p/freeghost/code/1769/tree//trunk/packages/tftp/[/url]
I know the dev team has made leaps and bounds in this area since I originally started the topic. Have you tried the ipxe.kpxe file I uploaded to this thread?
Tom,
1807 has given me no further reliability in multicasting - I’m still seeing issues like new group multicast tasks getting dumped into already running multicast tasks. Were you referring to installing MySQL with no root password as a solution to multicasting problems or just the repeated prompts to upgrade the DB schema?
Andy
Tom,
Thanks for the reply. No apology necessary on MySQL - it’s not a showstopper by any means and I know how much work you’ve put into this project and for that I’m grateful. I will update to 1806 and see how it goes.
Yes, that was me who built the ipxe.pxe file with success for 1.0.0.
I’m hoping I can get 1.1.0 running reliably enough to roll out in our school district within the next 2 weeks. I want to thank you and the other devs for the progress made from 1.0.0 to 1.1.0. The iPXE/undionly.kpxe combination has been working well and I’m blown away by how almost all of our models in production (14+ Dells and 5 HPs) have been working with the stock bzImage kernel with no arguments necessary. I will update the working model thread when I get through them all.
Andy
Do you have the FOG Service installed in your image?
I’ve got a couple of lingering issues in 1.1.0 that someone can (hopefully) help me sort out.
As I’ve mentioned in a previous thread, if I reboot my FOG server I’m being prompted twice within a couple of minutes to update the database schema. Restarting the mysql service clears this up and lets me log in, but I’m hoping this is not an indication of a bigger issue.
Under task management for active snapin tasks and active tasks, the start times for jobs seem to change randomly (always adding 5 hours). Sometimes they will look correct and then other times I can log in from another computer (or even the same computer) and the start time will be listed as 5 hours later than my time zone.
Also, I’m currently fighting through getting multicasting to work reliably so that our techs can reimage 2000+ computers this summer. I don’t recall having this problem with 0.32 but in initial testing with 1.1.0 I can create a group and create a multicast task. The number of hosts may look corrrect before I actually deploy the task, but when we get (say, in this case 30) computers PXE booted and the task doesn’t start…I can look in “Active Multicast Tasks” and instead of 30 clients there may be double that number. In another instance today, I created a multicast task under a particular group (of 3 computers) and the image deploy went fine - but while that task was working I created another multicast task of 2 computers under a different group. When I searched for the multicast task created for the 2 computer job, the number of clients in the “Active Multicast Tasks” had actually increased from 3 to 5 in the job that was in the middle of deploying - as if the 2 were added to the currently running image. When the 3 computer multicast task was finished, it cleared out everything as if I never created a new multicast task under with a different group.
Any insight would be greatly appreciated,
Andy
Ubuntu 13.10 Server
FOG 1.1.0
Looks to me like whatever computer you are using doesn’t like the included bzImage kernel. Try a different one or try adding kernel arguments. There are several threads on these topics.
Andy
Just to update this thread - I don’t know if this was an issue just for a short while after reboot but it seems to have cleared up (although I haven’t been making any changes to the DB). I also added “service mysql restart” to the /etc/rc.local file.
Tom -
Fresh install of 1.1.0
New install of Ubuntu 13.10 Serverx64
MySQL 5.5.32-0ubuntu7
AMD880 chipset, AMD hex core CPU, 16GB RAM
When I make changes to snapins, groups, etc., I’m sporadically being asked to update the database schema and a “service mysql restart” will allow me to log in again.
Andy
Junkhacker:
Thank you very much for the reply. I will dig further to address this.
Andy
I did a clean install of Ubuntu 13.10 with 1.1.0 and deployed our base image from 0.32 / uploaded to new 1.1.0 installation. Do I need to use an updated FOG Service msi before I sysprep or will the 0.32 image version work as is? The snapins seem to deploy fine - just doesn’t change name or join domain.
Thanks,
Andy
Baite:
Here’s my ipxe.kpxe.
Andy
[url=“/_imported_xf_attachments/0/843_ipxe.zip?:”]ipxe.zip[/url]
Thanks. All these years using FOG and I’d completely forgotten about that feature.
ipxe.kpxe (and undionly.kpxe for that matter) is identifying the wireless NIC as net0. I had to get to net1 somehow.
This dirty hack in my default.ipxe file seemed to do the trick:
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
isset ${net1/mac} && chain [url]http://10.0.0.50/fog/service/ipxe/boot.php?mac=${net1/mac}[/url] ||
params
param mac ${net0/mac}
param arch ${arch}
chain [url]http://10.0.0.50/fog/service/ipxe/boot.php##params[/url]
I’m trying to get more familiar with iPXE. Am I OK to assume that I can (attempt to) build an all-drivers ipxe.kpxe file and use it with FOG as long as the script to chainload to default.ipxe happens? I’m trying to figure out why undionly.kpxe is being used by default in FOG. Thanks for any feedback.
Andy