r326820 stuck on bootloader

[Warner Losh]

On Mon, Dec 18, 2017 at 9:52 AM, O. Hartmann <ohartmann at walstatt.org> wrote:

> Am Mon, 18 Dec 2017 09:48:01 -0700
> Warner Losh <imp at bsdimp.com> schrieb:
>
> > On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann <ohartmann at walstatt.org>
> wrote:
> >
> > > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST)
> > > "Rodney W. Grimes" <freebsd-rwg at pdx.rh.CN85.dnsmgr.net> schrieb:
> > >
> > > >
> > > > > Hey all!
> > > > >
> > > > > I have just downloaded
> > > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > > > > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > > > > internal video/keyboard" and then it's stuck.
> > > > >
> > > > > I actually have no idea how to debug, any help would be
> appreciated.
> > > >
> > > > This snapshot may have broken boot code in it, I had problems
> > > > installing it to a zfs system and had to post install replace
> > > > my zfs boot blocks from those of 20171206.
> > > >
> > > >
> > > > > Thanks in advance,
> > > > > - --
> > > > > antranigv
> > > >
> > >
> > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I
> > > had no problems
> > > with r326583, but r326584 and beyond had compilation issues). I tried
> > > r326593 and it
> > > worked for me (had issues on a serial console for the PCengine APU2C4).
> > >
> > > From usr/src/UPDATING, tag designated by "20171215":
> > >
> > > 20171215:
> > >         r326887 fixes the issue described in the 20171214 UPDATING
> entry.
> > >         r326888 flips the switch back to building GELI support always.
> > >
> > > [...]
> > >
> > > I tried the first time r326888 on the APU 2C4 and it worked again -
> this
> > > doesn't imply
> > > that the GPT GELI and ZFSBOOT loader are all right again, but Warner
> Losh
> > > stated it is
> > > fixed.
> > >
> >
> > Yes. I've confirmed that zfsboot works with or without the GELI code
> > compiled in. I've not confirmed that ZFS + GELI partitions work. I
> haven't
> > updated my test scripts in tools/boot/genroot.sh to create them yet. If
> > someone who knows this stuff really well wants to do that for one image
> > (gpt + zfs + geli) I can (a) test and (b) generalize.
> >
> > Warner
>
> Oh, my bad. So it is still to use with caution?
>

I have good reason to believe it will work. I fixed the underlying issues
that were broken in '593, so I think it will work again. I just haven't
confirmed it and hoped that someone else could get to it before I could :)


> At that point I can not understand why the build of bootable images is
> still in progress.
> People which desperate in need of a bootable image may download the wrong
> one from the
> FreeBSD site - and find out the harsh way it is broken. If the build of
> those images is
> automated - can this be stopped?


 That shouldn't be necessary. The normal images should be fine.

Warner