Re: Question about 'gptzfsboot'

On Mon, 2019-04-29 at 10:33 -0400, Thomas Laus wrote:
> > On 2019-04-28 22:27, Ian Lepore wrote:
> > > 
> > > If you're using gptzfsboot, I guess you're using zfs?  I just
> > > fixed a
> > > problem with probing disks for zfs volumes a few days ago
> > > (r346675). 
> > > There is even some small chance it fixes this problem, because
> > > one of
> > > the things I noticed was that in one of the disk structures in
> > > loader,
> > > the "slice offset" value was sometimes a bit random-looking, like
> > > it
> > > was being initialized with whatever garbage was laying around in
> > > memory.  It actually makes some sense that the "garbage" might be
> > > different between a firstboot after power-on and a reboot.
> > > 
> > > So all in all, it wouldn't hurt to update both gptzfsboot and
> > > loader
> > > (gpart bootcode -b and -p) to see if there's a fix lurking in my
> > > zfs
> > > probe changes.
> > > 
> > 
> > I'll build and update my laptop OS this morning and report back to
> > this
> > thread if I have any additional issues.
> > 
> 
> Ian:
> 
> Updating to r346885 turned out to be a disaster!  There were changes
> to
> DRM between FreeBSD 13.0-CURRENT r346544 and r346885.  The desktop
> that
> I use for a build machine because it is much faster than any of my
> other
> PC's installed kernel and world without any problems including
> starting
> 'X'.  I had to update the drm-current-kmod port on my build
> PC.  Nothing
> was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do
> so.
>  DRM on my build computer did not start until the update and then
> worked
> as expected.
> 
> I did the same on my Dell laptop and it crashed on the first boot
> right
> after loading DRM-kmod.  I removed the line in rc.conf that activates
> the kernel module and my laptop booted into multiuser.  When I
> started
> 'X' it crashed just like before.  The screen was black and I could
> not
> login remotely via SSH.  Nothing in any system log.  The Xorg log
> shows
> this and stops:
> 
>  40.979]    compiled for 1.18.4, module version = 2.4.0
> [    40.979]    Module class: X.Org Video Driver
> [    40.979]    ABI class: X.Org Video Driver, version 20.0
> [    40.979] (II) intel: Driver for Intel(R) Integrated Graphics
> Chipsets:
>         i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM,
> 865G,
>         915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
>         Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33,
> Q35,
> Q33,
>         GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
> [    40.981] (II) intel: Driver for Intel(R) HD Graphics
> [    40.981] (II) intel: Driver for Intel(R) Iris(TM) Graphics
> [    40.981] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
> [    40.981] (II) modesetting: Driver for Modesetting Kernel Drivers:
> kms
> [    40.981] (II) scfb: driver for wsdisplay framebuffer: scfb
> [    40.981] (II) VESA: driver for VESA chipsets: vesa
> [    40.981] (--) Using syscons driver with X support (version 2.0)
> [    40.981] (--) using VT number 9
> 
> I had to recover my system using beadm to rollback to the last
> CURRENT
> snapshot from a week ago.
> 
> Tom
> 
> 

I'm fighting my own video driver troubles (seems like a lot of that
going around lately); on an upgrade of a machine from 11-stable to 12-
stable I lost my console.

But, a broken kernel and/or userland shouldn't affect your ability to
use the new boot components.  That is, you can use gptzfsboot and
loader that contain my fixes, and use them to load an older kernel that
has working video drivers.

-- Ian