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.

Alright man,

Sorry I wasn’t able to help out too much but good luck. Maybe I can help with your other issues then.

It sounds like it’s your kernel.

I’ve build a, relatively small, kernel, that (yet to be fully tested) doesn’t rely upon your video card, so shouldn’t cause a green screen.

You can download it at:
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] (~6.5MB)

If using wget use the command:

wget --no-check-certificate [url]http://mastacontrola.com/fogboot/kernel/bzImage[/url] (~6.5MB)

It’s based on PeterSykes Config with a few modifications for proc and is based on 3.10.9 if you want to try that.

Give me about 15 minutes as I’m currently performing updates on my servers.

EDITED TO REFLECT PROPER LINK: Missed kernel after fogboot (sorry)

I’ve tried a diff of my init.gz and the FOG built init.gz, and, really, the only main differences I’m finding are binaries that I’m using are slightly more modern. Things like pigz is 2.3, clamav is set for 0.97.8, my customized chntpw-source-110511.zip, parted-3.1, the buildroot packaged version of ntfs-3g and tools, and gptfdisk from the buildroot system. It just seems strange that a customized version of init.gz would lose a partition after partimage runs.

I’m still not having any luck with a custom init.gz file.

I’ve followed the instructions on the WIKI page, but it just doesn’t seem to work with even the direct copies from what the WIKI page states, or with my modified versions. If I fix all the minor issues with the absolute instructions given, or if I use my own, uploading an image will only copy the rec.img.000 file when I set the system to do a Single Disk, Resizable image. I’ve modified the fog script so output information and sleep at various times, at it seems, with the custom built init.gz system, after it finishes copying rec.img.000 it, seemingly, removes the ${hd}2 variable from availability, but right before it does the first partition copy, it does exist. If I use the init.gz file that FOG has already created, all works fine. I’m just trying to figure out what the main differences are.

Can anyone help?

Clamav isn’t the problem its the script that fogs using to do the scan. The scripts error checking is only allowing NTFS.

Yes but you may be better off looking at the init.gz file and find which controls clamav scanner and make a few tweaks to allow it to scan the fat32 parts. If you have it there it could get a virus.

Fat 32 is not NTFS and I’ll bet the fog source is requiring NTFS.

Also don’t be afraid to try local boot 0x80

Yes, our storage node is set to allow 15 clients as well as the other two places specified, but it still doesn’t work in our setup. It’s not a huge deal for us though, as our images are fairly small and everything is gig-e.

The questions that need to be answered are:

When you receive your systems, do they come with a restore CD and are they, if you turn them on, preinstalled?
Are the systems you receive, more or less, the same system?
Are the systems you receive SLP keyed
If you where to use the cd do you have to enter the key or not; if you don’t need to enter a key, you’re systems are probably SLP keyed.

The reason these are asked is I can tell you a simple answer. If the systems are SLP keyed and have licenses for each system, you can upload an image of one system, and push that image to all clients of the same make and model. No Sysprep or anything.

I’m sorry. And I’ve noticed, with FOG 0.32, this doesn’t matter. We have all of our configs (even if deprecated) set for max of 15 clients, but as soon as 10 clients are downloading, the limit is met and anything after just queues up. We’ve restarted the server to make sure it wasn’t just a service needing to be restarted, and this didn’t help. It seems like the queue is set at 10 no matter what we do. Now I haven’t looked into funcs.sh or the /bin/fog script so maybe I’m just being silly, but it seems like it’s a constant that we can’t change for now.