I think I followed everything correctly, but I'm guessing I probably did not, can I added verbose boot argument to see if i could figure out the issue and I am not completely sure what this means. Or what step I missed.
Your verbose screen doesn't tell much, while you should have had install on a clean Catalina APFS Volume, I guess instead you upgraded from a Catalina USB Installer your previous APFS Mojave (or worst an HFS+ Mojave), apparently there are permissions issues on some frameworks before reaching the GUI Mode, you could try to fix them booting in single user mode (holding CMD+S) and typing:
mount -uw /
chown -R 0:0 /System/Library/Frameworks/
chmod -R 755 /System/Library/Frameworks/
chown -R 0:0 /System/Library/PrivateFrameworks/
chmod -R 755 /System/Library/PrivateFrameworks/
exit
But before do that, once following an apple guide, I wrote something about changing the
APFS Volumes Roles
It seems from your verbose that your previous Mojave (now Catalina) System/Data Volume doesn't have a valid APFS Role, it's reported as "0" (zero) that is according to the APFS scheme a non-system and non-data volume, but apparently your UUID is valid.
So could try to give it a Role in this way, but you need to boot or from Catalina USB Installer, or HighSierra/Mojave Installer from a Recovery Terminal:
mount -uw /
diskutil apfs list (or diskutil list)
Locate your Catalina APFS (Preboot, VM, Recovery, System and Data) disk identifiers example diskXsY of your System Volume
diskutil mount diskXsY1
diskutil apfs changeVolumeRole diskXsY1 S (This represents the System Volume)
diskutil apfs updatePreboot diskXsY1
(not sure if really needed the next lines I'm typing but if you want to set an APFS Role for each Volume you should add)
diskutil apfs changeVolumeRole diskXsY2 B (this represents the Preboot Volume)
diskutil apfs changeVolumeRole diskXsY3 R (this represents the Recovery Volume)
diskutil apfs changeVolumeRole diskXsY4 V (this represents the VM Volume)
I don't know yet the real role decided by apple for the new "APFS Data" but it should be this:
diskutil apfs changeVolumeRole diskXsY5 U (standing for Users I guess)
because I based on the fact that these are the APFS Volume Roles established by apple:
<roles> = one or more of 0|B|U|S|R|V
"0" is a generic empty APFS Volume containerized.
NOTE that Y1-Y5 are just indicatives partitions but you could have the Recovery on Y4 and System on Y3 for example.
[doublepost=1560256238][/doublepost]
You can patch the OSInstaller to ignore the mpkg signature errors.
BaseSystem.dmg/System/Library/PrivateFrameworks/OSInstaller.framework/Versions/A/OSInstaller
10.15.beta.19A471t
perl -pi -e "s|\x0f\x84\xbc\x0f\x00\x00\x48\x8b\x3d|\x90\x90\x90\x90\x90\x90\x48\x8b\x3d|g" OSInstaller
codesign -f -s - OSInstaller
But you will need to re-pack the BaseSystem.dmg, and check the size of /macOS Install Data/index.sproduct after installation stage 1.
Yes, I used your "perl" method earlier (during Sierra/HighSierra beta or Mojave) to create a custom Installer and it does allow to use an invalid signed OSInstall.mpkg allowing to customize the Distribution file inside avoiding the "package appears to be missing or damaged" in the OSX Installer GUI Mode.