On Thu, Dec 12, 2019 at 07:54:08AM +0100, Martin Husemann wrote:
> On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote:
> > in efi with gpt; it performs the installation lege artis, but then the
> > boot fails - the efi file tries and fails to find netbsd, nebsd.gz,
> > onetbsd etc...
>
On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote:
> in efi with gpt; it performs the installation lege artis, but then the
> boot fails - the efi file tries and fails to find netbsd, nebsd.gz,
> onetbsd etc...
That sounds like a regression in bootx64.efi, checking
Martin
On 11.12.2019 23:32, Valery Ushakov wrote:
On Wed, Dec 11, 2019 at 23:15:38 +0100, Bodie wrote:
FYI https://www.virtualbox.org/ticket/19146
Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not
subscribed to list.
CPUID values are ... = guest (host):
IBRS_IBPB -
Updating src tree:
P src/lib/libkvm/kvm_proc.c
P src/share/man/man4/man4.macppc/platinumfb.4
P src/share/man/man9/condvar.9
P src/sys/arch/amd64/amd64/netbsd32_machdep.c
P src/sys/arch/amd64/amd64/netbsd32_machdep_16.c
P src/sys/arch/arm/dts/rk3328-rock64.dts
P src/sys/arch/arm/dts/rk3328.dtsi
P
So for various reasons I had recently pulled an old macbook2,1 off the
shelf and booted it up, and today I thought I'd try booting NetBSD on it
just to see how well it works with NetBSD and vice versa.
I built all the various "image" files, including a live image and the
uefi-install image, from
Hi,
I tested the the keyboard before and after pull-up. Indeed, it
actually changed the behavior, results of testing were the following:
* Before the pull up keyboard worked in 6KRO mode only. Switching to
NKRO was failing to attach the keyboard with the message "ukbd1:
attach failed, too many
Just to confirm the same. I still have a NetBSD EFI VirttualBox guest
working just fine, built around 9.99.10 or thereabouts, perhaps
following the manual installation procedure mentioned above. Upon
seeng this thread, I tried to test the installation of a fresh 9.99.21
in efi with gpt; it
Hi all,
FYI https://www.virtualbox.org/ticket/19146
Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not
subscribed to list.
On Wed, Dec 11, 2019 at 04:29:41PM +0100, Thomas Klausner wrote:
>
> So it looks like radeondrmkmsfb does not (correctly) detect the active
> output(s)?
Looks like it. There is lots of heuristics in that field.
--
Michael van Elst
Internet: mlel...@serpens.de
On Wed, Dec 11, 2019 at 01:34:27PM -0500, Ron Georgia wrote:
> Thanks for responding Martin. Actually I did both. Selecting GPT did set
> things up but it does not boot.
OK, it worked for me when I tried last (but that is a bit ago).
Does the UEFI offer the installed drive as a bootable target?
Thanks for responding Martin. Actually I did both. Selecting GPT did set
things up but it does not boot.
On 12/11/19 1:31 PM, Martin Husemann wrote:
On Wed, Dec 11, 2019 at 01:28:31PM -0500, Ron Georgia wrote:
I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with
GhostBSD as
On Wed, Dec 11, 2019 at 01:28:31PM -0500, Ron Georgia wrote:
> I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with
> GhostBSD as a host. I enabled EFI and booted from the iso image. I did
> follow the "instructions" on creating a gpt partition for efi
I guess you followed the
This feels like this question has been asked before, but I could not
find what I was looking for in the mailing list archives.
I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with
GhostBSD as a host. I enabled EFI and booted from the iso image. I did
follow the
On Mon, Dec 02, 2019 at 11:35:18PM +0100, Michael van Elst wrote:
> On Mon, Dec 02, 2019 at 05:58:44PM +0100, Thomas Klausner wrote:
>
> > The kernel dmesg now says:
> >
> > radeondrmkmsfb0: framebuffer at 0xdc0909ca8000, size 1920x1080, depth
> > 32, stride 7680
> >
> > but I don't get a
2019年12月11日(水) 22:54 Patrick Welche :
>
> On Wed, Dec 11, 2019 at 09:44:23PM +0900, Tomohiro Kusumi wrote:
> > https://github.com/NetBSD/src/commit/50df35e2463781823f58628fcce2de6f468b9d2c#diff-d90e1b7e3737158f5dfc517594eb88bdL382
> >
> > In above commit, can you try moving back the
On Wed, Dec 11, 2019 at 09:44:23PM +0900, Tomohiro Kusumi wrote:
> https://github.com/NetBSD/src/commit/50df35e2463781823f58628fcce2de6f468b9d2c#diff-d90e1b7e3737158f5dfc517594eb88bdL382
>
> In above commit, can you try moving back the "cleanup_exit:" location
> to before
https://github.com/NetBSD/src/commit/50df35e2463781823f58628fcce2de6f468b9d2c#diff-d90e1b7e3737158f5dfc517594eb88bdL382
In above commit, can you try moving back the "cleanup_exit:" location
to before prop_dictionary_copyout_ioctl() and try again ?
Basically 1 loc change.
2019年12月11日(水) 20:44
Taking a working 6 Dec 9.99.19/amd64 box, I see:
# /etc/rc.d/lvm onestart
Configuring lvm devices.
File descriptor 3 () leaked on lvm invocation. Parent PID 687:
File descriptor 3 () leaked on lvm invocation. Parent PID 687:
Activated Volume Groups: vg0
Updating kernel and modules to today's
Hello
Sorry for the incident : my commit on multiboot support for amd64
broke biosboot. The offending change was
sys/arch/amd64/conf/kern.ldscript 1.27-1.28
I reverted it in
sys/arch/amd64/conf/kern.ldscript 1.28-1.29
amd64 biosboot should work again with 1.29.
--
Emmanuel Dreyfus
19 matches
Mail list logo
