Solved Upgrade problem 11.2 to 12.0 no bootable disk

B

Botanic

So I started upgrading my 11.2-RELEASE to 12.0-RELEASE...
There were no errors during the upgrade.
Everything went well until the first reboot.

Now when the server boots it doesn't find a bootable partition.
It looks as if the disks are empty with no boot loader.

I downloaded a 12.0 iso and booted from it.
From there I can do a gpart show and see the partitions, but I have no idea where to go from here.

I don't have a complete backup, so I'm not very cocky.

As you can see on the attached picture ada2 is my boot disk. It's an SSD with ZFS.
BIOS is set to UEFI boot.

Please help!
 

Attachments

  • gpart.PNG
    gpart.PNG
    86.5 KB · Views: 420
How exactly did you upgrade? There are multiple ways to do this, so just sharing that you upgraded doesn't tell us anything useful.

Alas: if you're in the boot menu press escape to drop down to the ok> prompt and then try the lsev command, see if that mentions anything about your ZFS pool(s).

Using that boot cd you can also try: # zpool import to see if it detects your ZFS pool(s).
 
Sorry. I did
Code: 
freebsd-update -r 12.0-RELEASE upgrade
and then
Code: 
freebsd-update install
Then a reboot. There is no boot menu.

Booting with the 12.0 iso and doing zpool import doesn't find the zpools.
 
Do you have loader prompt ?
What is the currdev and loaddev values from command 'show' in loader prompt ?
What lsdev returns ?
 
There is no loader prompt.
When I boot the server is goes directly into trying to boot with PXE.
If I go into boot settings and specify only the disk where FreeBSD is installed, it just blinks and behaves the same way as if there was nothing to boot from on the disk.

I have FreeBSD-12.0-RELEASE-amd64-disc1.iso to boot from (over iLO).
That doesn't seem to have lsdev.
Should I try booting with some other image?

Booting with that iso, dmesg finds my disks. The command gpart show, shows the disks but all zpool commands fail with an error message saying that there are no pools.
 
Have you tried to set legacy BIOS mode to boot on ada2?

Not a solution, of course, but maybe your server will start.
 
Legacy mode did not work.
But...

Doing "zpool import" works now.
I don't understand what I did differently yesterday, maybe I was tired.
Anyway, this feels like a game changer.

What should I do now in order to get the system running again?
I guess I need to mount the existing installation and make it bootable somehow.
I'm still a noob when it comes to ZFS so this is maybe a good learning experience.
 

Attachments

  • zpool_import_11.2.PNG
    zpool_import_11.2.PNG
    12.6 KB · Views: 248
My upgrade didn't get as far as on that bug. Also my server doesn't get that far booting.

Booting with the 11.2 installation CD I think I should be able to boot from the boot loader.

I have done:

Code: 
set currdev=zfs:zroot/ROOT/default:
load boot/kernel/kernel
load boot/kernel/zfs.ko <- This one fails due to missing module 'opensolaris'
autoboot


Please see attached pictures.

Any ideas on what to do? What is the thing with the opensolaris module?
 

Attachments

  • mount_error.PNG
    mount_error.PNG
    37.3 KB · Views: 265
  • opensolaris.PNG
    opensolaris.PNG
    15.4 KB · Views: 312
OK. Hope is coming back.

I managed to boot the server with the old kernel.
I booted the server with FreeBSD-12.0-RELEASE-amd64-disc1.iso, pressed 3 to escape to loader, then this:
Code: 
set currdev=zfs:zroot/ROOT/default:
load /boot/kernel.old/kernel
load /boot/kernel.old/opensolaris.ko
load /boot/kernel.old/zfs.ko
autoboot

The server is in some kind of unstable state right now.
There are several things not working and some things working.
It's running kernel 11.2-RELEASE-p5 with no working boot loader and most things upgraded to 12.0-RELEASE.

What should I do? Go back to 11.2 or continue to 12.0?
And how do I do it without getting into a worse state?
 
An update of the problem:
I wasn't able to mount my EFI partition. I don't know why, but something went wrong with it during the upgrade:
Code: 
# mount -t msdosfs /dev/ada2p1 /mnt
mount_msdosfs: /dev/ada2p1: Invalid argument

So I re-created it:
Code: 
# newfs_msdos ada2p1
# mount -t msdosfs /dev/ada2p1 /mnt
# mkdir -p /mnt/EFI/BOOT
# cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi

Now it boots as supposed with 11.2, even though there are few traces of 12.0 left.
I will probably try and upgrade to 12.0 again when I get time for it.

According to https://wiki.freebsd.org/UEFI the EFI partition is supposed to be FAT32:
Code: 
newfs_msdos -F 32 -c 1 /dev/da0p1

As my installation is old, the partition is too small for FAT32:
Code: 
# df -h /dev/ada2p1
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada2p1    767K    449K    318K    59%    /mnt

Here is a discussion from 2016 about increasing the size of the partition to 200 MB from 800 KB: https://reviews.freebsd.org/D6935
Maybe there is something in the upgrade that assumes that the partition is bigger than my 800K FAT12 partition?
 
Possible. I was thinking a problem in your EFI partition or EFI loader file. This is why I advised you to boot in legacy BIOS mode but I'm now really surprised it didn't work.
 
I also did /sbin/gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada2. Maybe the bootcode was faulty as well. I didn't try legacy BIOS mode after that command.
 
There is a problem with the12.0 version of gptzfsboot as it can't boot a 11.2 system whereas the 11.2 version of gptzfsboot can boot either 11.2 and 12.0 systems. I tasted the thing...

But this is not your case I think, since you didn't update the bootcode before rebooting (and even it should have worked).

On a 11.2 VM, I modified the efi partition (which is FAT32 and 200 MiB sized by default) to a 800 KiB FAT12 as you have. Then, I upgraded to 12.0-RELEASE but I got no trouble. The whole upgrade process went just fine

So, your real problem isn't the size nor the file system of your efi partition.
 
Thanks for the help and support!
I upgraded the system to 10.0 and everything went as supposed this time.
I don't know what went wrong with the EFI partition and possibly the bootcode during the first upgrade attempt.
Maybe it was just one of those things...
 
You must log in or register to reply here.
Back
Top