do-release-upgrade command left /dev/nvme1 unbootable on 20.04 LTS

[Eric Wood]

2 identical systems.  Both with 2 nvme chips.   1 chip is for the system 
and the other chip is installed for future use.

Performing the do-release-upgrade command, one system upgraded fine and 
rebooted fine. Here is it's layout:
$ lsblk -l
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1   259:0    0 232.9G  0 disk
nvme0n1p1 259:1    0   512M  0 part /boot/efi
nvme0n1p2 259:2    0   100G  0 part /www
nvme0n1p3 259:3    0    16G  0 part [SWAP]
nvme0n1p4 259:4    0 116.4G  0 part /
nvme1n1   259:5    0 232.9G  0 disk

$ sudo sfdisk -l
Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048   1050623   1048576   512M EFI System 
<----------------------
/dev/nvme0n1p2   1050624 210765823 209715200   100G Linux filesystem
/dev/nvme0n1p3 210765824 244320255  33554432    16G Linux swap
/dev/nvme0n1p4 244320256 488394751 244074496 116.4G Linux filesystem


The other system got into an infinite loop during the upgrade script 
saying it had trouble making a boot partition.  So we had to abort the 
script.  This left the system unbootable with this grub error:
Error: symbol 'grub_file_filters' not found.

So we used  https://help.ubuntu.com/community/Boot-Repair and got the 
broke system running very easily.   This is it's layout:

$ lsblk -l
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1   259:0    0 232.9G  0 disk
nvme1n1   259:1    0 232.9G  0 disk
nvme1n1p1 259:2    0     1M  0 part
nvme1n1p2 259:3    0   100G  0 part /www
nvme1n1p3 259:4    0    16G  0 part [SWAP]
nvme1n1p4 259:5    0 116.9G  0 part /

$ sudo sfdisk -l
Device             Start       End   Sectors   Size Type
/dev/nvme1n1p1      2048      4095      2048     1M BIOS boot 
<----------------------
/dev/nvme1n1p2      4096 209719295 209715200   100G Linux filesystem
/dev/nvme1n1p3 209719296 243273727  33554432    16G Linux swap
/dev/nvme1n1p4 243273728 488394751 245121024 116.9G Linux filesystem

I don't know why we installed Ubuntu on nvme0 on one system and nvme1 on 
the other.   Maybe the BIOS settings were different at install time.  
Bit, I'm now noticing that /dev/nvme1n1p1 was set up as 1Meg BIOS boot 
partition instead of a EFI system parition - another thing  we may have 
screwed up when setting up these two identical boxes.

Regardless, is this still an Ubuntu upgrade bug?  Thanks,
-Eric