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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

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

Colin Watson
On Thu, Jun 17, 2021 at 02:38:15PM -0400, Eric Wood wrote:
> 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.

This happens on BIOS (non-UEFI) systems where they're configured to
install GRUB to a disk that isn't the one that the system is actually
booting from.  Although it happens on upgrades, it's really more the
fault of whatever configured the system that way in the first place than
of the upgrade process itself.

> So we used  https://help.ubuntu.com/community/Boot-Repair and got the broke
> system running very easily.

boot-repair may manage a one-time fix, but if I were you I would not
rely on it having fixed the problem at its root.  To fix the problem at
its root, you need to run this:

  sudo dpkg-reconfigure grub-pc

... and (unless you know better) change the answer to the "GRUB install
devices" question to install GRUB to the boot record of all your drives,
so in your case /dev/nvme0n1 and /dev/nvme1n1; that way it doesn't
matter which one of those the BIOS decides to boot from.  You can leave
the answers to all the other questions unchanged.

> 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.

This machine was evidently set up using BIOS rather than UEFI, which is
why that happened.  If you intended them to be identical, then this is a
pretty major difference.  To fix that, you'd need to reinstall this
system, and make sure that you're booting the installer in UEFI mode
(which is typically a matter of making sure that the system firmware is
configured to boot removable media in UEFI mode rather than what it may
call something like "legacy" or "CSM" mode).

--
Colin Watson (he/him)                              [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users