I’ve created a table in FOG that does, more or this, exactly what’s being requested.

Because of this, for the most accurate of data, please use the proper filenames as it’s the best method I can come up with.

If you’re interested in finding out what files work and such, hence the idea behind the generation of this table, rather than setting your dhcp filename option to undionly.kpxe, start out with ipxe.pxe. Test your systems, and find out if the systems can boot under ipxe.pxe.

If they can, there’s little more you need to do.

If not all your systems work, then try the undionly.kpxe file. The table will read the new file name and create a new entry if it makes it into the menu. If it doesn’t make it into the menu it won’t enter it.

The basic construct of the table currently is:

Product, Manufacturer, Boot file, and mac address.

It will not keep making entries in the table for every mac address. It will only make new entries if the filename, product, and the manufacturer does not already exist.

This way, let’s say you changed undionly.kpxe to ipxe, you may end up with an entry for the same model of system for multiple files.

The ideology of this table is to eventually allow centralized place for fog and the ipxe team to better know what systems work and with which files.

Of course, when this gets entered, it will be completely optional to send this data to us.

Once we have the “central” table setup, the table will allow us (the developers) to hopefully code in what systems and what files to use for those systems.

For example, if we know the ipxe.pxe works for the Dell ts1700, and you’re booting to undionly.kpxe, We can supposedly cause the undionly.kpxe to rechain to ipxe.pxe. This would allow better operation of the nic during the ipxe state.

his comment is a quote from the ipxe forums about the different options to compile ipxe with. we do have a .pxe but have not had any use for a .kkkpxe

I always used this way many time and once again last week and never had that certificate request or any error.
I find out that it was a proxy problem but I don’t know what they made different here on the proxy…
I uncommented and edited in “/root/.subvertion/servers” the following lines :

[QUOTE]http-proxy-host = 10.121.0.1
http-proxy-port = 3128
http-proxy-username = lyc-liegeard.fr\administrateur
http-proxy-password = **********[/QUOTE]

Right, i have reserved position of storage. I’ll set my FOG 0.32 storage as master on my Fog 1.x
When start the replication and will it consume all my bandwidth ?

I find out that i had to put the main node in first in exports file and not second.
Since it’s the same datastore, it will use the first it an access.

What do you mean by the storage password? The Storage Node username/password AND the FOG_TFTP_FTP_USERBNAME/PASSWORD?

I’m going to guess this is what you mean.

You’re probably running a “default” style install of FOG. The FOG_TFTP_FTP_USERNAME and FOG_TFTP_FTP_PASSWORD are what’s used to download new kernels to your FOG system. The Storage Management Username and Password are what’s used to upload images to your FOG Server. In a “Default” install, these are typically both the same because the Storage Node and the tftp and kernel/init files reside on the same exact host. This is why there’s “two” identical fields. That said, The Node does NOT need to be the same if you’ve separated the node from the FOG Server itself.

The Username and Password in these fields are the *NIX fog user account created during install. This username and password can actually be used to log in to the terminal or console of your FOG server albeit with limited use as it’s not an administrator account nor is it given sudo permissions.

The Config.class.php file holding area for this information is ONLY used during a fresh install. Why they’re blank in your setup I don’t know, but you can get this information from the /opt/fog/.fogsettings file as well. The Username is almost always going to be fog, but the password will be stored in a variable called password within this file.

Hopefully this helps.

Any idea ?

If it’s only linked to Chrome : [url]http://news.softpedia.com/news/Chrome-34-Seeks-to-Save-All-Your-Passwords-436693.shtml[/url] (added screenshot about that flag but can’t test if it works right now)

But, I’m under the same Chrome and going to the FOG 0.32 right now and the problem isn’t here.
Homepage password is saved but it’s doesn’t overwrite node account or password.

[ATTACH]1057[/ATTACH]
(sorry my browser is in french)

[url=“/_imported_xf_attachments/1/1057_Sans titre.jpg?:”]Sans titre.jpg[/url]

Added a new storage and still the same display.

[ATTACH]1115[/ATTACH]

Hardware Information

General Information
Storage Node VaubanVieux
IP 10.121.84.7
Kernel 2.6.32-31-generic
Hostname fog0210003P
Uptime 15:53:13 up 1 day, 7:04, 0 users, load average: 0.16, 0.13, 0.05
CPU Type GenuineIntel
CPU Count 1
CPU Model Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
CPU Speed 1995.192
CPU Cache 15360 KB
Total Memory 497
Used Memory 146
Free Memory 350
File System Information
Total Disk Space 196.8 GB
Used Disk Space 89.4 GB
Network Information
lo Information
lo TX 14.93 KiB
lo RX 14.93 KiB
lo Errors 0
lo Dropped 0
eth3 Information
eth3 TX 10.8 MiB
eth3 RX 7.61 MiB
eth3 Errors 0
eth3 Dropped 0

[url=“/_imported_xf_attachments/1/1115_Sans titre.jpg?:”]Sans titre.jpg[/url]

It works with “GRUB”.
Thank you again.

No other idea or a way to debug this ?

Glad you got it working.

Sorry, I forgot to reply.
Upload works fine with the normal windows installation.
Now, i’ll look for the problem of downloading old image.