As I now know what version of FOG you’re using 
I’ll take a look at the fog script that moves this file.
In the meantime, I’d manually move the directory on the Server so your stuff will work properly. Hopefully this works for you.
Has this happened often or just on this one system?
When entering your website, go to:
[url]http://<FOGIPADDRESS>/fog[/url]
Then you should be redirected to FOG Management
Make sure your configuration file in:
/var/www/fog/commons/config.php (UBUNTU BASED)
/var/www/html/fog/commons/config.php (REDHAT BASED)
Have your SQL information pointing to the right area. From the sounds of it though, you’re database hasn’t been created yet as you haven’t initialized yet because you haven’t been pointing to the right website.
This information would be found under FOG Configuration->FOG Settings
What I’m seeing is the ftp server is pointing at 192.168.86.105 But the fog storage server is at 192.168.86.12
Maybe I’m missing something?
The only thing I can think of is that it’s not communicating with the gateway properly.
It’s, seemingly, is passing information through a loop. If you have a crossover cable, try one computer connected directly to the FOG Server’s network interface and try doing it that way. This will let you know if it’s the DHCP & DNS issue. I’d recommend, though, instead of a 5 port switch, if you have a router such as a linksys or netgear, you shouldn’t see the problem you’re describing now.
I don’t know what else to check. I understand you’re trying to make the server the “router” in this case, but that loop around seems to be causing the issue itself. Does your fedora system have named/bind installed as well?
Found out that, the problem I’m seeing with the image upload process (as much as I can tell) is halting (resizable) because it’s referencing as kB. This in and of itself isn’t necessarily wrong, but when I try to manual create the disk partitions using parted, it tells me that 105905 (one byte behind part2start) is not valid for the partition. If I leave the end alone, it completes, but it isn’t the right size. It’s much smaller (part 1 that is) when it’s created using this particular method of parted. However, it successfully recreates the partition if I call the sectors: specifically, the sectors referenced are 206847 (partition one end) and 206848 is the start sector on the drive.
This method I can get rid of the need for the sleep commands, and all runs as expected. This is really weird to me, but it’s working as far as I can tell.
So I’ve, seemingly, made progress on getting the upload to work. It seems that my builds just ran thru way too quickly for pigz to keep up with writing to the NFS. The only issue is that my VM is extremely slow on the upload and download process. It only pushes speeds as high as 758 MiB/min and as slow as 100 MiB/min, but this sounds likely to just be a driver issue in my kernel.
I found that by adding a sleep command to the partimage save of the 2 partition section seems to work. I’m tinkering now with stepping up the intervals for the sleep timer to find out which one works best, at least for my setup. I don’t know if it’s simply because I am making an image off of a VM or if this would be a common issue seen by all. Though I don’t know that many people are using this particular setup.
My init.gz size is 9.7MB versus the 12-13 MB of the original one. I don’t know what I changed, but it’s probably the busybox config more than anything.
I’m taking down the tarball for now as it will probably be a couple of days until I get the sleep timer just right. Hopefully this is okay for everybody.
Sorry,
There were a few components missing from this. I didn’t build my own busybox configuration or use the one that FOG graciously provides for us. I’m trying to limit size a little, so hopefully after this run, fdisk and all the bobs and bits from the filesystem for partclone is all available. The file will still be named the same once uploaded.
Thanks all,
So here’s the buildroot that I use:
[url]https://mastacontrola.com/fogboot/buildroot-2013.08-rc2_FOG.tar.bz2[/url]
If you’re to wget the file, as always, use:
wget --no-check-certificate [url]http://mastacontrola.com/fogboot/buildroot-2013.08-rc2_FOG.tar.bz2[/url]
It’s rather large, I know, but it’s preconfigured with everything we need including the buildroot .config and it builds on Centos 6.4 with no issues. I haven’t built it on other OS’s. You will need the normal development information for building this thing, but a couple things that I needed to add were glibc-static and perl-ExtUtils-ParseXS and all dependencies needed there.
The file is about 300MB in size, and it will take a while to download as I’m only sporting 5MB upload speeds, sorry guys, but it’s better than nothing right?
Maybe others can look at what I’m doing wrong to find out the partitioning issues?
You do the normal building with:
make ARCH=i386
If you want to edit the packages to install, that’s up to you, but you will need to download it. When you setup for this you do the normal:
make ARCH=i386 menuconfig
Hopefully people find this useful.
Also, my buildroot actually builds partclone and partimage natively so I’ve modified the fog package and rather than using customize within the package directory, I just placed the FOG components in the package directory.
Thanks guys,
A quick search of the error comes up with a MS article:[url]http://support.microsoft.com/kb/2466753[/url]
This could be your setup as well. Make sure to try SP1 versus non sp1 win 7.
It almost sounds like a 64 bit vs. 32 bit problem. I don’t have experience with nComputing. But I’ve seen similar issues trying to install 64 bit win 7 on netbooks.
The recommended disk upload type depends on disks in the system. Do you have multiple disks in the systems? The blank disk is probably because they’ve never been initialized which means you need to fdisk them just to write a quick value to them.
Updated due to autocorrect from mobile device.
Alright, I spoke a little too soon. That doesn’t mean I haven’t made success. I won’t post the file here, just the link as when compressed with all dl files needed it’s about 300MB which I’m certain is too large for this forum.
I’ll get the upload working on both partitions, as soon as I figure out why it’s not exactly.
It’s still in it’s prelimary, but I think I’ve finally created a modernized init.gz file that works. The only thing I’ve not tinkered with so far is lessening the packages available in it so we don’t have a 17MB init.gz file, though I suppose ultimately that doesn’t matter. Bash is included as well just as a safe measure from my reading a different post with dd and gzip relying upon bash existing.
Once I’ve tested the uploads, if it’s successful, I’ll tar the exact file up with DL’s and host it on my personal site as I don’t think this forum will store a file that large. If it can be here, I’ll put it here as well.
Thanks,
You’re very welcome then.
So I’ve given up on my venture towards building a modernized custom init.gz. I’ll just modify the current one as needed. I know I’ve been busy with these all, but when I buildroot2013.05, it loses partitions, when I buildroot2011.08, the file’s too large. I don’t know where I’m going wrong, but I think the fog custom components (the scripts, etc, init) should just be a part of the skeleton rather than built as a package, but this would require modernized scripts as well.
As I’m trying to understand a bit further,
Your tablets are connected to Docking stations with LAN ports built in. Do these docking stations have PXE/GPXE Support for them? When you boot the system up and get into the bios, does it give options for PXE booting with and/or without the Docking station connected?
Is there a possibility of multiple areas in your BIOS for PXE booting?
The last thing I can think of,
Are the tables UEFI enabled? If their UEFI enabled, is it Security Enabled as well? If they are, have you tried disabling UEFI on the system and then PXE booting? I have about 200 systems that came in for this year with UEFI enabled, but security was disabled and legacy mode was enabled. I didn’t have to disable UEFI and all worked fine. I’ll see if I can test the system with Security enabled and pxe boot. My systems are not tablets, they’re regular desktops, but it’s about as close to troubleshooting as I can get.
I’m sorry if you’ve already tried all of these things.
What’s up everybody?
Just wanted to post a little more info. I’m now going to give up, for now, on 2013.05 build root and try stepping back to 2011.08 just as a shot. I’m working towards building more modern software on top of it including 3.10.9 headers. This does pose a slight issue in that apparently there were all types of issue in busybox 1.18.5 and linux-2.4 where they had to create their own struct sysinfo portions to let the kernel work. This is important to know because when you’re setting up the toolchain and change header information from 3.0.X Headers to 2.6 Manual entry mode, it, from what I can tell, degrades to 2.4 specs and there’s quite a lot of editing to work on. So rather than type all of the editing I did, I’ll (once successful) post the busybox-1.18.5.tar.bz2 file with the modifications I’ve made to make this actually build.
When you can, in your buildroot directory edit the file:
output/host/usr/i386-unknown-linux-uclibc/sysroot/usr/include/sys/sysinfo.h
At the top of the file, place:
#include <sys/sysinfo.h>
and
remove the lines referencing struct sysinfo.
There’s another caveat that I haven’t figure out quite yet in the error that keeps cancelling out is:
make[1]: Leaving directory `/home/buildroot-2011.08/output/build/busybox-1.18.5’
make: *** [/home/buildroot-2011.08/output/build/busybox-1.18.5/.stamp_built] Error 2
Seemingly when a part of the build is referencing libbb/lib.a
As far as I can tell, everything will continue on if you simply re-type make ARCH=i386, but it’s kind of a nuisance to have to do this many many times throughout busybox’s build period.
Best of luck. I can’t guarantee anything, but if you can give me details from a hardware component setup of your system I could potentially build a kernel specific to your system so we know all aspects would work.
I’m not sure of the non-standard layout issue directly, but simply renaming the image files isn’t going to be of much help. If you can pull a resizable image, that’s awesome, as I’ve had very little luck unless I sysprep the machine first. However, I’d suggest using a smaller drive and build your system exactly as you need. Try using the smallest drive you can create your system with to create a master system. Then, when you upload the image, use Multiple Partition Single Disk. FOG, ultimately, shouldn’t care how the partitions are ordered, so long as it copies the data. The problem with your renaming of the d1*.img files is that there are actually three files created in this method. The first file is usually d1.mbr which (as the name suggests) is the mbr of the hard disk. Then d1p1 is usually the 100MB partition windows installs naturally. Then usually your d1p2 is the main system image. I don’t know how many partitions your current setup actually uses but from what I can tell in the files, FOG only allows up to 2 partitions. That’s not to say you couldn’t make more available, just it isn’t very supportive of more than two in either case.
When you do a resizable image, there is only 2 files created:
rec.img.000 which is usually (from what I can tell thru my testing) is the mbr [B]AND[/B] recovery partition all in one. The sys.img.000 file is obviously the main system image. This might be why you’re seeing the issue with the boot\bcd error as your method isn’t actually re-writing the mbr to the system.