Re: Call for Testing: UEFI Changes

As I said I would, I put the contents of /boot onto the FAT-formated EFI
partition.  This is suboptimal.  The default is to use "kernel.old" ...
etc  ... which cannot be done on a FAT partition... at least not with our
filesystem driver ...

... but with all of /boot on the EFI partition, simply starting loader.efi
works.

On Wed, Apr 4, 2018 at 11:57 AM, Kyle Evans <kevans_at_freebsd.org> wrote:

> On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans <kevans_at_freebsd.org> wrote:
> > Hello!
> >
> > A number of changes have gone in recently pertaining to UEFI booting
> > and UEFI runtime services. The changes with the most damaging
> > potential are:
> >
> > We now put UEFI runtime services into virtual address mode, fixing
> > runtime services with U-Boot/UEFI as well as the firmware
> > implementation in many Lenovos. The previously observed behavior was a
> > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
> > just loading efirt.ko or compiling EFIRT into the kernel.
> >
> > Graphics mode selection is now done differently to avoid regression
> > caused by r327058 while still achieving the same effect. The observed
> > regression was that the kernel would usually end up drawing
> > incorrectly at the old resolution on a subset of the screen, due to
> > incorrect framebuffer information.
> >
> > Explicit testing of these changes, the latest of which happened in
> > r331326, and any feedback from this testing would be greatly
> > appreciated. Testing should be done with either `options EFIRT` in
> > your kernel config or efirt.ko loaded along with updated bootloader
> > bits.
> >
> > I otherwise plan to MFC commits involved with the above-mentioned
> > changes by sometime in the first week of April, likely no earlier than
> > two (2) weeks from now on April 4th.
> >
> > Thanks,
> >
> > Kyle Evans
>
> As partially promised, the non-graphics related changes have been
> MFC'd to stable/11 today as r332028.
>
> The graphics related changes are going to simmer longer and probably
> get ripped out, because we're bad at this.
>
> Thanks,
>
> Kyle Evans
> _______________________________________________
> 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"
>