Maybe it’s just me, but putting an announcement of the availability of a
Release Candidate at the top of the NetBSD Home Page without having a link to
where it can be found seems highly inconvenient. Having to dig thru three or
four links and pages to find it doesn’t seem to be helpful in
I installed the latest version of NetBSD 10.0 BETA and tried to ssh into it
from an older system, in my case Mac OS X running 9.5 (Mavericks). I got an
error “no hostkey alg”. Never saw anything like this when I was running 9.2,
and I was able to ssh into the new system from another system
ert, Matthias,
>
> (taking current-users@ off Cc:)
>
>
> Thank you so much for your respective replies. Replying further inline
> below.
>
>>>>>> "bob" == Robert Nestor writes:
>
>bob> My experience with nvmm is limited and was mai
My experience with nvmm is limited and was mainly trying to use it on 9.x, but
I have the feeling that development on it has pretty much ceased and there’s
very little interest in improving it. I’ve been running a comparison
experiment seeing what it takes to get as many systems as possible
vt100 emulation)
[16.537588] no data for est. mode 640x480x67
[16.537588] wsdisplay0: screen 4 added (default, vt100 emulation)
[ 1544.481732] ehci0: missed microframe, TT reset not implemented, hub might
be inoperational
On Jan 5, 2023, at 7:02 AM, Martin Husemann wrote:
> On Thu,
023 at 02:07:04PM -0600, Robert Nestor wrote:
>> Be happy to try and provide more info if someone has suggestions.
>
> Is this the same machine as in https://gnats.netbsd.org/56737 ?
> As Rin asked there: we need the full dmesg output of the machine.
>
> Martin
The old problem of IDENTIFY failed and WDCTL_RST failed on the boot disk
doesn’t seem to be completely fixed in the current 10.0_BETA builds.
When I try to capture the boot output on a serial console it never seems to
show up, but when the boot output is sent to the main monitor it seems to
I’m in the process of installing 10.0_BETA on a system and I’ve seen some
transient errors which appear to be related.
If a disk contains GPT wedges that I want to destroy and replace with new ones
and I script the commands to do this, I often see errors indicating the disk
doesn’t contain the
I’ve had floppies that weren’t usable and couldn’t be formatted under Windows,
but would format and become usable under OS X. After that they were usable
under Windows and NetBSD, and could even be re-formatted under Windows. All
the systems used the same HW floppy disk which was a USB
d to execute a VCPU.
> [1] Abort trap (core dumped) qemu-system-x86_64 -accel nvmm -cpu max -smp
> c...
>
> Surfing on the net a little bit,I found an interesting post regarding shit
> specific bug :
>
> http://mail-index.netbsd.org/current-users/2020/08/24/msg039417.html
On Jun 18, 2021, at 3:43 PM, Chavdar Ivanov wrote:
> On Fri, 18 Jun 2021 at 19:36, Robert Nestor wrote:
>>
>> Playing with FreeDOS 1.2 and 1.3 under nvmm on a NetBSD 9.1-amd64 system and
>> ran into some issues. Basically I can do an install from the FreeDOS-1.2 CD
Playing with FreeDOS 1.2 and 1.3 under nvmm on a NetBSD 9.1-amd64 system and
ran into some issues. Basically I can do an install from the FreeDOS-1.2 CD
and run the system afterwards without an issue, but trying to install
FreeDOS-1.3 the same way aborts in nvmm. If the FreeDOS 1.3 install is
suggestions!
-bob
On Mar 3, 2021, at 8:53 AM, Greg Troxel wrote:
>
> Robert Nestor writes:
>
>> Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0: drive supports PIO mode
>> 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags)
>> Feb
using the same cable
where the spinning disk was, but I’ll try using a different cable and moving to
another controller to see if that helps.
-bob
On Mar 3, 2021, at 8:53 AM, Greg Troxel wrote:
>
> Robert Nestor writes:
>
>> Feb 26 09:50:59 amd64k /netbsd: [ 3.3392559] wd0:
I’m running NetBSD 9.1 on an amd64k system. Wanted to preserve some files from
an old Windows-XP system so I initialized a USB stick on Windows and copied the
files to it - well most of them. One file was too large to fit so the copy of
that file failed when it “ran of the end of the USB
I’m running NetBSD 9.1 on an amd64k system. When I run it on a spinning disk I
don’t see any errors, but when I install it on an SSD is see a lot of timeout
and write errors. Initially I thought it was a failing SSD as the one I’d
first used was quite old, so I bought a new Samsung 870.
similar results trying to boot CDs.
-bob
On Aug 7, 2020, at 12:10 PM, Chavdar Ivanov wrote:
> On Fri, 7 Aug 2020 at 14:21, Robert Nestor wrote:
>>
>> Thanks again! Your patience and suggestions have helped a lot and (I think)
>> I have a much better understanding of
for the UEFI boot files whereas the real implementation (on my PC at least) is
much more forgiving.
-bob
On Aug 7, 2020, at 7:02 AM, Chavdar Ivanov wrote:
> On Fri, 7 Aug 2020 at 12:54, Robert Nestor wrote:
>>
>> OK, I tried doing this with just the rEFInd CD and it still didn’t
fixed. I’m updating
my system and installed packages to verify that the issue is still there, and
if so, I’ll file a an issue with the qemu folks.
-bob
On Aug 7, 2020, at 7:44 AM, Martin Husemann wrote:
> On Fri, Aug 07, 2020 at 06:54:08AM -0500, Robert Nestor wrote:
>> OK, I tr
.
-bob
On Aug 7, 2020, at 2:58 AM, Chavdar Ivanov wrote:
> On Fri, 7 Aug 2020 at 02:35, Robert Nestor wrote:
>>
>> OK, thanks! I’m not sure I fully understand what you mean by “moved the
>> relevant file to the top”. Do you mean you moved the \EFI\boot\bootx64.efi
&g
the NetBSD CD booted. Doesn’t it’s
bootx64.efi file live in \EFI\boot\bootx64.efi just like it does on the rEFInd
CD?
-bob
On Aug 6, 2020, at 7:26 PM, Chavdar Ivanov wrote:
> On Fri, 7 Aug 2020 at 01:11, Chavdar Ivanov wrote:
>>
>> On Fri, 7 Aug 2020 at 01:05, Rober
-new \
>-net tap,fd=3 3<>/dev/tap1 \
>-net nic \
>-cdrom /iso/NetBSD-9.99.69-amd64.iso
>
>
> I was able to boot today's -current in efi mode, no problem.
> Obviously, I access the console over vnc.
>
> Chavdar
>
> On Thu, 6 Aug 2020 a
This helps a bit but still not quite there. Adding the “-device qemu-xhci
-device usb-tablet -machine q35” gets me to the BIOS menu screen, but even
after setting the boot device to the CDROM it still doesn’t boot up to the
rEFInd screen. Also adding “-accel mvmm” didn’t hurt but didn’t get
Something simple I must be missing here. I downloaded the CD image of rEFInd
from:
http://sourceforge.net/projects/refind/files/0.12.0/refind-cd-0.12.0.zip/download
Burned it to a CD and tried booting that CD on my PC. It doesn’t boot using
BIOS, but it does boot using UEFI. So I
As I recall there used to be a link to the mailing lists on the main web page
under the Support category along with the ones that are still listed on the new
web page. Finding the link to “Release engineering” used to be a treasure
hunt, but now it’s much easier with the link under Developers
obably want to change your print cap
file to send output to the POSTSCRIPT_P1 queue instead of the TEXT_P1 queue
since everything should be in Postscript format after applying this filter.
And of course you need to add the reference to the filter in your printcap file.
Hope this helps,
-bob
On Ju
Reading this thread it appears to me Ahi was booting up from NetBSD 8.0 on a
USB stick and then trying to install 9.0 on his hard drive. I’m not sure, but
that could be part of his problem. I seem to recall running into problems with
GPT partitioning and UEFI booting when I tried doing this
Not knocking the tremendous work Martin has done maintaining and extending the
Installer, but the GPT handling in 9.x/-current did seem a bit confusing to me.
It could be just me and my understanding, but the last time I tried it there
seemed to be a disconnect between the way an MBR disk is
I’m not sure if this is still true, but it was in the past.
The NetBSD installer used to get confused about partitioning if one was trying
to install a new NetBSD system on a disk that had previously contained an
installation of some other system like OpenBSD, FreeBSD or Linux. This was on
t; On Wed, 9 Oct 2019 at 16:47, Kamil Rytarowski wrote:
>>
>> On 09.10.2019 17:37, Robert Nestor wrote:
>>> Got a few systems installed and running under NVMM in NetBSD 9.0, but ran
>>> into this playing with a Windows installation. It appears to be coming
>>
Got a few systems installed and running under NVMM in NetBSD 9.0, but ran into
this playing with a Windows installation. It appears to be coming from NVMM
and I’m curious if this is a current limitation in NVMM or are there some QEMU
parameters which can be used to circumvent this.
NetBSD
:
> Once you get a grub menu, you need to specify 'noapic'.
>
> Linux runs aggressive hw checks that fail under hypervisors (NVMM is not
> to be blamed).
>
> The right solution is to patch the Linux kernel and disable the checks
> for NVMM and HAXM.
>
> On 08.10.2019
an installation CD
this way.
On Oct 8, 2019, at 9:40 AM, Kamil Rytarowski wrote:
> On 08.10.2019 16:31, Robert Nestor wrote:
>> Playing with nvmm in an Oct 9 NetBSD 9.0 build. Sucessfully installed
>> a version of NetBSD 8.0 but ran into problems tryuing to install a
>> LinuxMi
Playing with nvmm in an Oct 9 NetBSD 9.0 build. Sucessfully installed
a version of NetBSD 8.0 but ran into problems tryuing to install a
LinuxMint 19.2 64-bit system. Nvmm throws these errors:
qemu-system-x86_64: NVMM: Unexpected WRMSR 0x1c9 [val=0x3], ignored
qemu-system-x86_64: NVMM:
Confused about mvmm and NetBSD 9.0 BETA. I did build and install the version
of qemu-nvmm from pkgsrc-wip, then tried running it and it gives:
qemu-system-x86_64: NVMM: No accelerator found, error=6
qemu-system-x86_64: failed to initialize NVMM: No space left on device
I thought mvmm was in
I’m sure I’m doing something wrong, but don’t have a clue what it might be.
I downloaded the amd64 9.0_BETA ISO yesterday and burned it to a CD. Booted
the CD and attempted installation onto a disk that already has a GPT structure
set up with an earlier version of 9.0 on it. The disk was
A follow up for anyone else seeing the same problems with dbus, hal and avahi
starting up xfce4.
Finally isolated the problem to a build error in the packages using pkg_comp -
it doesn’t happen with builds done in a typical pbulk build environment. It
appears that when pkg_comp bootstraps its
otica# gpt biosboot -L bootroot wd1
=> xotica# newfs dk0
xotica# installboot /dev/rdk0 /usr/mdec/bootxx_ffsv1
xotica# mount /dev/dk0 /mnt
xotica# cp /usr/mdec/boot /mnt
On Feb 13, 2019, at 12:25 AM, John Nemeth wrote:
> On Feb 12, 7:03pm, Robert Nestor wrote:
> }
&
Somewhat related, but the man page on GPT in the example on how to set up a
BIOS boot indicates that one should newfs dk?, not rdk?. A number of people
have pointed out to me that I should be running newfs on rdk?, NOT dk?. This
was probably the source of a lot of my problems, but in my
I’ve noticed on my system that building packages is very much I/O bound rather
than CPU limited. So in an effort to try and speed things up I decided to
install a cheap SSD as a system disk. While doing that I noticed some things
and I wonder if they point to problems in NetBSD. I am using
Got a bit further on this problem. Tried a clean install of 8.0_STABLE and
downloading the packages from the 8.0 archives. Xfce comes up and allows me to
create terminal sessions and most functions seem to work, although I’m still
seeing the “funky mouse” and window move problems. There are
Interesting that others have seen the mouse and window move problem under xfce.
My system is an amd64 with Intel driver and I’m using X from the base
distribution.
I have been building the packages myself and using them for the installation
and I always do a clean system install of
I’m still trying to isolate the problem I’m seeing. Did notice that hal is no
longer dragged in when I install xfce4 from current or 2018Q4, so I’ve
eliminated it in my install. Avahi was being pulled in when I installed
seamonkey, so I’ve disabled it for the time being. Where I am now is
As suggested by David Gutteridge, I commented out the startup of the dbus, hal
and avahi daemons in rc.conf. When I did this, xfce4 came up and appeared to
be working. So that begs the question, why the install of xfce4 also installs
these daemons and why aren’t they working in 2018Q4 and
Running NetBSD 8.0_STABLE on an amd64 system using xfce4 and related packages
from pkgsrc-2017Q4 which has been working. But there are some minor nits, so
I’ve tried upgrading my installed packages to those found in either
pkgsrc-2018Q4 or -current. I see the same problem in both though;
I wonder if the absence of some packages in the archives (like gimp in 2018Q4)
are related to what I’m seeing in my builds. Some packages build successfully
as individual builds, but fail to build when part of a pbulk build. Both done
inside a sandbox.
The one I’m trying to figure out right
Did a clean checkout of pkgsrc-2018Q4 and tried building a few of the packages,
mainly xfce4. If fails, along with about 122 others in my build, because
perl-5.28.1 doesn’t build. but perl-5.28.1 is in the binary archives for
amd64/8.0_2018Q4 on the server. So it had to build for someone,
I’ve noticed inconsistencies with the pre-built package archives since about
the time of NetBSD 6.2. Whenever I’ve done a clean install of NetBSD (7.x ,
8.x or -current) and then try to install some packages from almost any
corresponding package archive, I usually run into issues with
Not sure if this is a NetBSD bug or a cockpit error on my part so some expert
guidance would be helpful.
I’ve got a system with two hard drives that I’ve installed NetBSD onto, using
both NetBSD-8.0 and NetBSD-8.0_STABLE. (Current doesn’t boot on this HP MT
6200 - that’s a different issue but
I’ve got one of those boxes and I did have NetBSD loaded on it not long after I
got it. I bought one with the minimal internal disk setup, two 120G Kingston
SSDs, and installed my own additional disk drives for more storage.
I was using an earlier version of NetBSD and bought it to set up some
ike that (open it up). I have one Linux instance
> running on it and its fine. I've installed NetBSD versions 3.0, 4.0.1, 5.0,
> 7.0 and 8.0 and they all have the same issue with the file systems.
>
> I'm not using Xen - just the standard install.
>
> -Original Messag
The screen auto-configure algorithm in X seems to change a bit with every new
update which, on my system, introduces this particular problem. What I’ve
noticed is that the algorithm tries to determine what graphics cards are
present, what resolutions are supported, etc then sometimes gets
I wasn’t sure if it was a pkgin issue or something else, but I have run into
this problem just installing packages using pkgin without having pkgsrc
installed. But if the solution is to run “make deinstall clean” in
devel/boost-headers, doesn’t that require that pkgsrc be installed on the
I’ve run into this a few times using pkgin. Not sure if it’s a problem with
pkgin or with the packages and their dependencies. What seems to work for me
is to remove the newer version of the package that it’s complaining about, then
retrying the installation. In you case, remove
Ah ha! I missed that root=dk1 part and I’ll bet with the little bit of magic I
should be up and running.
Thanks!
-bob
On Jun 23, 2018, at 12:27 PM, Robert Elz wrote:
>Date:Sat, 23 Jun 2018 11:29:25 -0500
>From: Robert Nestor
>Message-ID:
>
>
New oddity that I’ve stumbled over with 8.0_RC1. Got it all installed with GPT
partitions (wedge 1 is EFI, wedge 2 is root, wedge 3 is swap, etc). Boots up
and runs fine, so I moved to the next step and install xen. But when I try to
boot up it insists that root is on the first wedge
I thought I’d try putting my /home filesystem on a NAS box, so I’ve added the
line “critical_filesystems_remote=“OPTIONAL:/home” to /etc/rc.conf but when the
system boots up the logs show:
[running /etc/rc.d/mountcritremote]
[running /etc/rc.d/sysdb]
Building databases: devdev_mkdb: not found
,
After three weeks of struggling with this I posted the previous message and as
Murphy would dictate, as soon as I posted I found what I think is causing the
problem. Seems I had a flaky setup on my internet connection. When I have a
solid connection XSM comes up normally as I’d expect; with
Still playing with installation of NetBSD 8.0_RC1 (from 201806180740Z and
earlier) and have noticed some strange oddities.
I’ve installed the basic system on a disk using both the original/traditional
disk partition layout and on a disk with a GPT disk partition layout.
The /boot.cfg file is
While digging further into this I discovered that the UEFI install images boot
up in Legacy BIOS mode, not in UEFI mode. Disabling Legacy BIOS boot on my
system before trying to boot the install image resulted in not being able to
boot up at all. So even though the image contains and EFI
60 matches
Mail list logo
