Posts made by Tom Elliott

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.

So rpcbind from alternate subnets requires mysql to allow connections from its Ethernet and not local host. I guess that makes sense. I wouldn’t have thought of that so awesome man.

Just a track for understanding,

All systems are communicating via PXE and able to load bzImage and init.gz to attempt to start. After that, when it tries to connect to the NFS <fogserverip>:/images/dev and systems not within the same subnet cannot connect?

As your systems within the same subnet of the fogserver communicate properly, it isn’t a storage node user configuration issue, as far as I can tell. It also wouldn’t be a storage_ftp user issue either as you’ve already uploaded the images.

The only thing it seems like, is the internal network can’t route through to the fog server’s ip address to connect to the nfs share. This is why I would suggest port forwarding, for each of the switches in the path, to point directly to the fog server.

Maybe see if you can change the router to the gateway that all the subnet’s can communicate with each other across. This would typically be the DHCP server itself which, as far as I can tell, works perfectly fine. Maybe have your switches forward the nfs ports to your fog server. 111 and 2049 are the typical ports.

Other than that, I don’t know. Maybe setup dhcp for tftp to use the same LAN as your fog server?

Maybe check firewall on the fog system or network.

It isn’t pxe unable to mount it at that point. It’s the kernel. bzImage is that kernel. What version are you using? Try upgrading and see if that’ll help maybe?

Looked up the issue and found a page with similar issues as yours:

[url]http://fogproject.org/forum/threads/fog-32-on-ubuntu-11-10-unable-to-upload-image.852/[/url]

It sounds like nfs-kernel-server is having issue actually mounting. One issue I ran into on my setup was RPC, but I’m running centos which is redhat based. I just installed rpcbind and had to add fsid=1 to images and fsid=2 to images/dev so my exports looks like:

/images *(rw,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)

Looking into this further, try removing rpcbind and just:

apt-get install nfs-common nfs-kernel-server portmap

I was looking into the init.gz system, but I haven’t been able to figure which parts happen in which order. There’s kind of a lack of comments. So this will be one of the long winded projects, where I try to break the system to figure out exactly what’s happening and when. Hopefully we’ll see partclone working here shortly. I’m actually looking to figuring out how to build partclone into the initrd filesystem and maybe figure out how I can use it.

apt-get install apache2 php5 php5-gd php5-cli php5-mysql php5-curl mysql-server mysql-client isc-dhcp-server tftpd-hpa tftp-hpa nfs-kernel-server vsftpd net-tools wget xinetd sysv-rc-conf tar gzip build-essential cpp gcc g++ m4 htmldoc perl libcrypt-passwdmd5-perl lftp openssh-server php-gettext clamav-freshclam rpcbind nfs-common

try this:

apt-get remove portmap;
apt-get install nfs-kernel-server nfs-common

try removing rpcbind and nfs-kernel-server
then try to have apt install them

I don’t know what else to work on then.

try
apt-get install rpcbind nfs-kernel-server
or
apt-get reinstall rpcbind nfs-kernel-server

I don’t remember ubuntu’s method of on boot startup, I think it’s update-rc

[COLOR=#333333][FONT=UbuntuMono]update-rc.d rpcbind nfs-kernel-server[/FONT][/COLOR]

make sure both nfs and rpcbind are set to start on boot. Then I’d say try restarting the server, see if that helps you out at all.