Not sure this is related to any of the previous issues in the thread, but I had several Ubuntu 14.04 Fog servers using 1.2.0 that would unicast perfectly but get “starting to restore image” when multicasting.
I finally found that the FOG_UDPCAST_INTERFACE value under Multicast Settings was wrong. It was set to eth0 while my adapter was eth1. Not sure how I managed that, but hope it helps someone.
If it actually deployed 95% of the image, you’ve probably got a good shot at recovering a file that’s on the image.
Take the drive that you deployed the image to and attach it to another (bootable) computer directly or via a usb adapter and try accessing it with a software recovery tool. There’s lots out there that are free or free to try in some fashion.
GetDataBack for NTFS is one I’ve used often with good results. It’s at runtime.org and lets you do the whole recovery and preview the recovered files for free. You just need to pay them if you want to save files from the recovery. It’s pretty good at picking out NTFS even if its hashed up a bit. It can do a raw recovery as well, but that’s pretty time consuming. Even if you don’t want to pay runtime.org for the software, you’d be able to get an idea of whether you’ll be able to recover it with another program.
On win7 make sure you use GDB-NTFS using run as administrator or it won’t have rights to work with the physical disk.
Did Dell put the OEM recovery/diagnostic partition on the drive? I’ve seen that make things a bit goofy.
My guess is that it’s having an issue with the hidden dos partition in the beginning. I’ve had trouble with OEM partitions and Fog, and checking the forums, it looks like other have too.
Have you had any luck with another image that’s less complex? If a plain vanilla image works captures and deploys ok, then you at least know Fog is set right and working. From there you could try adding an additional partition, capture/deploy, repeat, until you reach a problem and try to troubleshoot from there.
Other thing I could think of to try if you really need that image with the hidden partitions is to do a RAW image type. I’ve not tried it myself as I don’t have the storage space for such a thing, but I’m wondering if that’d at least get you going for the time being. It’d be a large image file and take a bit longer to capture and deploy, though.
Anybody else had better luck with multiple partition setups?
Well, only a few months huh? You could type the 1’s and 0’s out faster than that.
Yeah, it’s under the “Other Information” icon (question mark with circle) along the top. And it’ll be “Kernel Updates” along the left hand side. I believe your Fog server will need an internet connection for it to work right.
My Fog machines need to stay off the network since they’re running their own DHCP servers. That and they’ve got a Microsoft Forefront thing obliterates any/all Linux related stuff from orbit as “Shareware/Freeware”. So, I’ve never tried that tool. But it’s supposed to be pretty easy to swap kernels with it.
The wiki details creating a custom kernel with manual instructions if your server can’t talk to the interweb either. You could probably use those instructions to place a kernel you downloaded.
[URL=‘http://www.fogproject.org/wiki/index.php/Building_a_Custom_Kernel’][/URL]
[url]http://www.fogproject.org/wiki/index.php/Building_a_Custom_Kernel[/url]
The weird thing is that it looks like it is working, albeit very slow. I might also be considering that something physical is wrong, maybe on the image storage side?
Hi Matt,
Well, I’m sure somebody else will have a better idea than me, but…
Maybe the mode of the drive ATA vs AHCI in the BIOS on the target?
Have you tried uploading an image to the Fog server? Does that bit work?
Another thread mentioned switching to a different fog kernel, maybe a newer or older one would work better?
Beyond that, my thoughts might be that there could be permissions or authentication issues on the storage, image is corrupted, or maybe a bad cable?
If it won’t complete the upload either, I might check the permissions/authentication bit.
If you have additional information on your current Fog setup like OS + version and Fog version + kernel, there are some much smarter people than me who can probably get you in the right direction faster.
Sounds like it might be a password issue for tftp. I think. Maybe.
Reference this: [url]http://www.fogproject.org/wiki/index.php/Unable_to_connect_to_TFTP[/url]
Particularly the bit about setting the password for the user “Fog” and it matching [B]TFTP_FTP_PASSWORD[/B] and [B]STORAGE_FTP_PASSWORD [/B]in /var/www/fog/commons/config.php (at least that’s my path in 11.10)
Seems like I had something else to do as well, but I guess start with that and see how it goes.
No problem. For me, the problem seems to be when Ubuntu boots without an ethernet connection to some active device (switch, another computer,etc) and cannot start the service. Also, the timing on the service starting is an issue, almost like it tries to start the service before the card is fully up. I think others have used a delay in /etc/init.d/isc-dhcp-server (or whatever is appropriate for your machine) to work around this.
Link on the subject here: [url]http://ubuntuforums.org/showpost.php?p=11305447&postcount=2[/url]
Kinda what I was thinking, Chad. On my fog server, I typically have to manually start the DHCP server following a reboot . You might check to see that the service is running. On my flavor of ubuntu (11.10), that is:
service --status-all
and the service is isc-dhcp-server
Other things I’ve seen are bad ports on a switch, bad cables, bent pins on the NIC. I typically overlook those types of things for hours if not days, so you might try going from fog to the target computer.
Found the manual here: [url]http://www.lenovo.com/shop/americas/content/user_guides/t530_w530_ug_en.pdf[/url]
On page 114, it describes enabling the Ethernet LAN option ROM, not sure if that’s needed or not.
On pages 124, 125, and 127 it describes settings for network booting. Might want to check that UEFI/Legacy is set to both, the startup sequence has PXE included, and network booting is enabled. It’s tough to know for sure just by the manual, but sometimes the BIOS settings are a little strange, like PXE is enabled, but is excluded from the startup sequence.
After verifying these settings, I’d mash F12 while the ThinkPad splash screen is up to manually pick the boot device. If the PXE option isn’t there, I’d guess something else in the BIOS isn’t enabled. If it attempts a PXE boot, you ought to get a screen with something along the lines of:
“Initializing Interl
Boot Agent GE v 1.3.52.1
PXE 2.1 Build 089 (WfM 2.0)
yada yada yada”
That should show up if you’ve got a network cable in or not.
Hope that helps!
Is your image type “Multiple Partition - Single Disk” by any chance? I found that when using that type of image, it will only deploy (properly) to a drive that is precisely the same size or larger, regardless of the used space or partitioning. So, if the 80GB drive in the desktop you’re trying to deploy to is from a different manufacturer, it could be a slightly smaller capacity drive than the one you captured the image from.
If you’re able to use the Single Partition type, I recommend that. Otherwise, my workaround for the Multiple Partition type was to work out which was the smallest capacity drive at the byte level and capture the image from it. Then I could deploy to any other drive.
If you are using the Single Partition type already, then something else is going on, but I’m not sure what. I’ll see if some more coffee gets my brain working.
Yeah, mine did that as well. There’s a couple things to try here:
First, see if there are any Ubuntu updates available, sometimes that will resolve a few problems.
Second, try installing things that fail during the fog setup manually using apt-get. So, for apache2:
sudo apt-get install apache2
This is tedious, but it works (or did for me). I would install the failed or missing package like that, run setup again and see where it had the problem that time and use apt-get again to install the package needed.
One problem I had with our network was they installed MS Forefront and blocked the http sources for Ubuntu software. I ended up changing
/etc/apt/sources.list
I just replaced http with ftp and it was able to get updates again. Sometimes I had to wait a bit and run it again after 5 or 10 minutes as it does a lot of anonymous ftp logins and it seems to stop you for awhile. If this becomes necessary, I highly recommend making a backup of the original sources.list should you need the original.
See how that goes and let us know again!
Hi Alan,
I’ve got a similar setup to yours. From my experience, Fog does require an internet connection during the install.
I left my network adapter on DHCP and connected to the Internet during the install part of Fog. Just configure the installation as you’d like. For the standalone, you’d need to setup Fog to be the DHCP server and pick an IP for Fog. I think any class C will work, I used 192.168.1.1
After the installation is complete, disconnect the Fog server from your network, change the network adapter to static and use 192.168.1.1 (or whatever you’ve selected). Now, when booting the Fog server, you’ll need to have the network adapter connected to another device, either a hub, switch, router, or another network adapter. Otherwise, the DHCP server service starts and quits immediately. Even then, I sometimes have to manually start the DHCP server. For Ubuntu 9.04, I think you want
sudo service dhcp3-server start
to start the service from a command line. You can substitute “status” for “start” to see if the DHCP service is running or not.
Hope this gets you going. Let us know how it goes!
No worries, glad it worked!
And I was right there with you when that happened to me, beating my head against a wall, trying to figure out what on earth was going on. I think I’d done so much flailing damage to my Fog installation that I just reinstalled after I figured why the dhcp-server wasn’t working.
Sounds like the location set for /images is pointing to storage on the network but can’t get there.
This post has some similar sounding things which might help:
[url]http://fogproject.org/forum/threads/fog-server-fatal-error-failed-to-mount-nfs-volume.115/[/url]
What about BIOS version? I’ve got a few laptops that do some strange things if they are before a certain version.
Other than that, can you take one of the two problem children and try a unicast deploy?
This might seem silly, but is the dhcp-server service running? On my setup, which is similar to yours, I can always get to the dashboard as long as the ethernet card has some type of connection. But, if I boot Ubuntu 11.04 without the card having a connection, the dhcp-server doesn’t start and I have to start it manually.
For 11.04 it’s “sudo service isc-dhcp-server start”
You can substitute “status” for “start” if you want to see what it’s doing.
Ran across this topic as I was getting the “tps65010 no chip?” on an e6410 as well. I ended up flashing the BIOS from A04 to A09 and then it PXE booted on the 0.32 default kernel.
I’m on 11.10 and the service name for my installation is “isc-dhcp-server”
I think the path is /etc/init.d/isc-dhcp-server
I hope that’s the same one for you.
Catsrules’ topic [URL=‘http://fogproject.org/forum/threads/dhcp3-stoped-starting-automaticly.379/’]here [/URL]offers some insight on this I think. His solution was to delay the start time of the dhcp service to wait for the NIC.
Here’s that [URL=‘http://ubuntuforums.org/showpost.php?p=11305447&postcount=2’]link[/URL]
What I found on my own isolated servers is that if the server boots without the NIC connected to some active device (another powered on computer, switch, etc.) it can’t start the DHCP service. I don’t know if that’s the case for you, but it’s a couple things to check.