Latest FOG 0.33b
-
usually i’ll put my clients logo in the PXE image.
having a configurable banner might work… or you could have the option to completely disable the menu on the client so they can not hit their keyboard and get stuck on the menu. in previous versions the hide menu only hides it as long as they don’t touch anything on the PC.
-
r1221 released to fix an issue on line 762 of the HostManagementPage I had: $$Location and it should have been $Location. Sorry about that!
-
I never used the hide menu option for PXE. I’ll look into it for iPXE. I’ve tried, so far, to make booting into iPXE as painless as possible my enforcing the option to load to iPXE nearly instantly. If I remove the timeout value, it just freezes and never makes it to iPXE, probably because I’m not using the undionly.pxe file. Basically, I could create my own “pxelinux.0” file that is based on undionly.pxe, but directly tells the system to boot straight into iPXE. However, doing that would force everybody to keep their “ipxe” stuff in the service directory, where the current method allows people make configuration changes how they deem necessary.
-
It just depends how valuable client branding is to others who use the project.
for me the menu could be completely removed and it would work well for me. I always use the web gui to make tasks and I pre-register hosts. having the interface on the client just means people can click buttons and call it to find out why they have a black screen with a flashing thing on it…
An auto register thing might work, but how do you keep track of machines etc that are naming themselves. I use my DHCP leases when I initially setup.
-
What’s everyone’s thought’s on iPXE so far? Big thanks to Junkhacker on implanting the idea on me, and an even bigger thanks to those who’ve been testing it. I just want to make sure it’s working to everyone’s expectations, if not faster at loading many of the things we use, and became very used to just “waiting”.
Ultimately, the sky’s the limit now that we’re on iPXE, but for now I’m trying to keep things relatively simple.
My next big goals are to get Windows 8 imaging working under the default “EFI/GPT” installation mechanisms. I must ask, however, if other’s are able to perform this testing for me. For this, I must thank Luke Anderson of the forums here, as he helped me implement the GPT checks. To my knowledge, the Partition tables are now stored and reloaded correctly on systems. Luke is reporting the same issues with his Windows 8 box that Albatros was reporting about Windows 7. That said, I haven’t been able to replicate or even come close to trying to troubleshoot the issue as I don’t have a GPT system I can play with.
So I ask the community for more help on this. Preferrably those of you who know some code as well, so maybe you can test what will make it work.
I hope you like what’s coming so far and that I’m in the right line of thought here.
Thank you,
-
For info I have added a background image to my ipxe boot cd.
I built an ipxe at
[url]http://rom-o-matic.eu/[/url]
with the following options.
CONSOLE_VESAFB
CONSOLE_CMD
IMAGE_PNG
in my ipxe boot file I added the console line.
so it now looks like
#!ipxe
console --picture ${boot-url}bg.png
:start
menu iPXE boot menuitem tftp FOG via tftp
item http-live FOG via http( live menu)choose target && goto ${target}
I’ve tried adding the console line to the fog code, but it looks like your ipxe.krn wasn’t built with the CONSOLE_CMD option.
Hope this makes sense.
[url=“/_imported_xf_attachments/0/543_boottest Clone.png?:”]boottest Clone.png[/url]
-
It makes sense. I’m using the ipxe.krn file provided by the official ipxe.iso download. With this, i’ve been looking into building a custom ipxe.krn, so that it may also integrate https as a valid boot option. So any instruction and assistance would be very helpful.
That said, with console enabled, can we just take the menu and paste it (for all intents and purposes here) over the image, or does that require the standard pxe rechain method I’ve been able to find?
-
r1222 released.
New ipxe.krn file that supports http, https, console, image_png, and the normal expected stuff. Copied the bg.png file that fog originally used to the ipxe folder in the service directory. Added statement to boot.php file to enable the background for more familiar items.
-
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.
