svn image doesnt push
-
hash tagged this content for addition to the WiKi.
edit: added.
-
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…
-
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
-
@KKTwenty101 What version of fog are you running?
-
@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]
-
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.
-
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…
-
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)
-
@KKTwenty101 Very nicely done.
So in a nutshell, this makes fog work with blank drives? Hash tagging this for the wiki
-
@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
-
@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.
-
@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? -
@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.