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

> On 2 Dec 2018, at 01:11, Mark Martinec <Mark.Martinec+freebsd_at_ijs.si> wrote:
> 
> 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
> 

The files are /boot/loader* binaries - to be exact, check which one is linked to /boot/loader. I can provide binaries if needed.

Can not tell about post in freebsd-stable - it simply does not provide enough information.

rgds,
toomas


> 
>>> 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
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"