Are you running FOG 0.33? The init.gz has a few changes to it which may be causing the issue. I don’t when I followed the build a custom init information, using a newer version of buildroot, I ran into the same type of issue because it never even copied the right file structure to the host.

fogclient.localdomain is just the name the PXE file system is using. The Reason your fqdn isn’t working is probably due to DNSMASQing is not configured for domain name distribution. I could be wrong, but I think you have to use IP for the imaging process. Using hostname is easier to remember, but it also requires DNS lookups to be accurate and updated quite regularly. Remember that the loading of FOG during pxe boot is a very minimal OS and it doesn’t mean that all components work as you expect. I’d stick with setting the IP for your <yourfogserver> section.

Which config file did you use? Also, did you do make ARCH=i386 menuconfig and make ARCH=i386 bzImage?

is it finally able to open /proc/partitions or are you still having this error.

Have you had any luck, or is it still rebuilding?

Take a look at your fog servers mysql system. Check that the bind-address field is set for your servers IP address rather than 127.0.0.1

You’ll have to restart mysql server, but it may help in communicating across the network. This is what, I’ve found, it usually has the issue with.

I don’t know what was done in the menuconfig portion of your setup. Which configuration file did you use?

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

It’s based on 3.10.7

My guess is the reason I’m not seeing both partitions get made is a lack of timing to register that it still has to process the sys partition.

Well, that’s not the case. I’ve added a statement to this upload process to watch when and what’s happening along with a couple of sleep statements in between. It seems to recognize the command and variables properly, just won’t run the system.

Alright, I had to do some, slightly heavy, modding to chntpw-source-110511.zip so I’ll upload it here in case any one else finds it useful.

As I had to mod the file, I removed the Makefile patch from the package/customize/chntpw folder as well, so I’m not trying to patch the files I already fixed to get working with buildroot2013.05

[url=“/_imported_xf_attachments/0/386_chntpw-source-110511.zip?:”]chntpw-source-110511.zip[/url]

One other change that needs to happen is:
in package/customize/chntpw/chntpw.mk
Change line 22 from: toolchain/patch-kernel.sh $(CHNTPW_DIR) package/customize/chntpw *.patch
TO:
support/scripts/apply-patches.sh $(CHNTPW_DIR) package/customize/chntpw *.patch

And change any other files that may make the same reference. Of toolchain/patch-kernel.sh to support/scripts/apply-patches.sh (e.g. selectcore, pigz, dmidecode, and chntpw)

Just for assurance,

uLibc is being built on:
0.9.33.2
gcc is being build on:
4.7.3
Kernel headers are:
3.10.9
Binutils are at 2.23.2
Busybox is still 1.21.0

I don’t know what else to place.

I’ll post my config file once I get it all working, but more, or less, it’s the same as it was, with the changes from fs/skeleton to system/skeleton and with target/generic/device_table.txt to system/device_table.txt

I’m also attempting to remove ntfsprogsfog and parted as that is built into to system naturally. Partclone is added, but I don’t know if it’s compiling. It probably doesn’t help too much that fog/scripts is directly copying the files to the filesystem.

[url=“/_imported_xf_attachments/0/385_mybuildroot.txt?:”]mybuildroot.txt[/url]

Ran into a few issues. First, the kernel headers needs a few lines input into the sysinfo.h file. You can download the kernel and unpack it. Then do a search for sysinfo.h, there are multiple, but do the one in the ./include/uapi/linux/sysinfo.h folder of the kernel-dir. You’ll need to add, near the top:
#ifndef __kernel_long_t
typedef long __kernel_long_t;
typedef unsigned long __kernel_ulong_t;
#endif
below the define _LINUX_SYSINFO_H part.
Once done, re-tar it backinto linux-<kernelver>.tar.bz2
In selectcore, make a change to:
package/customize/selectcore/selectcore.mk file on line:
27 from
$(CONFIG_UPDATE) $(SELECTCORE_DIR)/build-aux TO:
$(call CONFIG_UPDATE,$$(SELECTCORE_DIR)/build-aux)

Hello all,

I know I’ve been rather busy on fog these days, but I’ve just been trying to come up with things to help the whole project out.

I am, by no means, a developer, but I am a very avid computer enthusiast who likes to tinker around.

I’ve been trying to build my own init.gz file for use within the fog system, and I’ve been, for the most part, successful.
Only a couple of parts have confused me.

Using the WIKI page, I see that we are supposed to be using buildroot2011.08 but I’ve never had success with that particular version. I’ve had, however, success with buildroot2013.05.

There’s one part, though, that keeps eluding me. That part is the pigz portion. If I use the init.gz that’s prebuilt, uploading of rec.img.000 and sys.img.000 works flawlessly. When using a my custom one, it uploads, just fine, the rec.img.000 file, but then it completes the upload.
Downloading is a whole different issue that I’ve yet to succeed with. With that aside, I’ve been trying to build a more up-to-date init system anyway as the headers currently in use are 3.0.4 and I think it’d be more suited for a more updated kernel tree.

The item I have, for the developers, if you’re willing to share is how to get things to compile properly and what changes, I think, should have to be made for this all to work. Can anyone tell me what’s missing? I’ll give the link to my version of init.gz just to see if their’s anything that I can correct to get pigz to work for both rec and sys img files.

First things first, the device_table.txt file, in more recent versions of buildroot, is now located at system/device_table.txt rather than target/generic/device_table.txt

Also, the custom path for the fs is now:
system/skeleton rather than fs/skeleton

I’m still unsure about pigz, but many of the customize scripts need the last line changed from:
[COLOR=#000000]$(eval $(call AUTOTARGETS,package/customize,parted))[/COLOR]
[COLOR=#000000]to:[/COLOR]
[COLOR=#000000]$(eval $(autotools-package))[/COLOR]
I don’t know what else to share from here. At least I have, for the most part, a working init.gz, though I’m unsure of how to build custom packages for buildroot. Maybe somebody can help me?
I know that partclone can do many things but depends upon the utilities and tools to operate, so we’d have to include them. At the very least, we’d have to include ntfsprogs, e2fsprogs, and maybe btrfs-tools and possibly more but I don’t know what I’m doing totally. I’ll try to tinker and play, but I can only do so much alone.

Well, I hope this works for you. I’m sorry I wasn’t much help, but it sounds like it was probably just a bad drive causing all of this headache. To test, while this one is rebuilding, do you have another storage node that has enough space that you could test with?

Do you know of any tools to test the disks within the LVM to find out if your disks are okay?

Here’s what my output looks like!
— Volume group —
VG Name vg_mastavirtual
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 5
Act PV 5
VG Size 4.16 TiB
PE Size 4.00 MiB
Total PE 1089666
Alloc PE / Size 1089666 / 4.16 TiB
Free PE / Size 0 / 0
VG UUID Y86n60-8kTN-Akpl-Ixkm-jcUK-iqNG-UIFXV6

Then a pvdisplay shows:

— Volume group —
VG Name vg_mastavirtual
System ID
Format lvm2
Metadata Areas 5
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 5
Act PV 5
VG Size 4.16 TiB
PE Size 4.00 MiB
Total PE 1089666
Alloc PE / Size 1089666 / 4.16 TiB
Free PE / Size 0 / 0
VG UUID Y86n60-8kTN-Akpl-Ixkm-jcUK-iqNG-UIFXV6

[root@mastavirtual ~]# pvdisplay
— Physical volume —
PV Name /dev/sda1
VG Name vg_mastavirtual
PV Size 465.76 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 119234
Free PE 0
Allocated PE 119234
PV UUID NQYnUI-WNc1-4usj-uMSO-ZLTc-4O7k-pWWx2M

— Physical volume —
PV Name /dev/sdb1
VG Name vg_mastavirtual
PV Size 698.64 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 178850
Free PE 0
Allocated PE 178850
PV UUID aBQhCX-0A1r-EupN-bJsv-tAWf-HEdA-soXPfC

— Physical volume —
PV Name /dev/sdc1
VG Name vg_mastavirtual
PV Size 298.09 GiB / not usable 4.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 76310
Free PE 0
Allocated PE 76310
PV UUID cE19Nu-51wP-UdvP-K8ak-BeFA-PLtd-cr4h2l

— Physical volume —
PV Name /dev/sdd1
VG Name vg_mastavirtual
PV Size 931.51 GiB / not usable 4.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 238466
Free PE 0
Allocated PE 238466
PV UUID Th8qJh-j1Y8-g20V-xlL9-Jkqv-WsRl-3T5gKy

— Physical volume —
PV Name /dev/sde2
VG Name vg_mastavirtual
PV Size 1.82 TiB / not usable 4.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 476806
Free PE 0
Allocated PE 476806
PV UUID fUVEMi-fdqY-1QgK-yRVY-oU75-5oBb-XtmCZD

So is /storage a part of an LVM?

What is the output of vgdisplay?

This weekend was rather busy for me, but I did take some time to try out a few things. It looks like the init.gz package from the 899 revision already contains the components for partclone. However, I can’t figure out how to get the /bin/fog script to actually use it. I tried editing the file, especially pertaining to Windows 7, and tried getting it to use part clone with the commands:

partclone.ntfs -c -s <hard drive/partition> -o <file to save as>

and

partclone.restore -s <filename> -o <hard drive/partition>

But i kept getting the typical invalid syntax response.

I am going to try, in debug mode, to mount the nfs share and commandline partclone to find out exactly what I need to do to get partclone working.

For right now, I’m just lost in the sauce trying to figure out how to get this to work. My hopes are that partclone will work better for the single disk, resizable than partimage currently does.

One question I have though, hopefully somebody can answer, is How come, during the deploy process for Single Disk, Resizable, there isn’t a method to recreating the first partition? The lines that I find are:

                                elif [ "$win7partcnt" == "2" ]; then 
                                    win7part2start=`parted -s $hd u kB print | sed -e '/^.2/!d' -e 's/^ [0-9]*[ ]*//' -e 's/kB  .*//'`; 
                                    if [ "$win7part2start" == "" ]; then 
                                        handleError "Unable to determine disk start location.";
                                    fi      

                                    adjustedfdsize=`expr $sizefd + $win7part2start`;
    
                                    parted -s $hd u kB rm 2 &>/dev/null;
                                    parted -s $hd u kB mkpart primary ntfs ${win7part2start}kB ${adjustedfdsize}kB  &>/dev/null;

Now I understand that the mbr, supposedly, gets rewritten after the imaging begins, but what I’m finding, is that the partitions aren’t deleted and their not recreated.

Also notice, there’s nothing stating which part is the boot partition either.

I guess I just don’t understand enough of the system, but it would seem to me that we would need somthing like:

                                elif [ "$win7partcnt" == "2" ]; then 
                                    win7part2start=`parted -s $hd u kB print | sed -e '/^.2/!d' -e 's/^ [0-9]*[ ]*//' -e 's/kB  .*//'`; 
                                    if [ "$win7part2start" == "" ]; then 
                                        handleError "Unable to determine disk start location.";
                                    fi      

                                    adjustedfdsize=`expr $sizefd + $win7part2start`;
                                     
                                    parted -s $hd u kB rm 1 &>/dev/null
                                    parted -s $hd u kB mkpart primary ntfs 2048s ${win7part1end}kB &>/dev/null;
                                    parted -s $hd set 1 boot on &>dev/null
                                    parted -s $hd u kB rm 2 &>/dev/null;
                                    parted -s $hd u kB mkpart primary ntfs ${win7part2start}kB ${adjustedfdsize}kB  &>/dev/null;

This would need to happen anytime the system is being written, but maybe not so much on the Multiple partitions as the MBR is directly written which should, theoretically, contain the partitioning of the hard drive so it can continue with no issues.

For Single Disk, resizeable, this doesn’t happen and the partitions, apparently, are removed, but not properly recreated. This causes an issue in that that rec.img.000 gets installed, but because ${hd}2 doesn’t exist, sys.img.000 can’t be written to the 2nd partition, so it just continues on like the deploy has completed.

I guess that would do it as well. Awesome man. Maybe try posting your findings into the tutorial section so others can troubleshoot their issues a little quicker as I’m sure this isn’t the only one to have happened.