NEW iMac problems

[Sebastian Roth]

@Abuelika This is strange. I seems to properly do the Restoring Patition Tables (GPT) (no error) but then does not find those restored partition tables on disk why trying to deploy an image.

For this host, can you add to the Host Kernel Args: isdebug=yes ismajordebug=1

Then run a deploy, and capture pictures where it says: Current partition table: ...

[Abuelika]

Hi @Sebastian-Roth ,

Same error!

[Sebastian Roth]

@Abuelika Are you surely added the parameters? Ahh, sorry I overlooked that you are using the USB booting method as we still have the iPXE boot issue (hope we can work on this as well!)…

Please rebuild the USB key according to George’s manual and add isdebug=yes ismajordebug=1 in the grub.conf kernel command line.

[Abuelika]

@sebastian-roth said in NEW iMac problems:

isdebug=yes ismajordebug=1

I configured the USB with “isdebug = yes ismajordebug = 1” and it enters debug mode

[Abuelika]

@sebastian-roth

Log DEBUG MODE

[Sebastian Roth]

@Abuelika Sorry, forgot to ask if you could also post the contents of the d1.partitions and upload d1.mbr file? I’ll try to replicate the issue then.

[Abuelika]

Hi @sebastian-roth ,

Attached link to Download d1.mbr .

I attached the content of d1.partitions

root@fogserver:/images/MASTERMACOS2017# vi d1.partitions
label: gpt
label-id: EB5F756F-5E64-4990-8B9C-5F2826AFDEC2
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 234441614

/dev/sda1 : start=          40, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=F803B6B4-FAF1-4700-814F-4CC7B6AA693D, name="EFI System Partition"
/dev/sda2 : start=      409640, size=   232762432, type=48465300-0000-11AA-AA11-00306543ECAC, uuid=2CA043B5-1BA4-4052-AC59-AA30F67E556D
/dev/sda3 : start=   233172072, size=     1269536, type=426F6F74-0000-11AA-AA11-00306543ECAC, uuid=989E4FD8-2721-4B58-A6B4-24E3334F1165, attrs="GUID:49"

[Sebastian Roth]

@Abuelika Sorry for taking a while to get onto this. Too many other things going on at the moment. I tried your d1.mbr now and it worked like a charm. Then I looked at the pictures you posted more closely again and I am sure I see what’s wrong here. See the message printed in red:

GPT PMBR size mismatch (234441647 != 61279343) will be corrected by w(rite).

When I first saw this I thought FOG is doing something wrong but then I noticed the second number being smaller than the first and so I tried your d1.mbr on a smaller destination disk and that failed with the exact same error (just different number). You cannot deploy a non-resizable image to a smaller destination disk!

So what you have to do is create a new image in the FOG web UI, e.g. name it MASTERMACOS2017_RESIZABLE and set Image Type to “Single Disk - Resizable”. Do not delete your other image yet. Keep this as a backup for now just in case something is going wrong with the resizable image. Now set your master Mac machine to use this newly created MASTERMACOS2017_RESIZABLE image and schedule an upload task. Let it do it’s job. Then configure the machine you wanted to deploy to use the new resizable image as well and do the deploy. You might want to keep the debug kernel options for now just in case it runs into an error again.

Please let us know how it went and post a picture in case you run into an issue.

[Abuelika]

Hi @sebastian-roth when I try to capture the image, the following error appears:

[Sebastian Roth]

@Abuelika Oh … why the he** do I always forget about we are not able to resize HFS+ filesystems. Don’t know why! Sorry for that. Just forget what I said!

So this leaves you to maybe try shrinking the Mac OS X system by hand I am afraid. Search the web on how to do this. I am not sure this can be done at all but I think I’ve read about it somewhere.

Would be an awesome feature to add to FOG to have resize work for Mac OS X as well. But seems like there are no reliable tools out there to do this as of now.

[Abuelika]

Hi @sebastian-roth

I have been reviewing, and the source is a 120Gb disk and the destination is 250Gb.

It is rare that the problem is of disk size, when the source is smaller than the destination.

tnx!

[Tom Elliott]

Is it possible this is related to the 32 bit issue in HFS as it was in the other thread @Sebastian-Roth?

[Sebastian Roth]

@Tom-Elliott Don’t think so. But what do I know…?

@Abuelika Please do me a favour and boot up both clients in debug task (capture or deploy, doesn’t matter). When you get to the shell run fdisk -l /dev/sda (that’s for the source machine and fdisk -l /dev/nvme0n1… Post pictures here.

Ahhhhhha, now that I am writing this I have an idea. Possibly we are not able to move from a SATA disk (/dev/sda) to one of these new disks (/dev/nvme0n1). Not sure if I can test this.

Give this a try: Make a backup copy of the partition layout file and then edit those files which you find in /images/MASTERMACOS2017/d1.partitions. Make it look like this:

label: gpt
label-id: EB5F756F-5E64-4990-8B9C-5F2826AFDEC2
device: /dev/nvme0n1
unit: sectors
first-lba: 34
last-lba: 234441614

/dev/nvme0n1p1 : start=          40, size=      409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=F803B6B4-FAF1-4700-814F-4CC7B6AA693D, name="EFI System Partition"
/dev/nvme0n1p2 : start=      409640, size=   232762432, type=48465300-0000-11AA-AA11-00306543ECAC, uuid=2CA043B5-1BA4-4052-AC59-AA30F67E556D
/dev/nvme0n1p3 : start=   233172072, size=     1269536, type=426F6F74-0000-11AA-AA11-00306543ECAC, uuid=989E4FD8-2721-4B58-A6B4-24E3334F1165, attrs="GUID:49"

Save the file and try deploying the MASTERMACOS2017 image again.

[Abuelika]

Hi @sebastian-roth ,

Source:

Destination:

I have modified “/images/MASTERMACOS2017/d1.partitions” with the information provided and the error is the same.

[Tom Elliott]

@abuelika This appears to be a 4k disk then? I mean, the sector size is correct for 512, but not for 4096.

E.G.:

234441647 * 512 = 120034123264 (about 120 GB)
234441647 * 4096 = 960272986112 (about 960 GB)

Where:
61279344 * 512 = 31375024128 (about 32 GB)
61279344 * 4096 = 251000193024 (about 250 GB)

@Sebastian-Roth I don’t know how to handle this anymore. We have to use 512 for blockdev elements. Getting the block size is actually quite easy, though I’m still sure it’s working properly RC’s - but if this is 1.4.4 those changes should be present as well.

[Tom Elliott]

I imagine, however, resizable or not, this is a problem as the way the disk is presented on one system (512 byte sector sizes) to another system (4096 byte sector sizes).

I know there’s a way to adjust a disks byte sector size. Something like:

blockdev --setbsz 512 /dev/nvme0n1

[Tom Elliott]

Maybe we can use information from this posting to help us out? It’s coming from Rod Smith directly and he would probably be the guy who knows his stuff considering he wrote gpt disk utilities.

[Sebastian Roth]

Ahh, now I see. Give me a bit of time with this and I am sure I’ll comes up with a solution to this. Though it might sound like a good idea to set the NVME drive to 512 I don’t think this is wise to do. I have a bit of free time tomorrow and will dive into this more deeply…

[Tom Elliott]

@sebastian-roth I totally understand. I tried in the past and failed miserably, so I don’t mean to put more on your shoulders, I just don’t know how to best approach. In particular, fixing this issue for resize should be simple, but how can we fix for non-resizable images?

[Abuelika]

In the first instance

Many thanks to @sebastian-roth and @Tom-Elliott for the work you are doing.

The fastest solution I have found is the following:

My Solution:

• Mac with SATA ( Sector size: 512 bytes ) hard disk cloned with “FOG”, we created a “TimeMachine” and restored in iMAC computer with M2 disks ( Sector size: 4096 bytes ) .

• We create an image with FOG Multiple Partition Image - Single Disk (Not Resizable)

• Perform a capture of the equipment with disk M2 with “FOG”

• We deploy the image to all iMac computers with M2 hard disks

Work fine!