Latest FOG 0.33b
-
xz -C crc32 -z -c init > init.gz (I think)
That said, I don’t think that command will work.
extfs, ntfs, hfsp, btrfs, xfs are the partclone binary names. so if i read your script right, if it comes up as ext4, it’s going to try partclone.ext4 which is wrong.
-
[quote=“Tom Elliott, post: 21829, member: 7271”]xz -C crc32 -z -c init > init.gz (I think)
That said, I don’t think that command will work.
extfs, ntfs, hfsp, btrfs, xfs are the partclone binary names. so if i read your script right, if it comes up as ext4, it’s going to try partclone.ext4 which is wrong.[/quote]
administrator@fog:~/tmp/usr/sbin$ sudo ln -s partclone.extfs partclone.ext4
administrator@fog:~/tmp/usr/sbin$ sudo ln -s partclone.extfs partclone.ext3
administrator@fog:~/tmp/usr/sbin$ sudo ln -s partclone.extfs partclone.ext2works like a charm
-
[quote=“fabritrento, post: 21830, member: 21607”]administrator@fog:~/tmp/usr/sbin$ sudo ln -s partclone.extfs partclone.ext4
administrator@fog:~/tmp/usr/sbin$ sudo ln -s partclone.extfs partclone.ext3
administrator@fog:~/tmp/usr/sbin$ sudo ln -s partclone.extfs partclone.ext2works like a charm :D[/quote]
exist a develop environment where i can access and do testing? -
[quote=“fabritrento, post: 21828, member: 21607”]i tryed to modify fog script.
simply modified the line:
partclone.${fs_type} -c -s $part -O /tmp/pigz1 -N -f 1 2>/tmp/status.fog
with:
part_fs_type=
blkid $part | awk 'BEGIN {FS="\""} { print $4 }'### row patch to use correct partclone.fstype
partclone.${part_fs_type} -c -s $part -O /tmp/pigz1 -N -f 1 2>/tmp/status.fog[/quote]
alternatively we can insert this:
else
part_fs_type=blkid $part | awk 'BEGIN {FS="\""} { print $4 }'| sed -e 's/1/fs/g' |sed -e 's/2/fs/g'|sed -e 's/3/fs/g'|sed -e 's/4/fs/g'### row patch to use correct partclone.fstype
partclone.${part_fs_type} -c -s $part -O /tmp/pigz1 -N -f 1 2>/tmp/status.fog
partclone.${fstype} -c -s $part -O /tmp/pigz1 -N -f 1 2>/tmp/status.fog
fi
what is the more correct solution? -
hey Tom I am getting a new error now. This is after dropping my old database because the currpted client would not let me access much and starting a new one I re inventory the computer whiched worked fine but now I am getting this.
Unable to determain snapin status because the MAC address was not correctly formated.
-
[quote=“fabritrento, post: 21833, member: 21607”]alternatively we can insert this:
else
part_fs_type=blkid $part | awk 'BEGIN {FS="\""} { print $4 }'| sed -e 's/1/fs/g' |sed -e 's/2/fs/g'|sed -e 's/3/fs/g'|sed -e 's/4/fs/g'### row patch to use correct partclone.fstype
partclone.${part_fs_type} -c -s $part -O /tmp/pigz1 -N -f 1 2>/tmp/status.fog
partclone.${fstype} -c -s $part -O /tmp/pigz1 -N -f 1 2>/tmp/status.fog
fi
what is the more correct solution?[/quote]i’m testing image upload right now, in some minutes i say to you if patch worked…
-
Tom,
Could my errors be related to hyper-v?
-
I don’t know, what kind of errors are you getting now?
I’m currently working to fix multiple snapins to be deployed, so it could be that’s broken at the moment. I only got individual snapins working.
-
[quote=“fabritrento, post: 21837, member: 21607”]i’m testing image upload right now, in some minutes i say to you if patch worked…[/quote]
there is a problem, the blkid inclluded in init.gz don’t print the fstype.
on my server:
blkid
/dev/loop0: UUID=“04291dff-b6e6-4815-8549-b1a83d66f145” TYPE=“ext2”
/dev/sda1: UUID=“b842abee-3fbf-4347-a451-ec9e0b3b3aa8” TYPE=“ext2”
/dev/sda5: UUID=“0Oxvj0-osLb-ilwF-e7d0-oJeK-Za9o-IEsjcW” TYPE=“LVM2_member”
/dev/mapper/fog–vg-root: UUID=“b3e21764-e54a-4bbb-9907-0b9d05555c58” TYPE=“ext4”
/dev/mapper/fog–vg-swap_1: UUID=“82810d84-f19c-40ee-a3e8-fa51d6f6e84f” TYPE=“swap”on the client started with init.gz:
blkid
/dev/sda1: UUID=“b842abee-3fbf-4347-a451-ec9e0b3b3aa8”
/dev/sda2: UUID=“0Oxvj0-osLb-ilwF-e7d0-oJeK-Za9o-IEsjcW”i try to copy the binary of blkid by hand from server and re-run fog script.
-
That probably won’t work, but I’ll add it to the init.gz when I get a chance.
-
I am getting this error with out any snapins being deployed
Unable to determain snapin status because the MAC address was not correctly formated.
-
Is it because in fog the MAC address are using : and not -. I am not sure if that is the cause of the formatting error.
-
No, if you look at the access.log on your fog server, you can actually see the command being sent. I think, in my testing late last night, I set up different error tags to see if I could get things working, or see where they were failing. #!im was the error as it was easily identifiable. I may have forgotten to remove it from the snapins.checkin.php. I’ll be updating here shortly.
-
r1132 released.
Rewrite of the servicemodule-active script. Multiple snapins in deploy job works now. Error codes should be fixed.
-
Hey Tom,
Still getting invalid MAC error I attached fog service log.
[url=“/_imported_xf_attachments/0/513_fog2.txt?:”]fog2.txt[/url]
-
What’s your fog servers accesslog display for the snapins.checkin.php stuff?
-
I attached the logs and access log is just the end of the log let me know if you need more.
[url=“/_imported_xf_attachments/0/515_error.txt?:”]error.txt[/url][url=“/_imported_xf_attachments/0/516_accessupload.txt?:”]accessupload.txt[/url]
-
Let me guess, you have multi nics on the system?
-
yes I added both to fog though should I try to remove one the problem with hyper-v is they have two types of nics legacy adapter which boots from lan and the regular which I have not found away to have it boot from the lan So i needed to use both.
-
Don’t worry about it right now. I’m reuploading another revision which should separate the file.
