Lenovo Thinkcentre Edge 72 issues
-
No,
Upload is creating the image and placing it on the server.
Download is placing the image onto the system intended.
Upload -> Deploy from client to server
Download -> Deploy from server to client -
[quote=“Tom Elliott, post: 20654, member: 7271”]I’d recommend, performing upload - debug mode in your case.
I’m assuming you’re running FOG 0.32, in which case, the upload commands for your system would be:
Assuming your doing a multi-partition image:[code]mkdir /images
mount -o nolock,proto=tcp <IP.OF.FOG.SERVER>:/images/dev/ /images
mkdir /images/{temporarynameofimageupload}
mkfifo /tmp/pigz1
pigz -p 1 -3 < /tmp/pigz1 > /images/dev/{temporarynameofimageupload}/sys.img.000 &
partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog[/code]Download, you should be set. Though I’d recommend, performing the testdisk MBR fix and then reupload the image to the server using regular means.
Once you’re complete with the image upload process, log in to your FOG Server as root and type into a terminal window.:
[code]mv /images/dev/{temprorarynameofimageupload} /images/{IMAGENAME}[/code][/quote]
Thanks a lot Tom for these infos !
Right : FOG 0.32
The upload proccess went ok, except a little code error about image location:
[CODE]pigz -p 1 -3 < /tmp/pigz1 > /images/dev/{temporarynameofimageupload}/sys.img.000 & partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog[/CODE]
that has to be:
[CODE]pigz -p 1 -3 < /tmp/pigz1 > /images/{temporarynameofimageupload}/sys.img.000 & partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog[/CODE]
Then I moved image from /images/dev to /images/pc1sda2 and chmod -R 777 /images/pc1sda2.
FOG did not saw the image, so I created it with ‘multi-partition’ type.
Assigned pc1sda2 to a registered PC in FOG and tried to deploy image, I got : “image store corrupted, unable to load MBR”Then I assigned the ‘Single partition’ type to image and tried to Deploy-debug, FOG told :
[QUOTE]
osid=5
osname=Windows 7
mbrfile=/usr/share/fog/mbr/win7.mbr
storage=10.10.20.2:/images/
img=pc1sda2
part=/dev/sda1
[/QUOTE]
/dev/sda1 ?? I have imaged /dev/sda2 …
Thinking I have to tell FOG how to proceed, tried :
[CODE]mkdir /images
mount -o nolock,proto=tcp 10.10.20.2:/images/ /images
mkfifo /tmp/pigz1
unpigz -p 1 -3 < /images/pc1sda2/sys.img.000 > /tmp/pigz1 & partimage restore /dev/sda2 /tmp/pigz1 2>/tmp/status.fog[/CODE]
but last line gives :
[QUOTE]can’t read the following volume file : /tmp/pigz1[/QUOTE]
It seems that unpigz is not installed in the system.
Could you please assist a bit more so I could try to restore this imaged /dev/sda2 to another computer ?
Thanks in advance for your time.
Nicolas -
(sorry I can’t edit my post : edit box is empty)
So tried too :
[CODE]pigz -dc -p 1 -3 < /images/pc1sda2/sys.img.000 > /tmp/pigz1 & partimage restore /dev/sda2 /tmp/pigz1 2>/tmp/status.fog
[/CODE]But got same error code … -
[quote=“electronico_nc, post: 20693, member: 19779”](sorry I can’t edit my post : edit box is empty)
So tried too :
[CODE]pigz -dc -p 1 -3 < /images/pc1sda2/sys.img.000 > /tmp/pigz1 & partimage restore /dev/sda2 /tmp/pigz1 2>/tmp/status.fog
[/CODE]But got same error code …[/quote]When you’re trying to download through manual means, (deploy to the client) you don’t use pgiz in the same method. Which is why you’re seeing the issue.
You use this:
partimage restore /dev/sda2 /images/pc1sda2/sys.img.000 -f3 -bYou don’t need to pigz it, or unpigz it for that matter.
-
[quote=“electronico_nc, post: 20691, member: 19779”]Thanks a lot Tom for these infos !
Right : FOG 0.32
The upload proccess went ok, except a little code error about image location:
[CODE]pigz -p 1 -3 < /tmp/pigz1 > /images/dev/{temporarynameofimageupload}/sys.img.000 & partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog[/CODE]
that has to be:
[CODE]pigz -p 1 -3 < /tmp/pigz1 > /images/{temporarynameofimageupload}/sys.img.000 & partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog[/CODE][/quote]Sorry about the Typo, I’ll edit my post to fix this.
[quote=“electronico_nc, post: 20691, member: 19779”]Then I moved image from /images/dev to /images/pc1sda2 and chmod -R 777 /images/pc1sda2.
FOG did not saw the image, so I created it with ‘multi-partition’ type.
Assigned pc1sda2 to a registered PC in FOG and tried to deploy image, I got : “image store corrupted, unable to load MBR”[/quote]You may need to create the MBR on the system you’re going to deploy the image: manually from above. Then reupload the image using regular means, you shouldn’t have any more issues forcing you to do this manually, theoretically that is.
[quote=“electronico_nc, post: 20691, member: 19779”]Then I assigned the ‘Single partition’ type to image and tried to Deploy-debug, FOG told :
/dev/sda1 ?? I have imaged /dev/sda2 …
Thinking I have to tell FOG how to proceed, tried :
[CODE]mkdir /images
mount -o nolock,proto=tcp 10.10.20.2:/images/ /images
mkfifo /tmp/pigz1
unpigz -p 1 -3 < /images/pc1sda2/sys.img.000 > /tmp/pigz1 & partimage restore /dev/sda2 /tmp/pigz1 2>/tmp/status.fog[/CODE]
but last line gives :It seems that unpigz is not installed in the system.
Could you please assist a bit more so I could try to restore this imaged /dev/sda2 to another computer ?
Thanks in advance for your time.
Nicolas[/quote]unpigz is niether a valid command and nor should it be. You don’t need to unpigz, or decompress the image, with partimage which seems to be the issue here.
Hope this helps.
-
Sorry for the delay (I thought to have replied).
The restore command : [CODE]partimage restore /dev/sda2 /images/pc1sda2/sys.img.000 -f3 -b[/CODE]went OK.
Thanks again Tom !
Nicolas -
Hi all,
Just to get things straight: @electronico_nc have you been able to successfully create an image for these Lenovos that takes care of the MBR issue ?
Thank you very much.
-
Using standard FOG 0.32 :
In any case : if you choose PXE as first boot option, workstation will never boot on HD as fallback. [S]This seems to be due to FOG thinking every MBR is 512K large wich is false (2048 for these Lenovo).[/S]
You can try to modify chain loader but you won’t be able to boot on anything else than PXE and sda ( [url]http://fogproject.org/forum/threads/lenovo-m72e.3709/[/url] ).If you want to keep the original Lenovo MBR :
Manual image creation of [U]ONLY SDA2[/U] & upload :- Launch workstation to image in FOG upload-debug mode (select PXE @ boot), then create and upload the sda2 image to FOG :
[CODE]mkdir /images
mount -o nolock,proto=tcp <IP.OF.FOG.SERVER>:/images/dev/ /images
mkdir /images/{temporarynameofimageupload}
mkfifo /tmp/pigz1
pigz -p 1 -3 < /tmp/pigz1 > /images/{temporarynameofimageupload}/sys.img.000 & partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog
[/CODE] - On FOG server, move the uploaded image to the proper location :
[CODE]mv /images/dev/{temprorarynameofimageupload} /images/mygoodpc/sys.img.000[/CODE]
Manual image download of [U]ONLY SDA2[/U] to new workstation :
- Launch new workstation in FOG debug mode and copy image to sda2 :
[CODE]mkdir /images
mount -o nolock,proto=tcp <IP.OF.FOG.SERVER>:/images/ /images
partimage restore /dev/sda2 /images/mygoodpc/sys.img.000 -f3 -b[/CODE]
This way, you keep the original MBR and possibility to launch the factory Lenovo system restoration, but it is an “all manual” process…
I have modified Tom’s kernel to include a small ‘image2sda2.sh’ that avoids typing all commands to restore but it keeps being a pain to work with these Lenovo. - Launch workstation to image in FOG upload-debug mode (select PXE @ boot), then create and upload the sda2 image to FOG :
-
It’s not fog thinking every MBR is 512 “BYTES” not Kilobytes. That’s the specification of MBR. While Lenovo may use up to 2048 bytes, to get dd to work on it properly, you would type:
[code]dd if=/dev/sda of=/tmp/lenovo.mbr count=4 bs=512[/code]4 * 512 = 2048.
So it’s not a FOG thing, every system in the world that uses MBR, starts out with the partition information set onto the first 512 bytes (1st sector) of the hard drive. All information after (grub for instance) is after that initial 512. And in actuality, the 512 is the MBR and the Partition table, if you want only the MBR part of the disk without Partition information you would get the first 446 bytes of the disk with:
[code]dd if=/dev/sda of=/tmp/example.mbr count=1 bs=446[/code] The last 64 store the partition information directly.I’m not saying your way to fix it didn’t work, but just thought to clarify the points you made. MBR is always going to be the first 512, no matter what OS or Disk it is. If it’s mbr, 512 it is. All larger than that (as I used grub, and you said 2048 for lenovo) is extra information not associated directly with the MBR.
-
[quote=“Tom Elliott, post: 23505, member: 7271”]It’s not fog thinking every MBR is 512 “BYTES” not Kilobytes
…
[/quote]
Hi Tom,
Sorry about typo on MBR unity :oops: .
I was too hurry when I posted, I have edited the previous post.
Nicolas -
It’s all good.
-
Hello all,
Thanks for sharing that with us all. I’m going to try this fix in the weekend. In the meanwhile, setting up new machines by putting the default MBR via fdisk ^^
All the best.
-
I wish the best of luck to you then.
-
@danvaida : by curiosity, have you been able to use FOG with these Lenovo ?
