svn image doesnt push

Tom Elliott

THe fact that it isn’t able to find the disk at all tells me something much more sinister is going on.

Not sinister in a “bad” way I suppose, but it means it isn’t finding the partition layout of your disk.

Sebastian Roth

Try this: After unsuccessful deploying to a machine schedule a debug job for this same host and let it boot up till you see the shell. Then run fogpartinfo --list-parts /dev/sda and let us know what you see (picture would be best).

And maybe also take a look at fdisk -l /dev/sda and gdisk -l /dev/sda

KKTwenty101

shut down my SVN trunk server host and booted my 1.2.0 back up. This images to a physical and hyper-V client fine so I’m knocking trunk on the head for the time being as I cant devote any more time to it. I agree that it makes no sense as I imagine the front end hasn’t actually changed much. I must have made some sort of mistake installing trunk, i’ll dig it out again at Christmas when I get more time and start (again) from scratch.

KKTwenty101

@Sebastian Roth I have moved back to 1.2.0 but can guess what the results would have been - the HDD would have had 2 partitions, 1xW7 reserved, 1x primary NTFS. The SSD was fresh out of the packet so I guess would have had nothing (no partitions). The hyper-v host was a freshly created VHDx so again would have had no partitions on there.

I’ll try and remote in tonight and play a little more, i’ll post back more concrete results if I can.

Sebastian Roth

Ohh, now I see that “Stopping FOG Status Reporter” (which should happen after partclone) comes right after “Looking for Hard Disks”. Is this the case on VM as well as hardware??

Usually we see FOG finding the harddisk and writing MBR to disk and then failing because it cannot read back the partitions (e.g. too large for the disk). In your case try fogpartinfo --list-devices.
You’ll most probably see this:

fogpartinfo --list-devices
Error: Invalid partition table on /dev/sda – wrong signature 0.

Make sure to create a partition table on new disks and you should be fine. This is something on my todo list but I just cannot find the time to code a proper workaround for this. fogpartinfo is using libparted which is not happy enumerating completely empty disks.

KKTwenty101

I have just remoted in and you are correct. I used gparted live to create a simple fat32 partition and it worked, I now have a trunk upload and download working. Now I only have to sort out the 2202 error joining the domain using the trunk fog service client (hostname changer and domain join works fine in the 1.2.0 server and whatever fog service comes from that version) but since Ive been hogging the forums recently i’ll give someone else a go as I really cant give any more time at the moment!

Don’t worry, when I have all this up and running I will do a writeup on how I got Centos 6.7 working with fog trunk! (if only for my own notes when I search the forums in another year time…)

Luckily we have an apprentice who will love to run gparted live on the 114 SSDs we are priming for our 8.1 rollout next January

Wayne Workman

hash tagged this content for addition to the WiKi.

edit: added.

KKTwenty101

I am going to butcher gethardisk() in funcs.sh and force it to remove and repartition (with a read case of course), rebooting as necessary and carry on. Not exactly friendly for other people but it will work for me (hopefully!).

whilst fogpartinfo --list-devices barfs the next CAT portion DOES return /dev/sda but the next partitioning section in fog.download doesn’t work (even with debugpause things don’t become clearer). I suspect that if I can clear partitions, create a “simple” FAT32 partition and reboot then things might work out. Watch this space…

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.

svn image doesnt push

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

248

12.0k

17.3k

155.2k