Deploy problem with Optiplex 3020

[Pascal Gazaille]

@Wayne-Workman

[Wayne Workman]

@Pascal-Gazaille @Sebastian-Roth

It’s got a firmware version, CC43! I Wonder if it can be updated?!?

[Pascal Gazaille]

@Wayne-Workman I’ve searched everywhere but did not find any firmware update or downgrade…

[Wayne Workman]

@Pascal-Gazaille Lets wait and see what Sebastian says. He’s a pro with HDDs.

[Pascal Gazaille]

@Wayne-Workman Tried imaging the hdd with a multiple partition image - all disk (not resizable) we use for our laptops and it’s working…

[Wayne Workman]

@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!

[Wayne Workman]

@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?

[Pascal Gazaille]

@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

[Sebastian Roth]

@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…

[Wayne Workman]

Bumping this

[Sebastian Roth]

@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: gpt and PowerPC PReP boot while we see Disklabel type: dos and HPFS/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.partitions and cat /images/<image-name>/d1.partitions here in the forum!

[Pascal Gazaille]

@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.

[Sebastian Roth]

@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!

[Pascal Gazaille]

@Sebastian-Roth

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

[Sebastian Roth]

@Pascal-Gazaille Well then please run cat /images/TNI64/d1.original.fstypes and cat /images/TNI64/d1.original.partitions

[Pascal Gazaille]

@Sebastian-Roth

[Sebastian Roth]

@Pascal-Gazaille Ok, thanks. Please give me a bit more time to try and recreate this on my test machine…

[Pascal Gazaille]

@Sebastian-Roth the problem comes with image single disk -resizable…

[Sebastian Roth]

@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/sda and 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
halt

Now 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…

[Pascal Gazaille]

@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!