Do's and Don'ts of installing multiple OSes on MacBook Pro Late 2011

I have successfully installed macOS High Sierra, Windows 10, and Ubuntu 20.04 on MacBook Pro Late 2011, and there were some challenges worth noting down.

Formatting the disk

When booting into recovery mode to format the disk, the installation USB used must be of an OS X (Mavericks, for my case), not a macOS (newer version). I once booted into recovery mode using macOS High Sierra installation USB to format the disk with GUID Partition Map scheme, and then I was unabled to install Windows 10 through VirtualBox. I got the error message "The selected disk is of the GPT partition style." when selecting a partition to install Windows on. 

This is because I tried to install Windows using legacy mode and then Windows required a MBR disk, but it was GPT disk. However, when I booted into recovery mode using OS X Mavericks installation USB instead to format the disk with GPT Partition Table cheme, the error message was gone. Why? because the disk was hybrid MBR, not pure GPT, and so Mac OS saw it as GPT but Windows saw it as MBR. As Windows did not support EFI mode at that time, Apple used hybrid MBR to allow users to install Windows on its machines that used EFI boot.

Partitioning the disk

The disk must be partitioned as needed before installing any OSes on it or one of the OSes won't boot after the partition is resized or a new partition is created. 

At first, I didn't do that. After installing macOS High Sierra and Windows 10, I created another partition from the Windows 10 partition and then Windows stopped booting. It's because of the OS's boot entry is missing from the MBR, and I don't know why but this post claimed to fix that using a third-party tool. Unfortunately, I've never succeeded.

Ordering the partitions

In my case, I have 5 primary partitions:

1. EFI system partition
2. macOS
3. Windows
4. DATA
5. Linux

The first partition was hidden and created automatically by DiskUtility so I shouldn't have mentioned it but this is to show that the DATA partition must be the fourth partition so that it would appear in File Explorer (as I wanted) when booting into Windows. If it was the last one, it wouldn't show up. This is because the disk was MBR to Windows and so it could have only four primary partitions. Windows recognized only the first four partitions and ignored the rest so Linux partition was treated as unallocated space (this can be checked in Disk Management).

In DiskUtility (of OS X Mavericks), the first partition is graphically on top. Since the EFI system partition is not visible in DiskUtility, the macOS partition is on top instead.

Installing Windows using BIOS legacy mode without CD-ROM

Since my CD-ROM drive stopped working a long time ago, I couldn't install Windows with Boot Camp Assistant because my machine, by default, only looked for Windows installation files from the CD-ROM drive but it couldn't find it. 

When I forced the machine to look for the Windows installation files from a USB drive (by holding down the Option key while it's starting), it worked but Windows was installed using EFI mode instead, and the problem with EFI mode is the external monitor is not detected on Windows. This problem only happens on my Mac model, not the newer ones.

Everything worked fine when installing Windows using BIOS legacy mode, and the workaround was installing it through VirtualBox. I noted it down here.

How to clone Ubuntu OS partition?

I'm using Macbook Pro 13-inch Late 2011 running Ubuntu 20.04. I used the built-in application called Disks to backup the Ubuntu system partition into a disk image (*.img file) and then restore the disk image back to the partition.

IMPORTANT 

• When backing up a system partition, the EFI system partition should also be backed up if it exists (using either Disks application or cp command)
• The backed up or source partition must be smaller than or equal to the destination partition
• The size of the disk image (*.img file) equals the size of the (backed up) source partition even if the partition has free space. The source partition should be resized as small as possible so that the resulting disk image is acceptably small.

To Backup

Backing up Ubuntu partition:

• Boot into Ubuntu Live (on USB) and chose Try Ubuntu

• Open Disks application from the menu (press Windows key and type Disks)

• Select the partition to backup 

• (Optional) Click on the settings icon for more options and select Resize

• Click on the settings icon for more options then select Create Partition Image...

• Make sure the file name and location are correct. The partition for storing the disk image must be mounted or it'll fail with a message like there is not enough space or something else confusing.

Backing up EFI system partition:

The EFI system partition is where the Ubuntu bootloader locates in because I manually chose the partition for the bootloader while installing Ubuntu (It's a must to install Ubuntu using EFI mode).

I used the method above to clone (backup) this partition, and also manually copied its content using cp command. Of course, using cp command is simpler and works just fine. The partition has only one directory named EFI.

> sudo mkdir /mnt/sda1
> sudo mount -o loop /dev/sda1 /mnt/sda1
> sudo cp -rf /mnt/sda1/EFI /media/myusb/ubuntu-efi/

To Restore

Restoring Ubuntu partition:

• Boot into Ubuntu Live (on USB) and click Try Ubuntu

• Open Disks application from the menu

• Select the (destination) partition for running Ubuntu 

• Click on the settings icon for more options and select Restore Partition Image...

• Browse to the (source) partition that the disk image (*.img file) is stored on

• Select the disk image file and click Start Restoring

Restoring EFI system partition:

I opened Terminal and used the cp command to copy it back from the USB drive to the EFI system partition (in my case, /dev/sda1). 

> sudo mkdir /mnt/sda1     

> sudo mount -o loop /dev/sda1 /mnt/sda1    

> sudo cp -rf /media/myusb/ubuntu-efi/EFI/ubuntu /mnt/sda1/EFI/

> sudo cp -rf /media/myusb/ubuntu-efi/EFI/BOOT /mnt/sda1/EFI/

Successfully Tested Scenarios

Scenario 1 

1. Create a virtual machine and install Ubuntu with VirtualBox, enabling EFI mode
- Partition 1: 500 MB (EFI system)
- Partition 2: 50 GB (FAT32 - empty)
- Partition 3: 200 GB (NTFS - empty)
- Partition 4: 40 GB (EXT4 - Ubuntu)
2. Reboot into Ubuntu Live through a virtual CD-ROM attached with the Ubuntu installation ISO file and choose Try Ubuntu
3. Open Disks application from the menu and use it to backup Partition 4 (Ubuntu system partition) to a disk image (*.img file) stored on Partition 3.
4. Restore the disk image file to Partition 2
5. Format and erase Partition 4
6. Optional: backup Partition 1 to a disk image stored on Partition 3
7. Close the virtual machine and start it again

Scenario 2

1. Boot into Recovery mode on MacBook Pro Late 2011
2. Create the following partitions:
- Partition 1: 70 GB (Mac OS Extended)
- Partition 2: 100 GB (exFAT)
- Partition 3: 90 GB (FAT 32)
- Partition 4: 200 GB (exFAT)
3. Install macOS High Sierra on Partition 1 
4. Install Ubuntu 20.04 on Partition 3 (formatted as ext4)
5. Boot into Ubuntu Live USB and choose Try Ubuntu
6. Open Disks application from the menu
7. Format Partition 4 as NTFS
8. Optional: resize Partition 3 to 20 GB (leaving 70 GB of free space)
9. Backup Partition 3 (Ubuntu) as a disk image (*.img file) and store it on Partition 4 
10. Format and erase Partition 3 (this can also be done in macOS)
11. Restore the disk image from Partition 4 to Partition 3
12. Reboot the machine

Setting environment variables on Ubuntu

Example

export JAVA_HOME=/usr/local/jdk-15.0.2

export PATH="$PATH:$JAVA_HOME/bin"

Without the export command, the variables are just shell variables; it means they aren't recognized by the sub processes or programs that start from the shell. 

Login shell vs non-login shell

A shell in Unix is a program that provides command line interface for OS and user interaction. The Terminal application is just an emulator or GUI for a shell.

Login shell - ssh is an example.

Non-login shell - the Terminal application by default starts a non-login shell but inherits the user environment variablbes loaded from the graphical login shell.

Session-wide environment variables

It affects only specific user.

The ~/.profile file

Each user has its own .profile file. It gets executed by the DisplayManager when the desktop session loads as well as by the login shell when one logs in from the textual console.

The ~/.profile file is not automatically executed by just restarting the Terminal application because it's not a login shell. For the file modification to take effect, logout the user account and login again.

System-wide environment variables

It affects the system as a whole (rather than just a specific user). 

The /etc/environment file

The downside is variables do not expand. In the example below, the PATH variable would end up containing only "/bin" because $PATH and $JAVA_HOME don't get replaced with their values.

export JAVA_HOME=/usr/local/jdk-15.0.2

export PATH="$PATH:$JAVA_HOME/bin"

The /etc/profile & /etc/profile.d/*.sh files

The /etc/profile is often used for setting system-wide environment variables but it is a configuration file so it's inappropriate to edit that file. The /etc/profile.d directory should be used instead. It (and any sh files inside) get executed whenever a bash login shell is entered (e.g. when logging in from the console or over ssh), as well as by the DisplayManager when the desktop session loads. 

For example, create the /etc/profile.d/myvars.sh file and set the variables as followings:

export JAVA_HOME=/usr/local/jdk-15.0.2

export PATH="$PATH:$JAVA_HOME/bin"

WiFi is not working on a fresh-install Ubuntu 20.04

I'm using Macbook Pro Late 2011 to install Ubuntu 20.04 on it. WiFi was working fine when trying Ubuntu from Live USB, but it wasn't after the installation. I couldn't find the WiFi adapter in Network settings.

First, when I opened Software & Updates > Additional Drivers, I saw:

Broadcom Inc. and subsidaries: BCM4331 802. 11a/b/g/n (AirPort Extreme)

The option Do not use the device  below it was checked and then I check another option to use the device and clicked Apply Changes but failed.

Second, I mounted the Ubuntu installation ISO file as a CD-ROM (using commands in Terminal) then opened Software & Updates again and selected Ubuntu Software tab. Under Installable from CD-ROM/DVD label, I checked Cdrom with Ubuntu 20.04 then repeat the first step but still no luck.

The solution below (that I copied from here) worked. 

1. Extract the Ubuntu installation ISO file (ubuntu-20.04.*.iso) to ~/Downloads folder then open Terminal and run:

> sudo chmod -R 777 ~/Downloads/ubuntu-20.04.*

2. Find the broadcom firmware on another machine:

- Download broadcom-wl-6.30.163.46.tar.bz2 (or later) from here or my backup.

- Extract it to ~/Downloads folder

3. Run the following commands in Terminal:

> cd ubuntu-20.04.*/

> sudo dpkg -i ./pool/main/b/b43-fwcutter/b43-fwcutter_019-4_amd64.deb

> cd ~/Downloads/broadcom-wl-6.30.163.46

> sudo b43-fwcutter -w /lib/firmware broadcom-wl-6.30.163.46.wl_apsta.o

 

> sync

> sudo modprobe -r b43 

> sudo modprobe b43 

4. Check the Network settings again and the WiFI icon should appear.

Testing

sudo asr restore --source /dev/disk1 --toSnapshot 9942DBA2-5C5C-4A6C-B099-79AE2C7B011D --target /dev/disk3 --erase
	Validating target...done
	Validating source...done
	Erase contents of /dev/disk3 ()? [ny]: y
	Replicating ....10....20....30....40....50....60....70....80....90....100
	Replicating ....10....20....30....40....50....60....70....80....90....100
	Restored target device is /dev/disk3s2.
Restore completed successfully.

Cloning a macOS Big Sur partition to a USB Drive (bootable)

I'm using MacBook Air 2013 running macOS Big Sur. This is how I made a bootable backup of my macOS partition to another partition on my USB drive. Apple Software Restore (asr command line utility) allows a user to restore the content of a (system) volume (disk/partition) to another volume or disk image. This can be thought of cloning a partition.

Step 1

My USB drive has 4 partitions as shown in the image below. The internal system volume (source), macOS Big Sur, is going to be restored to NAK-macOSBigSur partition (target) on the USB drive. The partition is formatted as APFS with GUID Partition Map scheme.

NOTE: This post is about restoring from a snapshot of the system volume (which is explained in the next steps). If there is no snapshot and so it won't be specified in the command, the size of target volume (or disk image) must be greater than the size of the source system volume (not just the size of the system volume's content) or the restore will fail. Just make sure the target volume's size is bigger before the restore and then shrink it later.

Step 2

Note down the identifiers of the source system volume, macOS Big Sur, and the target USB's partition. They can be viewed in DiskUtility or from Terminal using this command:

> diskutil apfs list

APFS Containers (2 found)

|

+-- Container disk1 0A4D95E1-BDA4-4BEF-B349-D34D0B1EAD0B

|   ====================================================

|   APFS Container Reference:     disk1

|   Size (Capacity Ceiling):      89999998976 B (90.0 GB)

|   Capacity In Use By Volumes:   65204166656 B (65.2 GB) (72.4% used)

|   Capacity Not Allocated:       24795832320 B (24.8 GB) (27.6% free)

|   |

|   +-< Physical Store disk0s2 E0056EF5-6FCD-4D45-AB00-C7D273999AE5

|   |   -----------------------------------------------------------

|   |   APFS Physical Store Disk:   disk0s2

|   |   Size:                       89999998976 B (90.0 GB)

|   |

|   +-> Volume disk1s1 23C04205-6361-398C-989F-10195CDC66BA

|   |   ---------------------------------------------------

|   |   APFS Volume Disk (Role):   disk1s1 (Data)

|   |   Name:                      macOS Big Sur - Data (Case-insensitive)

|   |   Mount Point:               /System/Volumes/Data

|   |   Capacity Consumed:         47762022400 B (47.8 GB)

|   |   Sealed:                    No

|   |   FileVault:                 No

|   |

|   +-> Volume disk1s2 0300C5AA-7F28-4FB1-9B21-F128B56BD685

|   |   ---------------------------------------------------

|   |   APFS Volume Disk (Role):   disk1s2 (Preboot)

|   |   Name:                      Preboot (Case-insensitive)

|   |   Mount Point:               /System/Volumes/Preboot

|   |   Capacity Consumed:         284585984 B (284.6 MB)

|   |   Sealed:                    No

|   |   FileVault:                 No

|   |

|   +-> Volume disk1s3 FF1FA02B-5C9E-41E9-8193-4676E5DC57D3

|   |   ---------------------------------------------------

|   |   APFS Volume Disk (Role):   disk1s3 (Recovery)

|   |   Name:                      Recovery (Case-insensitive)

|   |   Mount Point:               Not Mounted

|   |   Capacity Consumed:         623341568 B (623.3 MB)

|   |   Sealed:                    No

|   |   FileVault:                 No

|   |

|   +-> Volume disk1s4 A0B8A157-01F7-4563-9C6A-CC869FE11FB5

|   |   ---------------------------------------------------

|   |   APFS Volume Disk (Role):   disk1s4 (VM)

|   |   Name:                      VM (Case-insensitive)

|   |   Mount Point:               /System/Volumes/VM

|   |   Capacity Consumed:         1074819072 B (1.1 GB)

|   |   Sealed:                    No

|   |   FileVault:                 No

|   |

|   +-> Volume disk1s5 8C1ADEAE-7361-415F-AEBF-C64BD1C00146

|       ---------------------------------------------------

|       APFS Volume Disk (Role):   disk1s5 (System)

|       Name:                      macOS Big Sur (Case-insensitive)

|       Mount Point:               Not Mounted

|       Capacity Consumed:         15330869248 B (15.3 GB)

|       Sealed:                    Broken

|       FileVault:                 No

|       |

|       Snapshot:                  9942DBA2-5C5C-4A6C-B099-79AE2C7B011D

|       Snapshot Disk:             disk1s5s1

|       Snapshot Mount Point:      /

|       Snapshot Sealed:           Yes

|

+-- Container disk3 FD345835-64FB-4924-962B-FB26C2B8F980

    ====================================================

    APFS Container Reference:     disk3

    Size (Capacity Ceiling):      76559953920 B (76.6 GB)

    Capacity In Use By Volumes:   122478592 B (122.5 MB) (0.2% used)

    Capacity Not Allocated:       76437475328 B (76.4 GB) (99.8% free)

    |

    +-< Physical Store disk4s5 17F2CE1B-2E10-411D-8ECF-0435F949DFAE

    |   -----------------------------------------------------------

    |   APFS Physical Store Disk:   disk4s5

    |   Size:                       76559953920 B (76.6 GB)

    |

    +-> Volume disk3s1 714E92A0-4F22-47A0-A72C-449E389BFC23

        ---------------------------------------------------

        APFS Volume Disk (Role):   disk3s1 (No specific role)

        Name:                      NAK-macOSBigSur (Case-insensitive)

        Mount Point:               /Volumes/NAK-macOSBigSur

        Capacity Consumed:         827392 B (827.4 KB)

        Sealed:                    No

        FileVault:                 No

Step  3

Run Apple Software Restore command as following:

> sudo asr restore --source /dev/disk1 --toSnapshot 9942DBA2-5C5C-4A6C-B099-79AE2C7B011D --target /dev/disk5 --erase --buffersize 32m  

Password:

Validating target...done

Validating source...done

Erase contents of /dev/disk5 ()? [ny]: y

Replicating ....10....20....30....40....50....60....70....80....90....100

Replicating ....10....20....30....40....50....60....70....80....90....100

Restored target device is /dev/disk5s2.

Restore completed successfully.

Apple does not allow restoring a system volume when its seal is broken and so is mine, then specifying the --snapshot option is a workaround to bypass the restriction. The snapshot was created by macOS Big Sur automatically when it updated itself and so it's the OS update snapshot.

The seal is part of Signed System Volume (SSV) technology, which is used to protect a system content on a signed system volume. With SSV, the kernel rejects any data or code (at runtime) that does not have a valid cryptographic signature from Apple to protect the integrity of the system content. I'm not sure if the seal is broken because I once booted into Recovery mode and used DiskUtility to restore the system volume to a USB drive. But, some people on the internet said the seal was broken even for a fresh install of Big Sur. 

/dev/disk1 is the identifier of the (source) system volume's container. The identifier of the system volume can also be used, /dev/disk1s1, in this case.

/dev/disk5 is the identifier of the target USB partition's container. The identifier of the partition can also be used, /dev/disk3s1, in this case.

--buffersize 32m option (32m means 32 Megabytes) makes the asr command run faster than the default buffer size. This is ideal for block-copies between partitions.  The size should be changed and experimented for an optimal value.

And the image below shows how my USB drive's partition changed after restore completed.

macOS Sierra

The asr restore command might throw the error below.

Source volume is read-write and cannot be unmounted, so it can't be block copied.

To solve that, the asr restore command must be run in Mac's Recovery mode (restart the machine and hold Command + R).

macOS High Sierra

The asr restore command always fail at the end. Many people reported the same so I downgraded to macOS Sierra.

Errors restoring or creating a disk image from a volume using DiskUtility

I'm using Macbook Air running macOS Big Sur, and I was having troubles performing disk restore using DiskUtility.

ERROR 1: I was unable to restore a volume to a new blank disk image I created. 

There could be a couple reasons such as the size of the blank disk image is smaller than the size of the source volume or there was no partition in the disk image (must be manually created at least 1 partition). But, even if I did follow all these requirements, the restore still failed.

ERROR 2: When trying to create a new disk image from a device or folder, I got the error message like "...operation not permitted". 

The function to create a new image from a device/folder is useful because the size of the new disk image will automatically be set to the size of the source device/folder, and the contents of the device/folder are restored (cloned) to the new disk image. 

SOLUTION

The errors occured because DiskUtility did not have enough privileges to perform those operations. After assigning a Full Disk Access permission to DiskUtility, I could restore a volume to a disk image (and vice versa) without any problems.

How to assign Full Disk Access permission to DiskUtility?

Open System Preferences > Security & Privacy > Privacy then select Full Disk Access from the listbox on the left and click on the Plus sign to add DiskUtility to the right listbox and make sure it's checked.