On Dec 25, 2022, at 15:55, Warner Losh wrote:
> Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a bogus if
> MACHINE_ARCH == "amd64" somewhere.
Well, seems more is missing for aarch64 if devd hyperv is to be enabled:
# grep -r MK_HYPERV /usr/main-src/ | more
Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a bogus
if MACHINE_ARCH == "amd64" somewhere.
Warner
On Sun, Dec 25, 2022, 4:28 PM Mark Millard wrote:
> From the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
> system:
>
> . . .
> Starting devd.
> genet0: link state
From the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
system:
. . .
Starting devd.
genet0: link state changed to UP
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Starting dhclient.
. . .
This seems to be from /etc/devd/hyperv.conf :
notify 10 {
match "system"
On 2021-May-5, at 05:28, Mark Millard wrote:
> On 2021-May-5, at 02:47, Andriy Gapon wrote:
>
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME USED AVAIL REFER MOUNTPOINT
>>> . . .
>>>
On 2021-May-5, at 02:47, Andriy Gapon wrote:
> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME USED AVAIL REFER MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G
On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G -
ad
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
Not exactly an obvious error message for the issue.
===
In FreeBSD 13.0 when I update the kernel and world I receive the following
error message during mergemaster:
ka-freebsd:/usr/src# mergemaster
*** Creating the temporary root environment in /var/tmp/temproot
*** /var/tmp/temproot ready for use
*** Creating and populating directory structure
On Mon, Jan 13, 2014 at 8:22 PM, Glen Barber g...@freebsd.org wrote:
On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
So, now when I run pkg I get the following:
pkg: Ignoring bad configuration entry in
/usr/local/etc/pkg/repos/FreeBSD.conf: URL:
So, now when I run pkg I get the following:
pkg: Ignoring bad configuration entry in /usr/local/etc/pkg/repos/FreeBSD.conf:
URL: http://pkg.freebsd.org/${ABI}/latest;
pkg: Ignoring bad configuration entry in /usr/local/etc/pkg/repos/FreeBSD.conf:
true
pkg: Ignoring bad configuration entry in
On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
So, now when I run pkg I get the following:
pkg: Ignoring bad configuration entry in
/usr/local/etc/pkg/repos/FreeBSD.conf: URL:
http://pkg.freebsd.org/${ABI}/latest;
pkg: Ignoring bad configuration entry in
Glen Barber wrote this message on Mon, Jan 13, 2014 at 23:22 -0500:
On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
So, now when I run pkg I get the following:
pkg: Ignoring bad configuration entry in
/usr/local/etc/pkg/repos/FreeBSD.conf: URL:
Hi!
In the thread
http://lists.freebsd.org/pipermail/freebsd-current/2013-August/043926.html
someone stumbled upon a not very helpful error message from:
# route get
The error message is strange/misleading:
route: writing to routing socket: Invalid argument
The patch in
http
Thanks for all the helpful suggestions.
csup worked like a charm and solved the problem. I will be rebuilding my
ports gradually, starting with the development ports like Perl, gcc,
clang etc.
I am also experimenting with a custom kernel where I am eliminating
drivers and modules for isa,
Niclas Zeising wrote:
On 2010-09-23 04:29, Ralph Ellis wrote:
Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and doc
update by cvsup but now I am getting the following error message when I
do a src
the following error message when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to the mailing list. Is this a known error?
Is this an error to do with the source tree or an issue on my end
and doc
update by cvsup but now I am getting the following error message
when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to the mailing list. Is this a known error?
Is this an error
W dniu 2010-09-23 14:02, Bartosz Stec pisze:
I am using cvsup. I had recompiled my VirtualBox port but I had not
finished recompiling the other major ports. Thanks for the suggestion.
My make.conf is deliberately very plain jane with no special conditions
or comments.
Thanks
Ralph Ellis
was able to one general ports, src
and doc
update by cvsup but now I am getting the following error message
when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to the mailing list
buildworld and buildkernel. I was able to one general ports, src
and doc
update by cvsup but now I am getting the following error message
when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new
Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and
doc update by cvsup but now I am getting the following error message
when I do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
On 2010-09-23 04:29, Ralph Ellis wrote:
Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and doc
update by cvsup but now I am getting the following error message when I
do a src update.
cvsup
is the following message serious ?
Mar 10 21:49:17 multi kernel: witness_get: witness exhausted
is there anything special to do ?
this is on a newly cvsuped, very lightly loaded, -Current (4 minutes
after booting the machine)
TfH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
... there are so many people testing
it that it's getting tired!
8-).
Actually, you need to look at where the error message is
generated, which will tell you that it's running out of
the things returned by witness_get. Then increase the
compile time constant that controls them, and you won't
run out any more
I've done two make worlds and can't seem to get rid of the following
error... I had it on my home system, but didn't log what I did to
correct it...
I just upgraded a 4.0-CURRENT (from around Jan 26) to the 4.0-STABLE
from yesterday.
when running pstat -s I get the following:
pstat: undefined
On 2 Feb, Kenneth D. Merry wrote:
I'm using this hardware since 2 years now and it's the first time I see
this (the computercase isn't opened for 2 months now, so nothing changed
recently). Is this something I should worry about?
This is likely a cabling or termination problem. It could
Hi,
today I've got
(da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 44,
SEQADDR == 0x113
(da0:ahc0:0:0:0): BDR message in message buffer
(da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 54,
SEQADDR == 0x113
(da0:ahc0:0:0:0): no
On Wed, Feb 02, 2000 at 13:06:36 +0100, Alexander Leidinger wrote:
Hi,
today I've got
(da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 44,
SEQADDR == 0x113
(da0:ahc0:0:0:0): BDR message in message buffer
(da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in
May 27 23:39:23 p100 /kernel: vnode_pager: *** WARNING *** stale FS getpages
May 27 23:39:23 p100 /kernel: No strategy for buffer at 0xc13637e0
May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4,
writecount 0,
refcount 0, flags (VOBJBUF)
May 27 23:39:23 p100 /kernel: tag
As Bruce Evans wrote ...
May 27 23:39:23 p100 /kernel: vnode_pager: *** WARNING *** stale FS getpages
May 27 23:39:23 p100 /kernel: No strategy for buffer at 0xc13637e0
May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4,
writecount 0,
refcount 0, flags (VOBJBUF)
May 27
As Matthew Dillon wrote ...
:etc
:
:This was during a cp -R /* /mnt where /mnt is a SCSI disk I'm testing.
:Both disks are on seperate SCSI buses. Is this because the cp -R
:tries to copy /proc ??
:
:| / o / / _Arnhem, The Netherlands- Powered by FreeBSD -
:|/|/ / / /(
Hi
My P100 testbox running a fairly recent current just said:
May 27 23:39:23 p100 /kernel: vnode_pager: *** WARNING *** stale FS getpages
May 27 23:39:23 p100 /kernel: No strategy for buffer at 0xc13637e0
May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4,
writecount 0,
:etc
:
:This was during a cp -R /* /mnt where /mnt is a SCSI disk I'm testing.
:Both disks are on seperate SCSI buses. Is this because the cp -R
:tries to copy /proc ??
:
:| / o / / _ Arnhem, The Netherlands- Powered by FreeBSD -
:|/|/ / / /( (_) Bulte WWW :
34 matches
Mail list logo
