Container disk issue in Disk Utility

[tzzzt]

Hi, I could really use some help here.
I noticed something strange on my Macbook pro with a T1 chip that is operating on a Mojave OS. When I used the disk utility in the normal mode, under the Internal tab after I clicked open all devices, it says it contains Container disk 1. But when I used the disk utility in the recovery mode, under the Internal tab, it says it contains Container disk 2 instead. I was under the impression that the same Container disk should be shown in both the normal and recovery mode for the disk utility. Is there a reason why there are 2 different containers being shown and if having this situation a cause for concern? In addition, is there any way to fix this issue?
I have attached the relevant screenshots for reference.
Any assistance would be greatly appreciated!

 

[Kumar Anne]

I have the same problem

 

[Brian33]

TL;DR: This is not a problem. This number can change when you reboot because they refer to /dev/disk"n" device numbers. The way to see the full picture is to use the Terminal command diskutil list.

Looking at my Mojave iMac (in "normal mode"), it says "Container disk3". (I do have several physical drives attached.) The "3" refers to the "device" /dev/disk3, which is the boot device, even though it is a "synthesized" (not physical) device. With Mojave both synthesized and physical devices get assigned a /dev/disk"n" number. Disk images that are mounted also get a device number. The important point is that those device numbers are assigned at boot time and can be different on every boot! I think it depends upon what devices and disk images are attached and the timing of their responses. Normally you never see these device numbers unless you use Terminal commands, but in this instance it's interesting to see that the Disk Utility window does expose one of the numbers to the user.

Notice when you are in recovery mode, there is an additional "device" attached -- the "Apple Disk Image" -- and I expect it is getting assigned /dev/disk1, so that forces your synthesized boot disk to be assigned /dev/disk2. Boot to normal mode and the disk image is not there, so the synth disk gets /dev/disk1 in that case. Makes sense to me.

You can verify all this with the command I mentioned -- and you'll also notice that these numbers actually start from 0...