have you tried single disk resizable?

[quote=“Jaymes Driver, post: 39693, member: 3582”]Is there a particular reason you want to multicast these?[/quote]

100Mb switch maybe 🙂

I’ll take a look at the code, but I’m pretty sure this is there already.

I don’t remember when it was added, but I’ve already made changes to fix this. Basically, it works with the task scheduler.

It checks if there’s any systems to run a task, and if so, sends the WOL packets to those systems on every cycle (defaulted to 1 minute).

This is, again, the nature of UDP. It just blasts your network. It’s not a failure to get dhcp, it’s a failure that your switch cannot cope with the hammering effects of Multicast.

Are you talking about multiboot or is this single boot systems?

[quote=“Junkhacker, post: 39630, member: 21583”]then you need to change the password stored for FOG_TFTP_FTP_PASSWORD in fog settings and the password stored in storage management. these places use the linux “fog” user for ftp/tftp purposes, like Tom said.[/quote]

the problem was the password in storage management not equal to fog unix password, solved

Can you try comparing contrasting info from this site?

[url]https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP[/url]

Thanks a lot for the work you guys do.
Had the database schema problem and thought I’d have to do a complete rebuild.
Used the link provided: [url]https://github.com/mastacontrola/fogproject/issues/1[/url]
Works now.
Am running Ubuntu 14.04 LTS (desktop version) and FOG 1.2.0

Thanks again very much.
Fred

how setting this option in Linux ??

Thanks, that is what I was looking for.

Andrew

Hi fre2709,

Have you resolved your issue ?
I have a similair problem with my HP8000 USDT … On twenty PCs, just 2 can boot (i)PXE correctly … Other computer model works fine)
I have checked the BIOS version, try an update BIOS, etc etc …

I’m going crazy …

Basic informations :
FOG Version : 1.2.0 on Debian 7
OS Client : Windows 7 PRO.
Fog Install LOG : [url]http://pastebin.com/uRiN9x3c[/url]

Ah cool, there hasn’t been a client update in a long time, right? What’s the plan for it?

[quote=“John VanHoose, post: 39534, member: 4156”]I just went back to .32 it works with no extra troubleshooting.[/quote]

It’s tempting, John, but I’m not giving up just yet.

When the machine boots does it pull the pxe menu, or does it error out and continue booting to the OS?

In the past with certain revisions of Ubuntu, we had to doctor some services to start on each reboot. I would not be surprised to find that a service was not started properly on boot.

Start by verifying that the apache and tftp services are running.

[code]sudo service apache2 restart
sudo service tftpd-hpa restart[/code]

Try to navigate to the fog management UI, did the web page display? Pxe boot a machine, does the menu appear? can you register the machine to the fog server?

You may need to separate the Network into different scopes and filter the broadcasts to allow this to work.

One of the biggest drawbacks to Multicast/UDP packets is they don’t care who’s receiving them, and don’t care who it’s intended for. It just “blasts” data. This blast is then picked up by EVERY system on the network. Seeing as imaging will continuously send packets of data out, it’s literally self DoSing your networking.

Sorry for not responding. Been out with a stomach bug. I checked the php.ini file and it is blank

Nope, but it is pretty close. Right now I’m implementing the new encryption system. Once that is done a usable beta should be ready, but a lot of polishing needs to be done before a final release (the small things that make the client more professional and easier to use).

Good luck, you only need dnsmasq if you need to resolve to your file, if lets say for some reason your offered file is not received completely.

I use dnsmasq because there are IP helpers in my network that over ride my dhcp settings. I also use an out dated netware environment that has limitations on the boot file name length.

This length issue is also present in dnsmasq, that is why you have to symlink undionly.kpxe to undionly.0

Yes it is true that in the ltsp.conf file you have supplied the boot file name in its entirety, but when we began working to provide the undionly.kpxe as a boot file name, dnsmasq still had limitations. I do not know if these limitations are still present.

I hate to see you give up on trying to get dnsmasq to work, I feel it’s a wonderful solution, and with the use of dnsmasq you do not need to even edit the dhcp information to include the fog server or it’s boot file, dnsmasq works as a proxy dhcp server and issues the proper boot information to the client. If you choose to take it up again, dnsmasq that is, I would be happy to help you troubleshoot.