Latest FOG 0.33b
-
r1223 released.
Just adds the bg.png file to the ipxe directory, sorry I missed it.
-
r1224 released.
Updated ipxe.krn to only have what’s needed.
Fix the gpt message from being thrown in init.gz.
-
Hi,
my company is thinking of switching from ghost to FOG. I’m the one who is testing FOG. But got some problems.
The version i pulled is from the SVN, but i got problems booting the Host registration (or any else entry) because my PCsboth show errors.Fujitsu Esprimo P910:
XZ decompressor out of memory
Kernel Panic: not Syncing - VFS unable to mount…
(not exact message, but if required i could take a photo and upload it.)Dell Optiplex 760 loads kernel and initrd and stops for a while. Than showing a message like “resyncing network interface” or something. I think it is the network adapter here not finding the right driver.
Main problem is, that the Fujitsu PC is not booting the init.gz file (i think) I tried to uncompress the file, and see what happens, but gunzip says it’s no .gz file…
any ideas what could help?
EDIT:
Ok, i fixed the PC with the Kernel Panic (by decompressing the init.gz with XZ [didn’t know of XZ] and gzip(ing) it again. Now it boots at least on the Fujitsu.Any hints for adding network drivers to the Dell PC Kernel?
-
What revision are you on? 1224?
The kernel issue may already be taken care of, but the kernel you’ve got may not have the drivers needed, you can try my kernel at [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url], or if you’re on 0.33b as the post suggests, go to the FOG Configuration Page, choose kernel update, select the drop-down for Unpublished kernels and choose the 3.13.3 kernel.
xz is the compression medium I’m using now, but I haven’t seen any issues with it loading the init.gz file. The only reason I haven’t renamed it as init.xz is many things reference it in the FOG systems, so I just left it be for now. xz is the compression I’m using, but your method will work as well as I’ve built my kernels with xz compression. My guess, however, is that the kernel that tried loading (I think it’s still 3.12.7) may not have the xz methods built in, I’ll try to fix that today.
The only reason I’m using xz compression is it makes the file sizes a lot smaller than gzip.
-
r1225 released.
Updates the default kernel to TomElliott 3.13.3 so we are sure xz is built in.
-
I also realized that GZIP is much bigger… I’m Uploading a image right now, when this is ready, i’m tring with the kernel you mentioned and report back.
I tried the newest unoficial kernel, but we’ll see if the 3.13.3 fixes it.
Also The 3.3.3 Kernel seems to fix booting on my Dell PC. Is there a way to set Kernel (and init, because i doubt 3.3.3 has XZ compiled in) on a MAC Basis? (I know of the Client Basis, but that doesn’t work, as i have to add it manually then.)
-
Sry 4 Double post.
3.13.3 seems to fix it… But i don’t know why it didn’t prior, as it seems to be from last Thursday, and i’m completely sure i tested it with this kernel…
-
r1226 released to fix a typo on the line 67 fog.checkin.
-
r1227 released, with it comes the fix for tabbed issue if using the location plugin on the fog.man.reg.
It also changes the iPXE menu bar color to orange just as proof of concept or customization ability.
It also uses sanboot to load the hard disk, but if that fails, it exit’s which should get you back to the BIOS boot methods. If that fails, it returns you to the menu.
-
Thanks Tom! I’m really digging the iPXE direction!
-
now with ipxe could it be possible that when you do full registration for the host and you choose image now, could we now avoid a need to reboot before the imaging starts?
-
With iPXE we “could” do it that way, but the issue remains of actually Compatibility when the imaging starts. I have decided, for now, not to perform registration from iPXE and actually load the OS level so we know the systems we register are capable of being imaged in the first place.
-
I think I found a bug with single snap-in.
When I try to deploy a single snap-in it shows up in active task and active snap-in task. Then I try to deploy another snap-in with single snap-in option it shows both in active task and only the last one in active snap-in task. -
That’s not really a bug, it’s by design. Snap ins deployments as I’ve run them should be able to be stacked. My guess is the previous task completed but hadn’t yet removed the active task yet. I’ll try to replicate the issue when I get home.
-
I see that this is a bug and am currently looking into it. Should be fixed shortly.
Thank you for reporting it.
-
r1228 released.
Should fix the snapin bug reported. It also adds checking. If performing a single snapin and the snapin you choose to deploy already exists, it will throw an error stating that the task couldn’t be created as the snapin task already exists.
If the single snapin is deployed, but you don’t choose a snapin, it automatically sends all snapins that are deployed to it. Will work on making this the same in the task management page as well.
Fixed an issue on the task page, from active snapins canceling the task didn’t work, it should now.
Fixes tabbed issue, again and properly now, for location field during registration.
-
r1229 released.
Should fix Imaging Log issue reported by Lee. It also sorts out the dates properly now.
Thank you,
-
Now when I try and deploy snapins I get the error
Fatal error: Call to a member function get() on a non-object in /var/www/fog/lib/fog/Host.class.php on line 595
-
Found the error, I’m guessing you haven’t enabled the Location Plugin then huh?
-
r1230 released to fix this issue. Sorry I forgot to set the Storage Group variable if the location plugin is not in use.
