Willem Jan Withagen
2018-Dec-07 18:08 UTC
Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
On 05/12/2018 00:48, Toomas Soome wrote:> Yes, that must be true but it does not hurt to get checked. > > And of course, lsdev -v from 11.x loader would be good too. > > Anyhow, I am afraid we have reached to point where more specific debug info is needed (printed out), with lack of output about disks at all, it must be related to floppy device checks.Just another point in time. Ended up more or less in the same situation this afternoon with freebsd-upgrade to RC3 Boot stops after listing all DOS disks, in a spinner. So that is no fix. I booted from USB 11.2 and replaced the /boot/zfs{boot,loader} by the 11.2 ones. That makes my server again happy. --WjW> Rgds, > Toomas > > Sent from my iPhone > >> On 4 Dec 2018, at 22:19, Ian Lepore <ian at freebsd.org> wrote: >> >> On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable >> wrote: >>>> On 4 Dec 2018, at 19:59, Mark Martinec <Mark.Martinec+freebsd at ijs.s >>>> i> 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? >>>> Myself wrote: >>>>>> 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. >>>> 2018-12-02 18:59, Toomas wrote: >>>>> The files are /boot/loader* binaries - to be exact, check which >>>>> one is >>>>> linked to /boot/loader. I can provide binaries if needed. >>>>> [...] >>>>> rgds, >>>>> toomas >>>> I got a maintenance window today so I tried with the new loader, >>>> and it did not help. >>>> >>>> More specifically: >>>> >>>> As it comes with 12-RC2, the /boot/loader was hard linked with >>>> loader_lua. >>>> Its size is 421888 bytes. So I concentrated on this loader. >>>> >>>> I build a fresh stable/12 on another host, and copied the newly >>>> built loader_lua (425984 bytes) to the /boot directory of the >>>> affected >>>> host, deleted the file 'loader', and hard-linked loader_lua to >>>> loader. >>>> >>>> The situation has not changed: the BTX loader lists all BIOS drives >>>> C..J (disk0..disk7), then a spinner starts and gets stuck forever. >>>> It never reaches the 'BIOS 635kB/3537856kB available memory' line. >>>> >>>> While trying to restore the old /boot from 11.2, I tried booting >>>> a live image from a 12.0-RC3 memory stick - and the loader got >>>> stuck again, same as when booting from a disk. >>>> >>>> So I had to boot from an 11.2 memstick to be able to regain >>>> control. >>>> >>>> Mark >>>> >>>> >>> ok, if you could perform 2 tests: >>> >>> 1. from loader prompt enter 0x413 0xa000 - @w . cr >>> >>> 2. on first spinner, press space and type on boot: prompt: >>> /boot/loader_4th and see if that will do better >>> thanks, >>> toomas >>> >> I don't think that will be an option. If it hasn't gotten to the point >> of saying how much BIOS available memory there is, it's only halfway >> through loader main() and has hung before getting to interact(). >> >> In fact, if that line hasn't printed, but some disk drives have been >> listed, it pretty much has to be hung in the "March through the device >> switch probing for things" loop. If all the disks are listed, then it >> got through that entry in the devsw, and is likely hanging in the >> dv_init calls for either the pxedisk or zfsdev devices. >> >> -- Ian >> >>>> >>>>>>>> On 29 Nov 2018, at 17:01, Mark Martinec <Mark.Martinec+free >>>>>>>> bsd 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-stable at freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd. >>> org" >>> >> _______________________________________________ >> 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" > _______________________________________________ > 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"
Mark Martinec
2019-Dec-10 14:18 UTC
Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
Commenting on a thread from 2018-12 and from 2019-09-20, with my solution to the boot problem at the end, in case anyone is still interested. ====== On 2018-11-29 myself wrote: (after upgrading from 11.2 to 12.0):> 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.[...] (on 2018-12-04):> The situation has not changed: the BTX loader lists all BIOS drives > C..J (disk0..disk7), then a spinner starts and gets stuck forever. > It never reaches the 'BIOS 635kB/3537856kB available memory' line. > > While trying to restore the old /boot from 11.2, I tried booting > a live image from a 12.0-RC3 memory stick - and the loader got > stuck again, same as when booting from a disk. > So I had to boot from an 11.2 memstick to be able to regain control.====== 2018-12-04, Ian Lepore writes:> Toomas Soome wrote: > | ok, if you could perform 2 tests: > | 1. from loader prompt enter 0x413 0xa000 - @w . cr > | 2. on first spinner, press space and type on boot: prompt: > | /boot/loader_4th and see if that will do better > | thanks, toomas > I don't think that will be an option. If it hasn't gotten to the point > of saying how much BIOS available memory there is, it's only halfway > through loader main() and has hung before getting to interact(). > > In fact, if that line hasn't printed, but some disk drives have been > listed, it pretty much has to be hung in the "March through the device > switch probing for things" loop. If all the disks are listed, then it > got through that entry in the devsw, and is likely hanging in the > dv_init calls for either the pxedisk or zfsdev devices.====== 2018-12-07 19:08, Willem Jan Withagen wrote:> Ended up more or less in the same situation this afternoon with > freebsd-upgrade to [12.0]-RC3 > Boot stops after listing all DOS disks, in a spinner. > So that is no fix. > > I booted from USB 11.2 and replaced the /boot/zfs{boot,loader} by the > 11.2 ones. > That makes my server again happy.=======are 2019-09-19 16:02, Kurt Jaeger wrote: Subject: Re: Lockdown adaX numbers to allow booting ?> | Kurt Jaeger writes: > | The problem is that if all 10 disks are connected, the system > | looses track from where it should boot and fails to boot (serial > boot log): > | > | Consoles: internal video/keyboard serial port > | BTX loader 1.00 BTX version is 1.02 > | Consoles: internal video/keyboard serial port > | BIOS drive C: is disk0 > | BIOS drive D: is disk1 > | BIOS drive E: is disk2 > | BIOS drive F: is disk3 > | BIOS drive G: is disk4 > | BIOS drive H: is disk5 > | BIOS drive I: is disk6 > | BIOS drive J: is disk7 > | BIOS drive K: is disk8 > | BIOS drive L: is disk9 > | // > | [...] > | The solution right now is this to unplug all disks of the 'bck' > pool, > | reboot, and re-insert the data disks after the boot is finished. > | [...] > | No gpart on the bck pool, raw drives.2019-09-20 17:27, Mark Martinec wrote: Subject: Re: Lockdown adaX numbers to allow booting ?> > This sounds very much like my experience: > > 2018-11-29, Boot loader stuck after first stage upgrading 11.2 to > 12.0-RC2 > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-November/090129.html > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090159.html > > I now have three SuperMicro machines which are unable to boot after > upgrading 11.2 to 12.0. After unsuccessfully fiddling with boot > loaders, > I have reverted two back to 11.2 (which boots and works fine again), > and the third one is now at 12.0 but needs the boot hack as described > by Kurt, i.e. pull out half the disks (of the 'data' pool), boot the > system, plug the disks back in and zfs mount the remaining pool. > > Considering that the 11.2 boots and works fine on these machines, > I consider it a btx loader failure and not a BIOS issue. > > What is common with these three machines is that they have one pool > on raw devices for historical reasons (not on gpt partitions). > My guess is that the new loader gets confused by these raw disks.====== Ok, now to my current situation and solution/workaround. What was common with these hosts (and similar) is that a machine has more than a couple of disks, with a zfs pool (non-root) on raw devices (for historical reasons), not on gpt partitions. Three workarounds seem possible: - replace a boot loader with the one from 11.2, or - using a default loader from 12, disconnect a sufficient number of data disks, boot, then reconnect disks and zfs attach the pool, - or my current solution: zfs offline one disk at a time from a data pool, wipe it, set up a gpt partition on it and put it back to the pool by 'zfs replace', letting it resilver. It was a painful and slightly risky procedure (9 hours of resilvering each of the seven disks), but this procedure has now salvaged our remaining hosts which could not be upgraded from 11.2 to 12. Mark