svn image doesnt push

[KKTwenty101]

ok a simple fix that has worked for me. Using https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image as a reference to edit init.xz In funcs.sh I have altered gethardisk() as follows (since CAT works for me I have added it to the CAT function after fogpartinfo). I basically murder the partition table with “dd” then add a label, that should be enough to cure my blank drive issues anyway.

Lets check and see if the partition shows up in /proc/partitions

	for i in hda hdb hdc hdd hde hdf sda sdb sdc sdd sde sdf; do
		strData=`cat /proc/partitions | grep $i 2>/dev/null`;
		if [ -n "$strData" ]; then
			hd="/dev/$i";
                            #** this is the new bit **
			echo;
			read -r -p "Partition error. Do you want to murder the partition table for $hd? [y/N] " response
			if [[ $response =~ ^([yY][eE][sS]|[yY])$ ]]
			then
				#murder the partition table - this shouldnt need a restart
				dd if=/dev/zero of=$hd bs=512 count=1 conv=notrunc;
				#label the emptiness - should be enough to get the system to continue
				parted $hd --script -- mklabel msdos;
			fi	
                            #** end of the new bit **
			return 0;
		fi 
	done

[Tom Elliott]

@KKTwenty101 What version of fog are you running?

[Tom Elliott]

@KKTwenty101 Would you be willing to try trunk? I’ve made MANY changes since 1.2.0, and one of the largest changes is how partitions are found and recognized. I no longer limit found partitions to those within hd[a-f] sd[a-f]

[KKTwenty101]

I do have a trunk VM server on stand by but needed to drop back to 1.2.0 - I ran out of time setting it up. My intention IS to use trunk and i’ll try to get some time later on this month. Luckily I have lots of empty drives I can use!

The biggest error I got was 2202 errors joining the domain using client 0.9.5 but I see that a new client is out - perhaps 0.9.6 fixes that. Allegedly 2202 errors are AD errors relating to username and passwords but I have no issues with 0.1 client on 1.2.0 (and I did try both “legacy” fogcrypt and the new “just type it in” passwords in trunk).

give me a week and i’ll get back onto trunk.

[KKTwenty101]

Trunk still fails. Exactly the same error. I can fix it if I MANUALLY run the same bit of script I do below but im currently navigating my way around the new init.xz layout. Funcs.sh has changed completely so i’ll have to learn how the new structure works. Either way I am going to add my hack to get completely blank drives to work, when I do i’ll post it up. Trunk is almost working for me…

[KKTwenty101]

Fixed.
Used https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image and modified /bin/fog.download

#fix for possible dodgy partitions on the disk
testdisk="";
testdisk=`fogpartinfo --list-devices 2>/dev/null`;
#this will either give us something or nothing
if [ -z "$testdisk" ]; then
  echo;
  read -r -p "Partition error. Do you want to murder the partition table for $hd? [y/N] " response
  if [[ $response =~ ^([yY][eE][sS]|[yY])$ ]]
  then
    #murder the partition table - this shouldnt need a restart
    dd if=/dev/zero of=$hd bs=512 count=1 conv=notrunc;
    #label the emptiness - should be enough to get the system to continue
    parted $hd --script -- mklabel msdos;
  fi
else
 echo "checked $testdisk for partitions (no need to kill partition table yet)";
fi

I put this before the imgtype checks

# Generates the partitions.  If singledisk resizeable, it generates
# based on default normal values.
# Otherwise it uses MBR/GPT to generate the partition table(s).

After that I get a VERY healthy speed increase (PIGZ 7 uploaded on a 4core 4gb @ about 1gb/min). This client is a modest 3ghz Core2Duo with 2gb RAM.

Testing was done on multiple brands of HDD and 2 brands of SSD reproducible. If the drive had already been cloned (some had been cloned from previous upgrades) then the system worked without my fudge. If the drive was brand spanking new out of the packet then there was a chance this would happen (both sandisk and Kingston SSDs were totally blank, the Seagate was blank but the WD was not and worked without the fudge)

[Wayne Workman]

@KKTwenty101 Very nicely done.

So in a nutshell, this makes fog work with blank drives? Hash tagging this for the wiki

[KKTwenty101]

@Wayne-Workman yes. Not sure if it is the cleanest of solutions though, however it will work for me, if it gets to this point in the cloning process then I don’t care if I kill the partition table and give a nonsensical label - there maybe purists who aren’t happy with this.

There are probably countless pitfalls that might happen, such as wrong drive selected in multiple drive systems resulting in the wrong drive having its first 512 murdered - that isn’t an issue for me but at least it defaults to N

[Wayne Workman]

@KKTwenty101 Added to the WiKi: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_Downloading_-_Unicast

Thanks for the screenshot - they really help out a TON because I cannot easily replicate the errors that people run into - when screenshots are posted here it makes documentation SO much easier! Thanks again for your fix! We need more people like you using fog.

[Wayne Workman]

@Sebastian-Roth Does the potential changes in this thread:
https://forums.fogproject.org/topic/6295/capture-task-not-completing-after-finishing-and-then-loops/36
Make the proposed code in this thread for handling blank drives unnecessary?

[Sebastian Roth]

@Wayne-Workman Good catch! I had exactly this in mind when I said that we had issues with empty disks with fogpartinfo. The new method (using lsblk) should work on empty disks. Would be interesting if someone could test this as well. Easiest would be to boot an unused client into debug mode. Then use the dd command from KKTwenty101’s posting to “murder the partition table”. After that try deploying (using the init files I posted) to that client.