Ok, thanks for the post. It’s fixed now and it was the very last step that did it. A few notes on the instructions above. Like you requested, I did each step one at a time.

[quote=“mecsr, post: 27208, member: 23886”]
[B]Symlink method[/B]

delete the current /etc/resolv.conf file with this command “sudo rm /etc/resolv.conf”[/quote]
/etc/resolv.conf -> This is already a symlink to the master file /run/resolvconf/resolv.conf

[quote=“mecsr, post: 27208, member: 23886”]
2. edit the master resolv.conf file with the command “nano /run/resolvconf/resolv.conf”
The format of the file is nameserver definitions…
For a dns server definition, you use nameserver, you can define more than one, each has its own line
nameserver [I]your.Network’s.DnsServer.Address [/I]
For example, if you wanted the server to use google public dns, you would have one line say
nameserver 8.8.8.8
[/quote]
/run/resolvconf/resolv.conf -> this file is modified automatically on resolvconf service restart

[quote="mecsr, post: 27208, member: 23886
If you are on a enterprise type network that has a domain name you use the search line and the supersede statement
The “search” line syntax -
search [I]your.appended.domainName[/I]

The supersede statement, this is a multiple line statement with the second line indented with a space-
supersede domain-name “[I]your.appended.domainName[/I]”; (Quotes are apart of the syntax)
prepend domain-name-servers [I]your.primary.dnsServer.address[/I];

(in case anyone hasn’t used nano before, to save and close the file, ctrl + x, then y )

Create the symlink to the master file with the command “sudo ln -s /run/resolvconf/resolv.conf”

Restart the resolvconf service and the dnsmasq service with “sudo service resolvconf restart” and “sudo service dnsmasq restart”
[I]Note: If the “port=0” line in /etc/dnsmasq.d/ltsp.conf is still commented out, go uncomment it before your restart the dnsmasq[/I] [I]service[/I]

Do a quick test with “sudo apt-get update” if it succeeds than hooray! otherwise try the next method.
[/quote]

This solution didn’t work. The files were automatically modified on service restart.

[quote=“mecsr, post: 27208, member: 23886”]
[B]resolvconf interfaces file[/B]
[I]If the symlink method alone didn’t work, it may be necessary to edit the files specific to each network interface, these instructions assume you only have one ethernet device named eth0, but these steps can easily apply to any additional interfaces.[/I]

Edit the eth0 dhclient file with “sudo nano /run/resolvconf/interfaces/eth0.dhclient”
If you have a domain name, you need a domain line. It is the same as the “search” line in resolv.conf,
except you domain instead of search. i.e. “domain your.appended.domainName” (without quotes)

The only other lines you need are the nameserver lines which use the same syntax as the resolv.conf file shown above

so just put in your nameserver definitions the same as before
[/quote]

I didn’t have an eth0.dhclient file.

[quote=“mecsr, post: 27208, member: 23886”]
2. Edit the eth0.inet file with “sudo nano /run/resolvconf/interfaces/eth0.inet”
In this file you only need one line defining your primary dns server with a single nameserver line

Restart the resolvconf service and the dnsmasq service with “sudo service resolvconf restart” & “sudo service dnsmasq restart”

Do a quick test with “sudo apt-get update” if it succeeds than hooray! otherwise try the next method.
[/quote]

My eth0.inet file already had the correct info in it. I also had an lo.dnsmasq file with one line in it
[CODE]nameserver 127.0.0.1[/CODE]
So I modified this file with the correct details but, once again, on service restart the file reverted to the original values.

[quote=“mecsr, post: 27208, member: 23886”]
[B]resolvconf interface order and base config files[/B]
[I]If the above 2 methods still didn’t do the trick, try editing these 2 more config files. You may try restarting the service after each file to see if you only needed to edit one of them rather than both.[/I]

Edit the base file with “sudo nano /etc/resolvconf/resolv.conf.d/base”
The syntax of this file is the same as the master resolv.conf file[/quote]

I modified the base file with the values and restarted the service but the /etc/resolv.conf did not reflect the changes

[quote=“mecsr, post: 27208, member: 23886”]
2. Edit the interface order with “sudo nano /etc/resolvconf/interface-order”
This file should already have lots of information in it. I edited so that the top two interfaces are
eth0.dhcp
eth*
It is likely that you only need to have eth* at the top, but this is what I have working. Keep all the rest of the interface order
as it is.

Restart the resolvconf service and the dnsmasq service with “sudo service resolvconf restart” & “sudo service dnsmasq restart”

Do a quick test with “sudo apt-get update” if it succeeds than hooray! otherwise, the problem is something different or the linux distro your using uses the resolvconf service completely differently than ubuntu 14.04 and would require additional research.

I hope this helps. Good luck 🙂

Thanks,
-JJ[/quote]

This final step was the one that worked. I only put eth* at the top of the interface-order file and restarted the service. Did a quick ping test… success! Checked the /etc/resolv.conf and it had pulled the details from eth0.inet

So it seems the real problem is the lo.dnsmasq file which takes precedence in the interface-order
[CODE]# interface-order(5)
lo.inet*
lo.dnsmasq
lo.pdnsd
lo.!(pdns|pdns-recursor)
lo
tun*
tap*
hso*
em+([0-9])?(+([0-9]))*
p+([0-9])p+([0-9])?(+([0-9]))*
ath*
eth*
wlan*
ppp*
*
[/CODE]
The above was the original layout.

Thanks for your help JJ. It was an interesting ride and probably wouldn’t have known the flow of these files from day to day usage.

Hi all,

I had the same problem. I fixed it checking the disk with gparted. No errors were found but the next time the image upload was fine.

Xabi.

You’re welcome.

It said partition sda1 (ext 3 - the system partition) is corrupted or dammaged, it’s the same for sda2 (extended partition that contains sd5 which is my swap partition) for sda5 i have the message : "swap partition not suported.

here is a screenshot of the fog server (host and server have the same partitioning) :
and a video of the upload : [url]https://mega.co.nz/#!M0QC3QaC!q3Jhk-RrX3zRpVFB3398U8lmkLQ8fW9t2rr-AM-wsCw[/url]
[ATTACH=full]694[/ATTACH]

[url=“/_imported_xf_attachments/0/694_Sans titre.png?:”]Sans titre.png[/url]

Try 0.33b? I have tried implementing a checking solution for the grub part. That said, 0.32 only supported ext3 disks, nothing higher. 0.33 should support ext4 at least.

Please bare in mind, though, that we don’t know every possibly outcome of every imaging job. We are doing this all on our free time. So making this a “Perfect” solution is the goal, but we need far more testing and assistance/coding experience to make that a possibility.

I was running 1491, just checked out 1493. Testing now.

Thanks.

[quote=“need2, post: 25906, member: 21891”]I also don’t want to step on any toes but this type of oddness is another reason I avoid distros like Ubuntu for servers now.[/quote]

Ubuntu isn’t all bad, the older revisions are great… I would avoid anything 12+ though just my personal opinion. I am VERY unhappy with the direction Ubuntu is heading, but it is REALLY versatile and easy to set up. It caters to a crowd of people who are not versed in linux but still want to dabble. Anymore it’s become a hodge podge mix, but the older revisions were solid. I have always been a fan of the debian releases.

I know this doesn’t look well coming from the Ubuntu guy, but I would avoid Ubuntu as well 😞

This is part of the /bin/fog script.

Within the init.gz

On your FOG Server as root extract and mount the init file:
[code]cd /tftpboot/fog/images
mkdir tmp
gunzip init.gz
mount -o loop init tmp
vi tmp/bin/fog
[/code]

Make the changes needed then save and close then run the following commands:
[code]cd /tftpboot/fog/images
umount tmp
gzip -9 init
rm -rf tmp
[/code]

That’s it.

It works great! I just tried it.

Thank you.

Edit: I was using EXT4 partition

Works FOG with 3 primary partitions and 1 extended partition with 4 logical partitions?

Hi all,
my PC with Mainboard ASUS P5RD2 VM has the same error like my PC with Mainboard ASUS P5W DH Deluxe (Image in post #11).

Please give me hints for resolving the problem, many thanks.

edit:
now I try another PC (FSC Esprimo E5925), it´s the same Problem …

edit 2:
now I trying PC with Mainboard ASUS M3N78-VM, Chipset Nvidia Geforce 8200, MCP78S, LAN Nvidia nForce build-in Gigabit MAC with external Realtek 8211CL-GR PHY, AND FOG WORK´S !!
(Windows 8.1 64bit, Image Type “Other Windows”)

[I] I confused …[/I]

edit 3:
Now I’ve tried desktop to circumvent the problem with the installation of Intel Pro/1000 GT Adapter, unfortunately without success. In all three problematic computers the same failure (see photo post#11).
Now I do not go on and ask for help.

Thanks for posting back what ended up fixing it.

I have seen that sometimes some things don’t install properly.

Over the last few days, it seems people who are having problems simply re-run the installer and they’re good to go after that. I don’t know why.

I haven’t seen it so much in 0.33b but that’s not to say it won’t happen once we release.

None of the machines were able to be queued!
[ftwlx132] Unable to connect to tftp server.

Hi,

As has been said above, Ubuntu is Debian with newer versions of some stuff, a different install program and a pretty desktop.

I’ve had what you experienced happen on one of my machines when I installed a different desktop. I installed something that hadn’t been Ubuntu-customised and that caused the boot screen to revert to the original one it had before Ubuntu applied their look. Is it the boot screen that has changed (the one that shows up when you turn the machine on) or the login screen (the one you type your password into)?

There’s almost certainly nothing to worry about. Nobody has compromised your box.

Awesome, glad to have been of some help.

The issue I think, is not with the image or deploy. I think it’s more related to the GRUB and MBR file.

You’re systems aren’t booting because they don’t know where to look at the hard drive for the information, so they just reboot, and the cycle keeps happening.

Thank you for the replies! The “server” I currently have it on is an old PC whereas I have a new server to implement Fog because I love it so much! The old PC was tampered with and the install of Ubuntu is clobbered. I’m not that ubuntu savvy but when I left the server was functioning fine, when I come back it locks up at boot. I have the new server anyways so I really don’t think it’s wise for me to search the forums day in and out to try and figure out the issue with it.

I’m sorry I didn’t read -.-

The setting should be under the video\display settings on that virtual machine and should be a value you can increase. Sorry for not knowing exactly where, we are a VMware shop here, but there aren’t many differences between settings on a VM with the type 1 hypervisors.

To my knowledge, ownership of these folders really don’t matter.

They’re usually given permissions of
[code]chmod -R 777 /images[/code]

However, it’s FTP that moves the file from /images/dev to /images.

Make sure your FTP username and password are correct.

[code]passwd fog[/code]

Set the password and make sure you set this same password under:

Storage Management->Storage Node->Management Username/Password and that it’s set under:
FOG Configuration->FOG_TFTP_FTP_PASSWORD

That should help you out.