Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

Mark Martinec Mark.Martinec+freebsd at ijs.si
Sat Dec 1 23:11:13 UTC 2018


2018-11-29 18:43, Toomas Soome wrote:
> I just did push biosdisk updates to stable/12, I wonder if you could
> test those bits…

Thank you!  I haven't tried it yet, but I wonder whether this fix was
already incorporated into 12.0-RC3, which would make my rescue easier.

Otherwise I can build a stable/12 on another host and transplant
the problematic file(s) to the affected host - if I knew which files
to copy.

I wonder also, if the today's posting by cksalexander at q.com on the
freebsd-stable ML titled "FreeBSD-12.0-RC3-i386-disc1.iso does not boot"
could be describing the same problem?

   Mark


>> On 29 Nov 2018, at 17:01, Mark Martinec <Mark.Martinec+freebsd at ijs.si> 
>> wrote:
>> 
>> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 
>> (amd64,
>> zfs, bios), I tried my luck with one of our production hosts, and 
>> ended up
>> with a stuck loader after rebooting with a new kernel (after the first
>> stage of upgrade).
>> 
>> These were the steps, and all went smoothly and normally until a 
>> reboot:
>> 
>>  freebsd-update upgrade -r 12.0-RC2
>>  freebsd-update install
>>  shutdown -r now
>> 
>> While booting, the 'BTX loader' comes up, lists the BIOS drives,
>> then the spinner below the list comes up and begins turning,
>> stuttering, and after a couple of seconds it grinds to a standstill
>> and nothing happens afterwards.
>> 
>> At this point the ZFS and the bootstrap loader is supposed to
>> come up, but it doesn't.
>> 
>> This host has too zfs pools, the system pool consists of two SSDs
>> in a zfs mirror (also holding a freebsd-boot partition each), the
>> other pool is a raidz2 with six JBOD disks on an LSI controller.
>> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
>> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
>> is happy with both pools.
>> 
>> After rebooting from an USB drive and reverting the /boot directory
>> to a previous version, the machine comes up normally again
>> with the 11.2-RELEASE-p4.
>> 
>> I found a file init.core in the / directory, slightly predating the
>> last reboot with a salvaged system - although it was probably not
>> a cause of the problem, but a consequence of the rescue operation.
>> 
>> It is unfortunate that this is a production host, so I can't play
>> much with it. One or two more quick experiments I can probably
>> afford, but not much more. Should I just first wait for the
>> official 12.0 release? Should I try booting with a 12.0 on USB
>> and try to import pools? Suggestions welcome.
>> 
>> 
>> 
>> Now that the /boot has been manually restored to the 11.2 state,
>> A SECOND QUESTION is about freebsd-update, which still thinks we are
>> in the middle of an upgrade procedure. Trying now to just update
>> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
>> 
>>  # uname -a
>>  FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
>>  #
>>  # freebsd-version
>>  11.2-RELEASE-p4
>>  #
>>  # freebsd-update fetch
>>  src component not installed, skipped
>>  You have a partially completed upgrade pending
>>  Run '/usr/sbin/freebsd-update install' first.
>>  Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
>> 
>> So what is the right way to get rid of all traces of the
>> unsuccessful upgrade, and let freebsd-update believe we are cleanly
>> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
>> 
>>  Mark


More information about the freebsd-stable mailing list