Deploy problem with Optiplex 3020
-
@Pascal-Gazaille Lets wait and see what Sebastian says. He’s a pro with HDDs.
-
@Wayne-Workman Tried imaging the hdd with a multiple partition image - all disk (not resizable) we use for our laptops and it’s working…
-
@Pascal-Gazaille huh… well, then this is a fog issue for sure! Notifying @Tom-Elliott and @Sebastian-Roth
Also to be sure, please re-upload the image you want as non-resizable and try it!
-
@Pascal-Gazaille said in Deploy problem with Optiplex 3020:
@Wayne-Workman Tried imaging the hdd with a multiple partition image - all disk (not resizable) we use for our laptops and it’s working…
For clarification, did the non-re sizable image deploy to the troublesome HDD?
-
@Wayne-Workman We already had an image with multiple partition image - all disk (not resizable) in our fog and yes this image has worked on the new HDD
-
@Pascal-Gazaille Thanks a lot for all the information and testing you did so far. I need to sit down and read through the whole thread again when I have a bit more time over the weekend.
Seeing the title of the post I am wondering if this has turned out a completely different issue, right? It’s the disk, right? Do you see the exact same issue if you put this “problem HDD” into a different computer? As well are you able to successfully deploy to a “good HDD” in the Optiplex 3020? You see I am trying to circle the issue…
-
Bumping this
-
@Pascal-Gazaille Ok here is what I ran into re-reading it all and trying things out a bit:
- In one of your ealier posts it says
Disklabel type: gptandPowerPC PReP bootwhile we seeDisklabel type: dosandHPFS/NTFS/exFAT. While I don’t say this is a problem I am still wondering when and how this got changed along the way. The two partition schemes are quite different from each other and will cause different behavior in FOG as well. - I guess we need the image information as well to get an idea if and where things go wrong. Please post the output of
ls -al /images/<image-name>,cat /images/<image-name>/d1.fixed_size_partitions,cat /images/<image-name>/d1.minimum.partitionsandcat /images/<image-name>/d1.partitionshere in the forum!
- In one of your ealier posts it says
-
@Sebastian-Roth Hi, I’ trying your commands and none of them works…I’m I missing something? I started the computer in “deploy - debug” like all other debug.
-
@Pascal-Gazaille Sorry, should have said that those commands I meant you to run on the FOG server! Note that you need to replace the
<image-name>part with your actual image name! -
cat /images/<image-name>/d1.fixed_size_partitions= 1
cat /images/<image-name>/d1.minimum.partitions= not working
cat /images/<image-name>/d1.partitions= not working -
@Pascal-Gazaille Well then please run
cat /images/TNI64/d1.original.fstypesandcat /images/TNI64/d1.original.partitions -
-
@Pascal-Gazaille Ok, thanks. Please give me a bit more time to try and recreate this on my test machine…
-
@Sebastian-Roth the problem comes with image single disk -resizable…
-
@Pascal-Gazaille Sorry for the delays and that we still don’t have a solution to this. I just have too many things on my list right now. Trying hard to get it all done.
Re-reading all the posts I am still not absolutely sure if I got it all right. Please help me.- The latest pictures you posted are showing an image you captured with an older version of FOG, correct?
- If you do a new capture (be it resizable or non-resizable) it all works fine, correct?
- It’s just that old image you need to be able to deploy to the new disks properly…?
- What about the different HDs? Does the image still deploy properly (windows running afterwards) on one of the disks but not on the other?
I took all the information you gave and put together a test image and test VM. Deploy went through without an issue and my partition table looks like there shouldn’t be any trouble. But as I don’t have exactly your data (rec.img.000, sys.img.000) my tests are only of limited value. But still I wonder what else could go wrong.
Please do a debug deploy on the problem disk again. After it finishes you get back to the shell. Run
fdisk -l /dev/sdaand post the picture here.–> Read this first: <–
Just right now I had an idea. Call me dumb but I really think it’s possible that it works on the “older” disks because they already have the proper MBR deployed on them. On the new disks the MBR is empty and as we see in the image listing there is no d1.mbr… Possibly it’s that simple. Wouldn’t be hard to fix, really. Get one of the PCs that you can deploy that image to properly. Do a debug upload and run the following commands (where x.x.x.x is your FOG server IP):mkdir /nfs mount -t nfs -o nolock x.x.x.x:/images/dev /nfs dd if=/dev/sda of=/nfs/d1.mbr bs=512 count=2048 umount /nfs haltNow you need to move that MBR file into place (on the FOG server console run
mv /images/dev/d1.mbr /images/TNI64/d1.mbr) and try deploying to a new disk again… -
@Sebastian-Roth Hey, I’ve tried to copy the d1.mbr files but this didn’t work, don’t know if there where a right issue. Seing that my MBR files was not there, I’ve tried to reupload my 2 images that had the problem and now everything seems ok.
Don’t know why the d1.mbr file disapeared from these 2 images on the first place.
Thanks alot for all the debug, you guys are a great team!
-
@Pascal-Gazaille Does this mean all the symptoms of not being able to deploy to the new disks disappeared?? Scratching my head… Will mark this solved for now anyway.
