On 11/04/2018 11:53, Lucas Holt wrote:
Machines don’t need to be old to have issues. I have a two year old asus am3+
board that cant boot from gpt without secure boot enabled and is hard coded for
Microsoft keys
Lucas Holt
Interesting. Not sure Clover would help there though, secure boot is
Machines don’t need to be old to have issues. I have a two year old asus am3+
board that cant boot from gpt without secure boot enabled and is hard coded for
Microsoft keys
Lucas Holt
> On Apr 11, 2018, at 12:04 PM, Ryan Stone wrote:
>
>> On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrot
On 11/04/2018 11:04, Ryan Stone wrote:
On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote:
Hi;
FWIW, I use a very old PC of the type where the processor will not be fixed
by Intel and that still needs support for the traditional BIOS. I also
bought a 3TB HD (they were easier to find that
On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote:
> Hi;
>
> FWIW, I use a very old PC of the type where the processor will not be fixed
> by Intel and that still needs support for the traditional BIOS. I also
> bought a 3TB HD (they were easier to find that 2T).
>
> If I leave the disk dedica
Hi;
FWIW, I use a very old PC of the type where the processor will not be
fixed by Intel and that still needs support for the traditional BIOS. I
also bought a 3TB HD (they were easier to find that 2T).
If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB
and will happily
On Thu, Apr 5, 2018 at 7:23 PM, Zaphod Beeblebrox wrote:
> 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 driv
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 st
On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans 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 ser
If you're thinking on it, you should know that the DVD version works. The
difference, AFAICT, is that it simply calls loader.efi directly. Ie:
bootx64.efi is loader.efi, not boot1.efi.
Loader.efi doesn't seem to change the screen mode when it starts. When the
kernel starts afterwards, this all
On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans wrote:
> Hi,
>
> Right- so, `gop set 0` should've immediately cleared your screen and
> put it into 1920x1080, full stop. If it did not, I think that's
> indicative of some kind of interestingly broken firmware...
>
> Regardless! We're clearly bad at tryi
Hi,
Right- so, `gop set 0` should've immediately cleared your screen and
put it into 1920x1080, full stop. If it did not, I think that's
indicative of some kind of interestingly broken firmware...
Regardless! We're clearly bad at trying to set a mode before the
kernel starts, so r331904 sets the
I did as you asked. You can see the result at:
https://owncloud.towernet.ca/s/6K3pGknCyGTi7du
... but the long and short of it is that even though the loader is printing
in the center of the screen (text mode?), it sees the 1920x1080 mode as the
"mode 0" ... I even tried "gop set 0" ... which it
On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox wrote:
> On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet
> wrote:
>>
>> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso
>>
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694
>>
>> On Mon, Apr 2, 2018 at 12:38 AM, Tomoak
I've booted that image on my zbook 15. I show in the boot that I can
deliberately load efirt.ko ... and it doesn't help. I also show that I can
"type blind" after the system boots ... so everything but the screen is
working.
In case you can't quite make it out, I hit right cursor twice (move to
On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI wrote:
> Confirmed both loader (with boot1) part and efirt.ko part.
> Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
>
> No benefit (VGA resolution) but no new harm (no panic nor silent
> reboot).
>
> *Maybe gracefully falling back to mode
Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694
On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI
wrote:
> Confirmed both loader (with boot1) part and efirt.ko part.
> Working OK on my ThinkPad420 (with nvidia GPU) at r331864
Confirmed both loader (with boot1) part and efirt.ko part.
Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
No benefit (VGA resolution) but no new harm (no panic nor silent
reboot).
*Maybe gracefully falling back to mode 0.
As I'm on x11/nvidia-driver, completely no test is done with
On 2018-03-25 14:52, Sheda wrote:
>>
>> I've tested on two different computers, my ThinkPad x230 and my desktop
>> with a Intel DQ77MK motherboard. I've only done light testing such as
>> loading efirt.ko and running efibootmgr to check the boot settings, but it
>> has worked fine.
>> I also haven
>
> I've tested on two different computers, my ThinkPad x230 and my desktop
> with a Intel DQ77MK motherboard. I've only done light testing such as
> loading efirt.ko and running efibootmgr to check the boot settings, but it
> has worked fine.
> I also haven't seen any issues with console graphics
On 03/22/18 01:45, Kyle Evans 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 w
On Thu, Mar 22, 2018 at 11:56 AM, Renato Botelho wrote:
> On 21/03/18 21:45, Kyle Evans 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 servi
On 21/03/18 21:45, Kyle Evans 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-
On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote:
> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
>> Hi.
>> For problem 2, try reverting r331241 alone.
>> This worked for my ThinkPad T420.
>
>
> I also hit this after updating to latest and was about to post when I
> saw this thread -
>
> I build efirt
On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans wrote:
> On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei wrote:
>> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
>>> Hi.
>>> For problem 2, try reverting r331241 alone.
>>> This worked for my ThinkPad T420.
>>
>>
>> I also hit this after updating to latest and w
On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> Hi.
> For problem 2, try reverting r331241 alone.
> This worked for my ThinkPad T420.
I also hit this after updating to latest and was about to post when I
saw this thread -
I build efirt into the kernel and it's now doing a panic on boot. It
appears to
Hi.
For problem 2, try reverting r331241 alone.
This worked for my ThinkPad T420.
On Thu, 22 Mar 2018 08:22:13 -0500
Kyle Evans wrote:
> On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote:
> > Hi!
> >
> >
> > Just updated to r331345.
> >
> > Two problems:
> >
> > 1. boot/efi.4th is added t
On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark wrote:
> Hi!
>
>
> Just updated to r331345.
>
> Two problems:
>
> 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in
> loader.rc. Loader fails to load it and subsequently fails to load modules.
> Reinstalling efi.4th proble
On Thu, Mar 22, 2018 at 6:09 AM, M&S - Krasznai András
wrote:
>> -Eredeti üzenet-
>> Feladó: owner-freebsd-curr...@freebsd.org
>> [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Toomas Soome
>> Küldve: 2018. március 22. 11:52
>> Címzett: Free
-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Toomas Soome
Küldve: 2018. március 22. 11:52
Címzett: FreeBSD Current
Tárgy: Re: Call for Testing: UEFI Changes
> On 22 Mar 2018, at 12:13, Jakob Alvermark wrote:
>
> Hi!
>
>
> Just updated to
> On 22 Mar 2018, at 12:13, Jakob Alvermark wrote:
>
> Hi!
>
>
> Just updated to r331345.
>
> Two problems:
>
> 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in
> loader.rc. Loader fails to load it and subsequently fails to load modules.
> Reinstalling efi.4th
Hi!
Just updated to r331345.
Two problems:
1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still
included in loader.rc. Loader fails to load it and subsequently fails to
load modules. Reinstalling efi.4th problem 2 appears.
2. Fixing problem 1 and adding efirt_load="YES" to /bo
31 matches
Mail list logo
