Short answer
No, it is not possible (to my knowledge, at this time) to boot into one of the other operating systems from a disk image stored on another partition.
What I have done in the past is make a third partition that I use to share files between the two. I make both boot partitions large enough to store the most important things and then a third that I can store other files on whether they be Windows files or Mac files. It isn't a perfect solution but at least that way if you want more space for Mac stuff then you can format that partition in HFS+. If you want more space for Windows stuff you can format that partition in NTFS or exFAT or something.
If you do decide to do something like that then look into the proper way of doing so before you try. It isn't an easy process but it is at least easier than trying to do what you suggested. You can find some instructions on Ubuntu's website that help explain how to set up a triple boot system. Follow those instructions and just skip the step where you install Ubuntu. Instead, leave the last partition empty for storing stuff.
IMPORTANT: Don't forget to backup everything before trying any sort of partitioning on your main drive. You were warned.
Another option is to install a second drive if possible. I have an older MacBook Pro and I took the DVD drive out and put a second drive in its place. Thats the absolute easiest thing to do if you can.
As to your question about LVM. CoreStorage would allow you to set up partitions that can be resized later and the like, but Windows cannot boot from a CoreStorage partition. CoreStorage is strictly a macOS technology that no other OS recognizes. But that is a longer story for another time.
Longer answer
Your Mac's firmware that is in charge of finding and mounting a bootable partition does not have that ability. Maybe, just maybe in the Linux world that is possible but I'm not sure. But I know a Mac's firmware doesn't have that capability because that is not something 99.9999% of people would want to do.
When your Mac turns on the firmware (the baked in software that is stored on a chip on the motherboard) is in charge of finding a partition on your hard drive with an operating system that can boot. When booting to macOS the firmware (EFI on a Mac) finds a special partition on your hard drive called EFI (yes, the same name as the firmware), mounts that partition, and lets the software (called a boot loader) take over the boot process. The EFI is very small and has very limited capabilities since it has to live in a small chip on the motherboard. The boot loader can do more because the EFI partition on your hard drive is large enough to store a bigger program.
The boot loader then mounts the other drives on your disk and finds the partitions with macOS and depending on which drive you selected in the System Preferences it will boot macOS from the partition you chose (you can have many different partitions on the same hard drive with macOS installed on any of them).
When booting to Windows on a Mac your EFI does things a little differently. As far as I understand the boot loader on the EFI partition isn't used to boot Windows. Instead, the Windows installer puts a little chunk of code at the very beginning of you drive in the tiny space called the MBR. That space is measured in bytes. Not even kilobytes. Just bytes. It is absolutely tiny. So you can't do much with the boot loader stored there. All it does is find the Windows partition and direct the CPU there to finish booting. There is no space on the Windows boot loader to do much of anything else at all. Especially not to mount a drive, find the correct disk image on that drive and then mount and boot from that disk image. It wouldn't come close to fitting in the MBR.
Going back to the EFI partition there may be a chance of fitting enough software on that partition to do all the work necessary to boot from a disk image but again I'm not sure its possible. I'm not familiar enough with the boot process to know if it is. All I know for sure is that the current EFI and boot loader do not support anything like you are asking for.
Making a boot loader that does what you are looking for may be possible but it would require a lot of work and a strong understanding of how the whole boot process works.
The point is it would be a much better use of your time figuring out a better way to partition your hard drive then to try and mount one using a disk image.
I tried to explain things as best as I understand them but I may be wrong. Someone please correct me if I am.
Apple does not provide a way to do what you want to do. There are third party tools that can move a partition, but last time I checked, they will not work with APFS container partitions.
Partitions are stored on a drive contiguously. This means you can not just add any free space to a partition. The free space must exist directly below the partition. Let my show you an example similar to your situation.
First is the output from the command diskutil list disk1
. The drive below is a a sparse disk image. I created the image to help illustrate my answer. The image is partitioned fairly close to your disk0
.
Marlin:driveinfo davidanderson$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +500.3 GB disk1
1: EFI EFI 314.6 MB disk1s1
2: Apple_APFS Container disk3 400.0 GB disk1s2
3: Apple_APFS Container disk4 100.0 GB disk1s3
Here is the output from sudo gpt -r show /dev/disk1
. This command shows the values store in the GUID Partition Table (GPT). In this case, the units are blocks of 512 bytes.
Marlin:driveinfo davidanderson$ gpt -r show /dev/disk1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 614448 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
614488 781250000 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
781864488 195283952 3 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
977148440 5
977148445 32 Sec GPT table
977148477 1 Sec GPT header
Since disk0
is your boot drive, you can not use the gpt
command without a sudo
and System Integrity Protection (SIP) disabled. An alternative to the gpt
command is a third party tool called driveinfo. If you use this tool, you will not need to disable SIP or use a sudo
. Below is the output from this command. Here, the units are in bytes.
Marlin:driveinfo davidanderson$ ./driveinfo -rd disk1
Code Size Type Identifier Mounted Name
---- --------------- -------------- ---------- ------- ----
512 PMBR
512 Pri GPT header
16,384 Pri GPT table
3,072 Free Space
314,597,376 EFI disk1s1 No EFI
400,000,000,000 Apple_APFS disk1s2 No
99,985,383,424 Apple_APFS disk1s3 No
2,560 Free Space
16,384 Sec GPT table
512 Sec GPT header
Next, I will enter the command below to create 50 GB of free space. This is similar to what you did.
sudo diskutil apfs resizeContainer disk0s2 350G
The results are shown below.
Marlin:driveinfo davidanderson$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +500.3 GB disk1
1: EFI EFI 314.6 MB disk1s1
2: Apple_APFS Container disk3 350.0 GB disk1s2
3: Apple_APFS Container disk4 100.0 GB disk1s3
Marlin:driveinfo davidanderson$ sudo gpt -r show disk1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 614448 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
614488 683593744 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
684208232 97656256
781864488 195283952 3 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
977148440 5
977148445 32 Sec GPT table
977148477 1 Sec GPT header
Marlin:driveinfo davidanderson$ ./driveinfo -rd disk1
Code Size Type Identifier Mounted Name
---- --------------- -------------- ---------- ------- ----
512 PMBR
512 Pri GPT header
16,384 Pri GPT table
3,072 Free Space
314,597,376 EFI disk1s1 No EFI
349,999,996,928 Apple_APFS disk1s2 No
50,000,003,072 Free Space
99,985,383,424 Apple_APFS disk1s3 No
2,560 Free Space
16,384 Sec GPT table
512 Sec GPT header
The 50 GB of free space was created immediately after disk1s2
. In order to add this free space to disk1s3
, the space would have to occur immediately after disk1s3
.
So, to add the 50 GB of free space to disk0s3
you would have to first move this partition up by 50 GB. I do not believe there currently exists software which can move a APFS container. Therefore, you can not move space from one APFS container to another APFS container.
Alternative solutions could include:
- Clone the contents
disk0s3
to
disk0s2
. See Geoff Nixon's answer for one such way to clone the contents.
- Install a fresh copy of Mojave
in
disk0s2
, then use the Migration Assistant application to copy
important data from disk0s3
. I should warn you that I have no
knowledge if the Migration Assistant will work with two APFS
container partitions on the same drive.
- Backup
disk0s3
to another drive by using Time Machine or some other means. You could then try restoring to disk0s2
Implementing any of the above solutions would allow you to remove disk0s3
and resize disk0s2
to contain the space originally occupied by both partitions.
Appendix
Often a user needs to know the partitioning of a drive. In particular, were the free space is. The diskutil list disk0
command shows the partitions in ascending order and the size of each partition. However, this command does not show free space. The Disk Utility application does occasionally show free space but the value is often incorrect and does not show where the free space is with respect to the other partitions
So, where is the free space shown? Here are a few ways to determine where the free space is.
- The
sudo gpt -r show /dev/disk0
command will show the logical sector blocks used by each partition. The command will also show the free space between each partition in logical sector block units. In the days of OS X, you could run this command on the boot drives. Starting with macOS, System Integrity Protection (SIP) has to be disabled to do this.
- Use the
diskutil info -plist disk0s#
command to retrieve partition number #
start and size byte values. You need to repeat the command for each partition on a drive. Next, you can compile a table similar to the output from the gpt -r show /dev/disk0
command. Basically, free space is any space not allocated to a partition, the Protected Master Boot Record (PMBR) and the GUID Partition Tables (GPT).
Write a BASH script that would automate way number 2. A free script can be downloaded from this site. Assuming your downloads goto to the default Downloads
folder, you can get the free space by entering the command shown below. Note: You do not need to enter sudo
or disable SIP.
~/Downloads/driveinfo-1.0.1/driveinfo -r disk0
A Note about using APFS container partitions
It is not normal to have two APFS container partitions on the same drive. Doing so, defeats one of the principle reasons for the creation of the APFS. If you need two different APFS volumes, the you should create each volume in the same APFS container partition. This is also true, if you want to have two or more different versions of High Sierra and/or Mojave installed.
When you want remove a APFS volume, then the free space is automatically returned to the APFS container. You should not need to enter a sudo diskutil apfs resizeContainer disk0s# 0
command. If you delete a volume containing a version of macOS, then there is some additional clean up that needs to be preformed. The necessary clean up steps are outlined in the accepted answer to the question: Remove macOS from a APFS container?
Best Answer
Below is an example of where the macOS versions named Mojave, Catalina and Big Sur (beta) have been installed in the same container. This is a triple boot arrangement. The output from
diskutil list
is shown below.All the APFS volumes and snapshots exist in the same container partition and therefore share the space allotted to the container.
The OP's question indicates the assumption that each version of macOS would reside in a single volume. This is not true. In this example, Mojave uses 4 volumes, Catalina uses 5 volumes and Big Sur uses 6 volumes. The
Preboot
(disk1s2
),Recovery
(disk1s3
) andVM
(disk1s4
) volumes are shared by all three macOS versions.Below are the result of enter commands to get the volume uuid for the
MyMojave
,MyCatalina
andMyBigSur - Data
volumes. Each UUID is generated when a volume is created and therefore all such UUIDs are unique.Normally, macOS boots from the
Preboot
volume. Although all three macOS version share the samePreboot
volume, they do not share the same preboot software. The preboot software for each macOS version is stored in a folder which has the same name as the UUID for a volume uniquely used by each macOS version. For this example, the boot software forMyBigSur
is be stored in the folder named383CF355-F467-48CE-9124-B24149322EA7
on thePreboot
volume. Note that the name of the folder is the same as the volume UUID for the "MyBigSur - Data" volume given above.Basically, the same setup is used to store the macOS Recovery software for each version of macOS, except the
Recovery
(disk1s3
) volume is used.The
VM
(disk1s4
) volume is used by all three versions of macOS for virtual memory.Mojave has an additional volume which is the root volume. For this example, this root volume is named
MyMojave
and has the identifierdisk1s1
.When booted to Catalina, the root volume is mounted read-only. For this example, this root volume is named
MyCatalina
and has the identifierdisk1s6
. Catalina has an additional volume which is both read and writeable. For this example, this volume is namedMyCatalina - Data
and has the identifierdisk1s5
.When booted to Big Sur, the volume is named
MyBigSur
(disk1s8
) is not even mounted. Instead, a snapshot volume (disk1s8s1
) is mount as root. Big Sur has an additional volume which is both read and writeable. For this example, this volume is namedMyBigSur - Data
and has the identifierdisk1s5
.