When I install the Virtio Drivers, it doesn’t have anything for Virtio network, it’s just a balloon driver. So it makes sense that it would not work. I’ll see what I can find though.

Still getting that same error after restarting those services.

Hi Tom,

I put END TEXT as you suggested and and all seems good now, I even put it back to END TEXT and was able to recreate to problem.

I really appreciate your help and prompt responses, now I’m able to carry on with my learning on linux/Ubuntu and FOG.

i guess that’s what my professor meant when he said "pay close attention to details when working, especially with text based config files/programs.

Thanks;
dabob

Does the task actually perform?

What version of FOG are you using?

Can you give us, right after you’ve created an upload/deploy/advanced task, a snippet of your error.log file located in /var/log/apache2/error.log?

[quote=“Peter Kuykendall, post: 19739, member: 18261”]I’m having the same problem trying to install FOG 0.32 on Ubuntu 12.04.3 LTS server i386 (in a VM for now). Output is in the attached text file (initial stuff was clipped due to the size of my SSH session buffer). Suggestions?[/quote]

The UDPCast file within the fog installation is outdated.

Follow the solution in this forum:

[url]http://fogproject.org/forum/threads/setting-up-and-building-udpcast-failed.4548/[/url]

It’s basically downloading a newer version, patching it, and then redirecting the fog installation to look to that version instead of the one that fog provides. Once you do that, run the install again, and it should complete without a problem.

Having the same issue, monitoring.

The embarrassment I’m feeling is overwhelming… I read your reply at least 10 times thinking it said the exact same thing when it hit me… Thanks though, it’s working great now! Boot nuking all those machines with ease.

The known good systems were extremely slow as well just like the new one using 3.12

Glad you found it! And thanks for letting us know where the issue was!

It sounds like the partitioning scheme on the hdd is causing this particular issue.

You may try an fdisk on the drive to verify what partitioning scheme is setup on it. It sounds like the first drive was initialized with the MBR tables and the other one is partitioned with GUID Tables.

I don’t have much more information to help out with this.

We do not use Acronis, sorry I can not be of assistance.

I thought of just changing my subnet mask but I suspect it’s far more involved than that.

I’ll Google around about ProxyDHCP, that sounds like the least convoluted solution - but I’m happy for the help if you have some tips, especially relevant to my configuration…I do appreciate that. I’ve been running CentOS 6 and am happy with it so far. I hope to not have to reinstall everything and start over, since Trinity Rescue Kit was a BEAR to get the config right (some late nights involved and I can’t remember exactly how I got it to finally work, but it does–except for the whole internet connection issue). But if I have to I have to.

Also,

To my knowledge, ftp is used to actually transfer the image from /images/dev to /images as nfs for /images is mounted as read-only

Make sure your server fog user password is set and that that password is what’s set in Storage Management Password and in FOG Settings->[FONT=Ubuntu][COLOR=#555555]FOG_TFTP_FTP_PASSWORD[/COLOR][/FONT]

[FONT=Ubuntu][COLOR=#555555]Hopefully this helps.[/COLOR][/FONT]

You can look into recovering a mysql database. There may be a way to remount the tables so you can export the data.

[quote=“Jaymes Driver, post: 19653, member: 3582”]
Were you running into display issues on your fog server, or were you getting display errors when using a windows box?
[/quote]

I was running an Ubuntu server without a display, so the problems were with the Windows box with IE10 I was connecting to the web interface with. There were loading icons, just that the pics weren’t loaded. Then I had someone mention that the graphs were HTML5 canvas elements.

Next time, I’ll remember to try multiple browsers 🙂

If you ever need help, please don’t be afraid to ask 🙂

Thanks for the reply, Tom. We’ve ended up finding some other way of tracking user logins over the network. I appreciate your help!

Orphen,

It sounds like the reason you received the Invalid MAC address is the kernel recognizes the loopback, (which doesn’t have a MAC address, therefore it’s invalid) but it doesn’t recognize the physical interface itself. To verify, boot PXE and select Compatibility to find out if the kernel recognizes the HDD and Network. My guess is that it can’t find your network adapter.

The hdparm issue is not really an issue. That, from what I’ve found, is just letting you know that the kernel has HDD Drivers and has found support, but the drive isn’t loaded in that particular mode. It’s nothing bad, just letting you know that it’s not the appropriate controller to how the device is setup.

I’d recommend starting by finding out if your kernel has your network adapter which is what my best guess is the issue here.

I have built a kernel that, for linux, contains all Ethernet and USB Networking adapters.

You can download it at: [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]

Or you can wget it with:
[code]wget --no-check-certificate http://mastacontrola.com/fogboot/kernel/bzImage[/code]

Hopefully this will help you out.

@Dark000- I’m happy that I helped in the smallest of ways, and only hope this helps others.

All,

I don’t know that FOGPrep or Partition adjustments, alone, corrected this problem. One way, I guess, to test would be to recreate the image, without FOGPrep. I’m more than certain the partition adjustments didn’t do this as the imaging process doesn’t know anything about the partitions them selves. All Partimage does is copy the data to the file, it’s really the FOG Scripts that create the partition specific images. Because of this, I am pretty certain these were not a problem in the first place.

I’m almost sure FOGPrep wouldn’t have been the fix for this either. Mostly because, to my knowledge, all FOGPrep does is get the UUID information (hostname and hardware specifics) cleaned up from the registry. At that point, it really doesn’t care.

It’s starting to sound, more, like the Image being under a certain size has helped improve the speed of this issue.

Nothing broke between them. A core kernel such as the one you’re describing (default install) contains drivers for video cards. With this comes the idea of kernel mode setting (KMS) which makes the terminal screen fit to the native resolution (if I understand it correctly) to your display.

The issue was KMS was not a fully tested feature and hence would show a snowy screen on some systems. Other systems it would display perfectly fine.

I imagine that an updated kernel (which one did you use 3.8.8 or something somebody built?) just has more support for video and can properly negotiate the KMS needed for the display.

If you’re using a custom one, I imagine you’re using a kernel that doesn’t care about the video card and just displays no matter what, which would also explain why you’re not seeing the “snowy” screen anymore.