Posts made by Gilou

Hi,

I’ve been experiencing a bit, and it turns out most of my hosts can’t do jumbo frames. But since iPXE & FOG use DHCP in a reasonnably standard way, pushing the MTU using DHCP (and having switches that support it, obviously) should have the client use it. But it requires the hardware of the NICs to support it, and the driver as well…

For those who don’t know what Jumbo Frames are, it’s a way to increase the maximum size (in fact, [URL=‘https://en.wikipedia.org/wiki/Maximum_transmission_unit’]MTU[/URL] means Maximum Transmission Unit) of the IP packet used on the network. The standard value is 1500, which means each TCP or UDP packet has to be sliced in 1500 bytes parts, adding a lot of overhead for huge transfers. Thus, putting that value to 9000 (the “jumbo” size), you avoid resending a full tcp/udp header every 1500 bytes…

Hi,

I’m sure Tom will jump in, but yeah, SVN is usable, and the FOG client changes aren’t there yet, so it should work properly as well. However, keep in mind of course that this should not be used in production

OK, that’s my fault, I used the schema updater from SVN in the end… not clever.

And new things, now my hosts don’t appear in the list, great… They do in the report, but because of the MACs, it seems they won’t get displayed…

And another bug (we need a mailing list, or a bug tracker):
all my upgrades were configured as: “DHCP will NOT be setup but you must setup your…”

And the process overwrote the config (backing them up before doing so, but still, annoying.)

I can’t really figure why the ->save() doesn’t work, so here’s the patch to make it work using pure SQL.

[url=“/_imported_xf_attachments/1/1496_schemav29.patch.txt?:”]schemav29.patch.txt[/url]

Hi,
Upgrading from 0.32 to 1.2, it is well known usually that the fact that the OS is stored in the image info rather than the host will be an issue, but there is a function handling that in the schema updater. Problem is, I got all my images set with OSID 0… I’ll debug more about that, but I wonder why this wasn’t done in SQL rather than having to call some PHP like this (we’re talking schema upgrade 29).

Here’s an example that tries to link the images with the OS of the host that was the last to finish a imaging task.

UPDATE images
SET imageOSID = (
[INDENT=1]SELECT DISTINCT hostOS[/INDENT]
[INDENT=1]FROM hosts LEFT JOIN imagingLog ON (imagingLog.ilHostID = hosts.hostID)[/INDENT]
[INDENT=1]WHERE hosts.hostImage = images.imageID[/INDENT]
[INDENT=1]ORDER BY ilFinishTime DESC[/INDENT]
[INDENT=1])[/INDENT]
WHERE imageOSID = 0

And that works, if you apply it before deleting the hostOS, whereas the PHP code leaves the images set to 0 for imageOSID…

Unless you use the DD method, there is no way FOG 0.32 can capture your Windows 8 which almost certainly use GPT, which was, I’m pretty sure, not supported at that time. You’d be better off upgrading to 1.2. The upgrade process should not lose any data, although there are a few funky things to watch out for (like, the OS ID that went from the host to the image).

As for how to do it, you just download 1.2, and run the installer. It will upgrade on its own (and yeah, backup before you do it ;))

Well, if mono can compile it, and compile it for Linux, that might be a “ready to go” situation (where .NET is used “properly” as a multi-platform framework, lol ?), avoiding more development… but it’d rather be working without a web black box, again so as to make sure we can be reasonnably certain there is no dependency on closed source (or un-runnable) things
The only “rich man” concern would then be, will we allow a mono dependency on linux just to run this, but I know I would if it meant no need to worry about it

gotcha!
Gonna give it a look, see if I can compile it using mono, and maybe write a PoC in Python for Linux, who knows.

Just make sure you have routing enabled between the two subnets (as in, the routers know that each other are responsible for their own network), and point to FOG as the next server. TFTP & HTTP work over layer 3 as long as you can route to it.

Question would be, what is the git repository you are talking about?

And SharpDevelop, might be good if it doesn’t make it impossible for non-windows users to contribute

Is that work done on SVN ? Is the work still done in C# requiring Visual Studio ?

The best would be to document a bit the API (even if it’s not REST or whatever standard), it should then be pretty easy to do something for Linux. And we need a mailing list, not a forum.

Nope
But there could be

OK, a few things I’ve noticed…

• On Debian install, it seems that the IP address somehow is improperly grepped as “adr:IP.XX.XX.XX”
• On a Debian install, the services init scripts seem to be improperly set up, the services aren’t starting in runlevel 2, and depends weirdly on inetd, and not on mysql. Meh. Can help, will talk about it
• If there is no disk label (i.e. no msdos, no gpt), FOG starts to go crazy, because of a bug in the bash, after invoking fogpartinfo --list-devices which fails.
• Not sure if feature or not, but I expected “Force task start” button to re-send a WoL packet, it doesn’t
• Group settings for the Client, Screen resolution : values are updated in hosts, alright, but the groups doesn’t remember the settings… maybe a non-feature as well, but it is weird
• FOGImageReplicator : if mysql restarts, it doesn’t die, but doesn’t do anything anymore, it seems…

and a weird one:
without saving the PXE Boot menu (i.e. on the stock boot.php setup, probably), if I try to boot a VM that has a disk like “/dev/vda”, it seems that Boot on first hard drive doesn’t work. But maybe it has to do with the default exit strategy for ipxe.

I referenced the IP in a few places, this “script” (bash, sort of) makes it possible, in a single fog, single master install to change the IP where it needs to be done…

[CODE]IP=XX.XX.XX.XX

mysql -e “UPDATE globalSettings SET settingValue = ‘$IP’ WHERE settingKey IN (‘FOG_TFTP_HOST’, ‘FOG_WEB_HOST’, ‘FOG_WOL_HOST’);” fog
mysql -e “UPDATE nfsGroupMembers SET ngmHostname = ‘$IP’ WHERE ngmID = 1;” fog

sed -i "s;chain http://([^/]+)/;chain http://$IP/;" /tftpboot/default.ipxe

[/CODE]

Hmm… not sure it’s so easy to do, or maybe the Wiki compatibility table can be re used for that (not so “automatic”). But the anonymous data would provide a view of how it’s setup, not necessarily how it’s working

For Dells, so far, the basic .ipxe thing works, and exit strategy “grub” allows all models (including the T1700) to properly boot on disk after ipxe’d…

Hi,

I will probably find a few too complicated, or impossible, but I’ll try to list here random thoughts about what could be added to Fog 1.2.0. Feel free to join, and beware, this might evolve

• customized deployment of multiple partitions (i.e. “minimum size / partition” + xx%, max), partition aware
• uploading/updating only one partition in a multiple partition image
• choosing a partition to upload as a single one (might already be there)
• UEFI boot (unsecure, obviously, but that’d be a start)
• MAC Netboot, instructions are on wiki, but now that we can do hfs+, we might as well have the fog kernel run on macs… not so sure, I use a ubuntu live CD for now.

Hmmm… basically, no UEFI booting for now ? I thought iPXE was getting around it?
I tried to load qemu+OVMF as I don’t have many UEFI-still enabled boxes, but I get [url]http://ipxe.org/err/2e0080[/url]