The default state of this server is that FreeBSD hangs when booting off UEFI
and the COM ports are enabled. That seems to be because console includes or
adds "efi" by default. Under every circumstance I've tested, when console
contains "efi", the server hangs at th
I have a Quanta D52B-1U server. When I boot it via legacy BIOS, there is no
issue. When I boot with UEFI and COM ports & console redirection disabled,
there is no issue. However, when boot UEFI and enable the COM ports and/or
console redirection, the server hangs at boot time right
improvements of ACPI detection (e0f3dc82727f
> > and 0b01d45783c3) would leave the system in an unbootable state if
> the
> > UEFI files are not being updated at the same time of "make
> > installworld". At early boot the kernel would panic with:
>
On 2023-11-20 19:33, Warner Losh wrote:
On Mon, Nov 20, 2023 at 6:21 PM Xin Li <mailto:delp...@delphij.net>> wrote:
Hi,
It seems that the recent improvements of ACPI detection (e0f3dc82727f
and 0b01d45783c3) would leave the system in an unbootable state if the
UEFI
On Mon, Nov 20, 2023 at 6:21 PM Xin Li wrote:
> Hi,
>
> It seems that the recent improvements of ACPI detection (e0f3dc82727f
> and 0b01d45783c3) would leave the system in an unbootable state if the
> UEFI files are not being updated at the same time of "make
> installwor
state if the
> UEFI files are not being updated at the same time of "make
> installworld". At early boot the kernel would panic with:
>
> panic: running without device atpic requires a local APIC on UEFI systems
>
> To recover a system in this state, at loader prompt, us
Hi,
It seems that the recent improvements of ACPI detection (e0f3dc82727f
and 0b01d45783c3) would leave the system in an unbootable state if the
UEFI files are not being updated at the same time of "make
installworld". At early boot the kernel would panic with:
panic: runni
<https://reviews.freebsd.org/D31121>
Amongst the related bug reports,
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821#c48>:
* suspects some kind of "special behaviour" with ASUS UEFI
* also observes a regression in FreeBSD.
Given other related bugs,
With Toomas's help (thanks!), I was able to partially resolve the hang
and blank screen at boot issue, for the record, for now this can be
solved by adding:
screen.font="16x32"
in /boot/loader.conf; no more efi_max_resolution setting is needed.
Setting allscreen_flags to load font still panics t
Hi,
It seems that some recent change after 282381aa53a would prevent my
laptop (Lenovo P51, with 4k LCD) from booting.
I have made some attempt to find out why, so far, it seems that setting
efi_max_resolution="480p" or efi_max_resolution="720p" would allow it to
boot to single user mode.
Unfort
Hi!
I am trying to migrate from 12/stable to main@163f4f1573
and after system (world + kernel + bootloaders) update
UEFI does not work: it reads loader.conf, but a bit strange:
- logo is off - OK
- font colour does not change - not OK
then black screen, no connect via ssh, after h/w reset - no
The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.
Non-debug kernels built for cortex-A72 and for cortex-A53 both got the
behavior that leads mount root failure. (This tends to eliminate some types
Does it boot when you copy loader.efi to bootx64.efi?
Toomas
> On 23. Oct 2020, at 05:02, Jan Beich wrote:
>
> After r366657 (currently, on r366953) I've tried to boot from a
> compression=zstd dataset but it failed to reach loader(8), see below.
> However, switching to CSM path (boot1.efi ->
Toomas Soome writes:
>
>> On 23. Oct 2020, at 05:02, Jan Beich wrote:
>>
>> After r366657 (currently, on r366953) I've tried to boot from a
>> compression=zstd dataset but it failed to reach loader(8), see below.
>> However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work.
>>
>>
After r366657 (currently, on r366953) I've tried to boot from a
compression=zstd dataset but it failed to reach loader(8), see below.
However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work.
Am I missing something?
$ strings /boot/boot1.efi | fgrep zstd
org.freebsd:zstd_compress
$
On 03/09/2020 10:01, Dave Cottlehuber wrote:
> On Thu, 3 Sep 2020, at 06:48, Andriy Gapon wrote:
>> On 03/09/2020 00:01, Navdeep Parhar wrote:
>>> Load cryptodev manually from the loader to boot and then add
>>> cryptodev_load="YES" to your loader.conf.
>>
>> I think that this shouldn't be needed *
On Thu, 3 Sep 2020, at 06:48, Andriy Gapon wrote:
> On 03/09/2020 00:01, Navdeep Parhar wrote:
> > Load cryptodev manually from the loader to boot and then add
> > cryptodev_load="YES" to your loader.conf.
>
> I think that this shouldn't be needed *if* zfs module has a dependency on
> cryptodev mo
On 03/09/2020 00:01, Navdeep Parhar wrote:
> Load cryptodev manually from the loader to boot and then add
> cryptodev_load="YES" to your loader.conf.
I think that this shouldn't be needed *if* zfs module has a dependency on
cryptodev module (MODULE_DEPEND in the code).
The loader knows how to load
On Wed, 2 Sep 2020, at 21:01, Navdeep Parhar wrote:
> Load cryptodev manually from the loader to boot and then add
> cryptodev_load="YES" to your loader.conf.
Hi Navdeep
that was it - thanks! crisis averted.
A+
Dave
—
O for a muse of fire, that would ascend the brightest heaven of invention!
___
Load cryptodev manually from the loader to boot and then add
cryptodev_load="YES" to your loader.conf.
Regards,
Navdeep
On 9/2/20 1:58 PM, Dave Cottlehuber wrote:
> hi Matt, Ryan
>
> Something goes awry after loading kernel & zfs drivers, at point of mounting
> the root filesystem from boot env
hi Matt, Ryan
Something goes awry after loading kernel & zfs drivers, at point of mounting
the root filesystem from boot env - unknown filesystem.
Running ? to show available fs doesn't show zfs here, but as we loaded kernel
already from zfs this is confusing.
Any ideas?
mountroot> ?
List of
Bitrate Retr
[ 5] 0.00-10.23 sec 1.09 GBytes 914 Mbits/sec 498 sender
iperf Done.
For reference, the RPi4B's CortextA72 is speed controlled via:
over_voltage=6
arm_freq=2000
in the RPi4's config.txt . As stands UEFI is configured to
impose a 3 GiByte RAM limi
f it is a bug in our code or theirs.freebsd.org
<http://theirs.freebsd.org>"
As I've said before, at least under bhyve it's a bug in the UEFI
firmware that we currently use.
Is that fixed in the -devel version? I think I missed you saying this
in the past...
before, at least under bhyve it's a bug in the UEFI
> firmware that we currently use.
>
Is that fixed in the -devel version? I think I missed you saying this in
the past...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.o
On 6/22/2020 10:12 AM, Warner Losh wrote:
I believe so. However, I've not dived deeply enough into this problem to
understand if it is a bug in our code or theirs.freebsd.org"
As I've said before, at least under bhyve it's a bug in the UEFI
firmware that we currently use.
From: Warner Losh
Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
Date: Mon, 22 Jun 2020 10:12:47 -0600
> I believe so. However, I've not dived deeply enough into this problem to
> understand if it is a bug in our code or theirs.
I got it. Thank yo
On Mon, Jun 22, 2020 at 9:40 AM Yasuhiro KIMURA wrote:
> From: Warner Losh
> Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
> Date: Mon, 22 Jun 2020 08:57:24 -0600
>
> > Does setting the tunable hw.efi.poweroff=0 help you?
>
> I add it to /b
From: Warner Losh
Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
Date: Mon, 22 Jun 2020 08:57:24 -0600
> Does setting the tunable hw.efi.poweroff=0 help you?
I add it to /boot/loader.conf and then `shutdown -p now` successfully
powers off system.
Does existence
> On 22. Jun 2020, at 16:57, Warner Losh wrote:
>
> On Mon, Jun 22, 2020 at 4:14 AM Yasuhiro KIMURA wrote:
>
>> From: Yasuhiro KIMURA
>> Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
>> Date: Mon, 22 Jun 2020 16:45:23 +0900 (JST)
&g
On Mon, Jun 22, 2020 at 4:14 AM Yasuhiro KIMURA wrote:
> From: Yasuhiro KIMURA
> Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
> Date: Mon, 22 Jun 2020 16:45:23 +0900 (JST)
>
> > I tried bisect and found this problem happens with r342108 and
From: Yasuhiro KIMURA
Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
Date: Mon, 22 Jun 2020 16:45:23 +0900 (JST)
> I tried bisect and found this problem happens with r342108 and
> after. Commit message of r342108 says as following.
>
> yasu@rolling-vm-f
From: Yasuhiro KIMURA
Subject: `shutdown -p now` fails to power off with VirtualBox UEFI boot
Date: Fri, 19 Jun 2020 05:23:48 +0900 (JST)
> I have VirtualBox VM running 13-CURRENT. In order to switch from
> legacy BIOS to UEFI I reinstalled OS by using
> FreeBSD-13.0-CURRENT-amd64
Olivier Cochard-Labbé wrote:
On Thu, Jun 18, 2020 at 10:26 PM Yasuhiro KIMURA wrote:
I have VirtualBox VM running 13-CURRENT. In order to switch from
legacy BIOS to UEFI I reinstalled OS by using
FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that
`shutdow -p now` (or select
On 6/21/20 12:37 AM, Olivier Cochard-Labbé wrote:
Same problem using FreeBSD current UEFI guests with bhyve, so it should
happen in any kind of hypervisor.
It is an old regression (in the sense of -current, so older than 6 months).
My idea was to generate very light UEFI VM images (because the
On Thu, Jun 18, 2020 at 10:26 PM Yasuhiro KIMURA wrote:
> I have VirtualBox VM running 13-CURRENT. In order to switch from
> legacy BIOS to UEFI I reinstalled OS by using
> FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that
> `shutdow -p now` (or select 'ACPI shu
I have VirtualBox VM running 13-CURRENT. In order to switch from
legacy BIOS to UEFI I reinstalled OS by using
FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that
`shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power
off. Shutdown itself completes success
On Wed, Jun 17, 2020 at 9:30 PM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:
> > This is what we have running in AWS right now, kinda proof of concept but
> > it's not that difficult to generalize:
> >
> > [root@ip-172-31-10-188 /usr/local/etc/freeswitch]# mdconfig -lv
> > md0 prel
party tools.
>
> Replace loading root from disk with loading it from HTTP server and it
> would work just as good with the only need to load 1 or two files.
I think your understating several of the stumbling blocks
that exist here. As Warner pointed out there are some
pokey sticks
So obviously we don't use the GENERIC kernel, but
I don't think we have any magic except in 4th files and loader.conf
and for the loader install command its all in the loader itself,
and I've been keeping head up todate on recent fixes/improvements there
since for UEFI I'm using
ines of code I think to generate this out of
buildworld/buildkernel. 0 third party tools.
Replace loading root from disk with loading it from HTTP server and it
would work just as good with the only need to load 1 or two files.
There is only one catch there - with real UEFI hardware sometimes there is
> > That's for normal boot, for the loader 'install' command
> > > it expects an uncompressed iso for rootfs.
> >
> > Ok, now the puzzle is how much work to get from a stock FreeBSD .iso
> > image to something that works with this. Obviously we need a n
; and that is taking a box stock linux distro, sticking it on a webserver
> and using PXE/HTTP booting to a running system. FreeBSD can not
> achieve that today WITHOUT some additional work. All that
> stuff like UFS snapshot, mkimg utlity, embeding the image is a ton
> of work compared t
On 6/17/20 2:11 PM, Rodney W. Grimes wrote:
Does freeBSD have any way to access these "Virtual Disk"
or Virtual CD images once we leave the world of the loader?
I believe we do not, as these are BIOS/UEFI devices that
require calls into the UEFI code, which, IIRC is gone
once we exit
uch work to get from a stock FreeBSD .iso
> image to something that works with this. Obviously we need a non-stock
> /boot/loader.conf file, or to type some commands manually at a loader
> prompt. I believe the stock GENERIC kernel has the md_root support
> for this already, so it may
>
> > On Jun 17, 2020, at 12:12 PM, Warner Losh wrote:
> >
> > I missed the start of this thread, so maybe I'm missing a key detail.
> > However, I thought UEFI didn't have a RAM-disk, per se, but that we could
> > load memory areas and pass that
> On Jun 17, 2020, at 12:12 PM, Warner Losh wrote:
>
> I missed the start of this thread, so maybe I'm missing a key detail.
> However, I thought UEFI didn't have a RAM-disk, per se, but that we could
> load memory areas and pass that into the kernel using freebsd-onl
y at a loader
> > prompt. I believe the stock GENERIC kernel has the md_root support
> > for this already, so it may not be that hard to do.
>
> So obviously we don't use the GENERIC kernel, but
> I don't think we have any magic except in 4th files and loader.conf
&g
On Wed, Jun 17, 2020 at 12:19 PM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:
> > On Wed, Jun 17, 2020 at 11:53 AM Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > > > Rodney W. Grimes wrote:
> > > > > > The "fake cd drive" is in the kernel, loader just copies the
> On Wed, Jun 17, 2020 at 11:53 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
>
> > > Rodney W. Grimes wrote:
> > > > > The "fake cd drive" is in the kernel, loader just copies the iso into
> > > > > memory like any other module, and by the time that's done you just
> > > > > rebo
On Wed, Jun 17, 2020 at 12:06 PM Rebecca Cran wrote:
>
> > On Jun 17, 2020, at 11:40 AM, Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > Does FreeBSD kernel have a driver that can talk to the UEFI ramdisk?
>
> I’m fairly sure UEFI gener
On Wed, Jun 17, 2020 at 11:53 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:
> > Rodney W. Grimes wrote:
> > > > The "fake cd drive" is in the kernel, loader just copies the iso into
> > > > memory like any other module, and by the time that's done you just
> > > > reboot into the ne
> On Jun 17, 2020, at 11:40 AM, Rodney W. Grimes
> wrote:
>
> Does FreeBSD kernel have a driver that can talk to the UEFI ramdisk?
I’m fairly sure UEFI generates it as a standard CD drive.
—
Rebecca Cran
___
freebsd-current@freebsd
> On Tue., Jun. 16, 2020, 8:35 a.m. Rodney W. Grimes, <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
>
> > > I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
> > > what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
> > >
> > > I'm curious if it should be possible t
> Rodney W. Grimes wrote:
> > > The "fake cd drive" is in the kernel, loader just copies the iso into
> > > memory like any other module, and by the time that's done you just
> > > reboot into the newly installed system, which again uses
> > >
> > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> >
directly (I
> > tried to use the img.xz unpacked it and make it available on a local web
> > server and that didn't seem to work for me) but maybe thats cause those
> > images miss something, so arm64 aside does that work for amd64? I.E. using
> > the bootonly.iso?
>
Rodney W. Grimes wrote:
> > The "fake cd drive" is in the kernel, loader just copies the iso into
> > memory like any other module, and by the time that's done you just
> > reboot into the newly installed system, which again uses
> >
> > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
>
npacked it and make it available on a local
>>> web
>>> > server and that didn't seem to work for me) but maybe thats cause
>>> those
>>> > images miss something, so arm64 aside does that work for amd64? I.E.
>>> using
>>> > the bo
but maybe thats cause those
>> > images miss something, so arm64 aside does that work for amd64? I.E.
>> using
>> > the bootonly.iso?
>>
>> Unfortunately HTTP boot only works as far as the kernel: UEFI fetches
>> loader.efi, the loader fetches and runs the
md64? I.E.
> using
> > the bootonly.iso?
>
> Unfortunately HTTP boot only works as far as the kernel: UEFI fetches
> loader.efi, the loader fetches and runs the kernel over HTTP -- and then
> you need to use NFS to mount the filesystem (or have a local root
> filesystem).
&
Rodney W. Grimes wrote:
> > Are you refering to something like:
> >
> > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> >
> > we boot that way all the time.
>
> What provides the cd9660 driver to FreeBSD? When you load the .iso
> over a network card, aka PXE/HTTP, the code that does that usually
> c
Rodney W. Grimes wrote:
> > I'm curious if it should be possible to point to a img/iso directly (I
> > tried to use the img.xz unpacked it and make it available on a local web
> > server and that didn't seem to work for me) but maybe thats cause those
> > images miss something, so arm64 aside doe
nd make it available on a local web
server and that didn't seem to work for me) but maybe thats cause those
images miss something, so arm64 aside does that work for amd64? I.E. using
the bootonly.iso?
Unfortunately HTTP boot only works as far as the kernel: UEFI fetches
loader.efi, the loa
> Rodney W. Grimes wrote:
> > > Are you refering to something like:
> > >
> > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> > >
> > > we boot that way all the time.
> >
> > What provides the cd9660 driver to FreeBSD? When you load the .iso
> > over a network card, aka PXE/HTTP, the code that doe
tware (freerdp) but for starters I just wanted to check if pointing
> > > > directly to a img/iso would work and that does not seem to be the case.
> > >
> > > I would strongly suggest use of NFS instead of trying to provide an
> > > ISO image, as you no longer
I don't think it needs the cdrom driver does it? UEF accepts a iso (since
2.5) has a http boot URI and that is mounted as a ramdisk via the http boot
driver itself (I think, this is all a bit new to me too :)
Most of the info I found on it is from tiano core:
https://github.com/tianocore/tianocor
the
> needed
> > > software (freerdp) but for starters I just wanted to check if pointing
> > > directly to a img/iso would work and that does not seem to be the case.
> >
> > I would strongly suggest use of NFS instead of trying to provide an
> > ISO image, as you no
> Rodney W. Grimes wrote:
> > > I'm curious if it should be possible to point to a img/iso directly (I
> > > tried to use the img.xz unpacked it and make it available on a local web
> > > server and that didn't seem to work for me) but maybe thats cause those
> > > images miss something, so arm64
memory on the
> client box, and with a pi4 your already memory contrained.
>
Thanks for the tips, but I was really looking for HTTP BOOT info no NFS,
that's why I replied to this thread.
I might look into that at some point if HTTP BOOT is not an option of
course, but this thread is ab
> I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
> what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
>
> I'm curious if it should be possible to point to a img/iso directly (I
> tried to use the img.xz unpacked it and make it available on a local web
> serv
I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see
what the state of HTTP BOOT is in FreeBSD, so I bumped into this!
I'm curious if it should be possible to point to a img/iso directly (I
tried to use the img.xz unpacked it and make it available on a local web
server and that
> On 14. Feb 2020, at 13:43, Yuri Pankov wrote:
>
> Hi Toomas,
>
> I was finally able to find the revision that has broken UEFI boot on VMware
> VMs, that is ESXi 6.7 and Workstation 15.x, for me at least -- VM simply
> powers off (sometimes with uninformative
On Mon, 16 Dec 2019 10:27+0200, Toomas Soome wrote:
> Also make sure you do have updated firmware.
1.22 is the latest one.
> r355347 by itself does not really look like it should cause infinite loop on
> normal input, but there we would need to check what we do get from keypress
> and then we
> On 16. Dec 2019, at 08:30, Trond Endrestøl
> wrote:
>
> On Sun, 15 Dec 2019 20:41+0100, Trond Endrestøl wrote:
>
>> I updated the loader.efi stored in the ESP of my laptop, Lenovo
>> ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try
>> out base/head r355441.
>>
>> As
On Sun, 15 Dec 2019 20:41+0100, Trond Endrestøl wrote:
> I updated the loader.efi stored in the ESP of my laptop, Lenovo
> ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try
> out base/head r355441.
>
> As soon as I press a button, say 2 or 3, the loader freezes.
> Ctrl+Alt+
I updated the loeader.efi stored in the ESP of my laptop, Lenovo
ThinkPad E590T (20NB), running boot firmware 1.22, as I wanted to try
out base/head r355441.
As soon as I press a button, say 2 or 3, the loader freezes.
Ctrl+Alt+Delete is being recognized.
I have tried loader.efi from the lates
> >>>
> >>> the other thing is the weird Lenovo handling of the UEFI vars. The only
> >> way to
> >>> boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
> >>> everything) was to set the loader's name to EFI/BOOT/BOOTx64.e
d back to default
settings. No effect.
I just downloaded the newest CURRENT mem stick and extracted both boot1.efi and
loader.efi and
installed those into the ESP as described, setting the efibootmgr env
accordingly. Still the
same error.
It seems that there is indeed no EFI/UEFI shell. There
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am Wed, 21 Aug 2019 22:29:29 +
greg@unrelenting.technology schrieb:
> August 22, 2019 12:23 AM, "O. Hartmann" wrote:
>
> > Am Wed, 21 Aug 2019 15:58:24 -0500
> > Karl Denninger schrieb:
> >
> >> I would see if you can get REFIND loaded and
On 2019-09-18 16:29, Yuri Pankov wrote:
> Yes, exactly, sorry for not mentioning it.
>
> ESXi version: 6.7.0
> ESXi build number: 13006603
Sorry, I've realized it's _not_ crashing when we call ExitBootServices
after all: it's just that we can't call printf after that point. I've
found it gets to
On 2019-09-18 18:36, Rebecca Cran wrote:
>
> So far, it looks to be a problem with the GetMemoryMap/ExitBootServices
> loop in bi_load_efi_data.
So, it's crashing when we call BS->ExitBootServices. Of course, the
problem isn't really _in_ that code (it hasn't changed since March), but
that's just
On 2019-09-18 16:29, Yuri Pankov wrote:
>
> Yes, exactly, sorry for not mentioning it.
>
> ESXi version: 6.7.0
> ESXi build number: 13006603
Thanks. I've been able to replicate the problem, and am currently
debugging it.
So far, it looks to be a problem with the GetMemoryMap/ExitBootServices
loo
Rebecca Cran wrote:
On 2019-09-18 09:01, Yuri Pankov wrote:
Any hints on debugging this further?
Are you running ESXi 6.7 Update 2? Or, what version of ESXi are you
using that has the problem?
Yes, exactly, sorry for not mentioning it.
ESXi version: 6.7.0
ESXi build number: 13006603
__
On 2019-09-18 09:01, Yuri Pankov wrote:
>
> Any hints on debugging this further?
Are you running ESXi 6.7 Update 2? Or, what version of ESXi are you
using that has the problem?
--
Rebecca Cran
___
freebsd-current@freebsd.org mailing list
https://list
Toomas Soome wrote:
On 18 Sep 2019, at 18:01, Yuri Pankov wrote:
I have tested several snapshot ISOs available for download:
FreeBSD-13.0-CURRENT-amd64-20190822-r351363-disc1.iso - OK
FreeBSD-13.0-CURRENT-amd64-20190829-r351591-disc1.iso - OK
FreeBSD-13.0-CURRENT-amd64-20190906-r351901-disc
> On 18 Sep 2019, at 18:01, Yuri Pankov wrote:
>
> I have tested several snapshot ISOs available for download:
>
> FreeBSD-13.0-CURRENT-amd64-20190822-r351363-disc1.iso - OK
> FreeBSD-13.0-CURRENT-amd64-20190829-r351591-disc1.iso - OK
> FreeBSD-13.0-CURRENT-amd64-20190906-r351901-disc1.iso - F
I have tested several snapshot ISOs available for download:
FreeBSD-13.0-CURRENT-amd64-20190822-r351363-disc1.iso - OK
FreeBSD-13.0-CURRENT-amd64-20190829-r351591-disc1.iso - OK
FreeBSD-13.0-CURRENT-amd64-20190906-r351901-disc1.iso - FAIL
FreeBSD-13.0-CURRENT-amd64-20190913-r352265-disc1.iso - FA
> On Aug 26, 2019, at 11:43 PM, Toomas Soome wrote:
>
> For me it is still confusing if this is path versus upper-lower capital
> chars.
>
> If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page
> 91), then the file name should also end with .
> On 27 Aug 2019, at 08:08, Warner Losh wrote:
>
> On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran <mailto:rebe...@bsdio.com>> wrote:
>
>> On 8/26/19 5:22 AM, O. Hartmann wrote:
>>
>>>
>>> the other thing is the weird Lenovo handling of
On 2019-08-26 23:08, Warner Losh wrote:
>
> That's the first machine I've seen where you have to set the name like
> that... there is a larger story here and we are getting incomplete reports
> because it doesn't quite make sense yet...
>
> But there are enough reasons not to do that by default. Fo
On Mon, Aug 26, 2019, 5:32 PM Rebecca Cran wrote:
> On 8/26/19 5:22 AM, O. Hartmann wrote:
>
> >
> > the other thing is the weird Lenovo handling of the UEFI vars. The only
> way to
> > boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
> > ev
On 8/26/19 5:22 AM, O. Hartmann wrote:
the other thing is the weird Lenovo handling of the UEFI vars. The only way to
boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding
everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi. Setting the
variable to contain EFI
ld need to start to insert more
> debug printouts and see what we will find. Once you are ready to go with it,
> you can poke me directly and then we can start…
>
> rgds,
> toomas
>
Hello.
I spent the weekend fiddling around with the settings and I found out two
things:
the mos
> On 22 Aug 2019, at 06:04, O. Hartmann wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Am Wed, 21 Aug 2019 22:29:29 +
> greg@unrelenting.technology schrieb:
>
>> August 22, 2019 12:23 AM, "O. Hartmann" wrote:
>>
>>> Am Wed, 21 Aug 2019 15:58:24 -0500
>>> Karl Denninger
August 22, 2019 12:23 AM, "O. Hartmann" wrote:
> Am Wed, 21 Aug 2019 15:58:24 -0500
> Karl Denninger schrieb:
>
>> I would see if you can get REFIND loaded and use that. I have a Lenovo
>> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
>> (e.g. Win10 and FreeBSD) easily.
t and EFI shell.
> >
> > I do not have a EFI shell on that type of laptop, not to know about
> > it. I can access the
> > firmware setup and already performed a reset and switched back to
> > default settings. No effect.
> >
> > I just downloaded the newest CURRENT mem
ds,
>>>>> oh
>>>
>>>
>>>> hm? efi shell should be available from boot device menu, so you
>>> mean, you can not even get
>>>> into firmware setup?
>>>
>>>> rgds,
>>>> toomas
>>>
>>>
t even get
> > > into firmware setup?
> >
> > > rgds,
> > > toomas
> >
> > Sorry,
> > I confused loader prompt and EFI shell.
> >
> > I do not have a EFI shell on that type of laptop, not to know about
> > it. I can access the
&g
on that type of laptop, not to know about
> it. I can access the
> firmware setup and already performed a reset and switched back to
> default settings. No effect.
>
> I just downloaded the newest CURRENT mem stick and extracted both
> boot1.efi and loader.efi and
> install
stop by and access the efi shell.
> > >
> > > Kind regards,
> > > oh
> >
> >
> > hm? efi shell should be available from boot device menu, so you mean,
> you can not even get
> > into firmware setup?
> >
> > rgds,
> > toomas
> >
able from boot device menu, so you mean, you can
> not even get
> into firmware setup?
>
> rgds,
> toomas
>
> >
> >>
> >>> On 21 Aug 2019, at 20:58, O. Hartmann wrote:
> >>>
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>>
1 - 100 of 605 matches
Mail list logo
