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

2018-12-01 Thread Mark Martinec

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


Re: gpart: param 'skip_dsn': Invalid argument (13-CURRENT/amd64)

2018-12-01 Thread Lev Serebryakov
Hello Ronald,

Saturday, December 1, 2018, 6:47:45 PM, you wrote:

> I got this response after gpart bootcode.
> Should I be worried?

> [AFTER make installkernel && make installworld]
> --
 Installing everything completed on Sat Dec  1 15:43:19 CET 2018
> --
> [root@sjakie /data/src/freebsd-current]# gpart bootcode -b /boot/pmbr -p  
> /boot/gptzfsboot -i 1 ada0
> partcode written to ada0p1
> gpart: param 'skip_dsn': Invalid argument
 You need new geom_part.ko or old userland part. There was change which make
new gpart userland utility incompatible with old kernel module.

 It is why source upgrade procedure "officialy" requires reboot after
install kernel and before installworld.

 You could repeat re-installation of "gpart bootkode -b /boot/pmbr" after
reboot. Now your bootcode (pmbr) has not been upgraded. I don't think it
will cause a problem, as last changes to it was made long time ago :-)


-- 
Best regards,
 Levmailto:l...@freebsd.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


gpart: param 'skip_dsn': Invalid argument (13-CURRENT/amd64)

2018-12-01 Thread Ronald Klop

I got this response after gpart bootcode.
Should I be worried?

[AFTER make installkernel && make installworld]
--

Installing everything completed on Sat Dec  1 15:43:19 CET 2018

--
[root@sjakie /data/src/freebsd-current]# gpart bootcode -b /boot/pmbr -p  
/boot/gptzfsboot -i 1 ada0

partcode written to ada0p1
gpart: param 'skip_dsn': Invalid argument


Regards,
Ronald.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"