Re: snapshot 1st aarcch64 boot got devd error message: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found"
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
/usr/main-src/sbin/devd/Makefile:.if ${MK_HYPERV} != "no"
/usr/main-src/libexec/Makefile.i386:.if ${MK_HYPERV} != "no"
/usr/main-src/libexec/Makefile.amd64:.if ${MK_HYPERV} != "no"
/usr/main-src/usr.sbin/Makefile.amd64:.if ${MK_HYPERV} != "no"
/usr/main-src/usr.sbin/Makefile.i386:.if ${MK_HYPERV} != "no"
/usr/main-src/lib/libc/x86/sys/Makefile.inc:.if ${MACHINE_CPUARCH} == "amd64"
&& ${MK_HYPERV} != "no"
/usr/main-src/tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_HYPERV} == no
(The below is based on cgit.freebsd.org
Re: snapshot 1st aarcch64 boot got devd error message: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found"
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 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" "ETHERNET";
> match "type""IFATTACH";
> action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
> };
>
> For reference:
>
> # ls -Tla /usr/libexec/hyperv/
> total 8
> drwxr-xr-x 2 root wheel 512 Dec 24 06:30:06 2022 .
> drwxr-xr-x 10 root wheel 1536 Dec 24 06:49:40 2022 ..
>
> I do not know if the error might have lead to skipping some
> other activities or not.
>
> Note:
>
> This is from a test where I'd 1st side stepped a syntax problem
> in /etc/rc.d/growfs in the snapshot to try to see if the growfs
> otherwise worked.
>
> # uname -apKU # long output line split for reability
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64 aarch64 1400076 1400076
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>
snapshot 1st aarcch64 boot got devd error message: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found"
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" "ETHERNET";
match "type""IFATTACH";
action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
};
For reference:
# ls -Tla /usr/libexec/hyperv/
total 8
drwxr-xr-x 2 root wheel 512 Dec 24 06:30:06 2022 .
drwxr-xr-x 10 root wheel 1536 Dec 24 06:49:40 2022 ..
I do not know if the error might have lead to skipping some
other activities or not.
Note:
This is from a test where I'd 1st side stepped a syntax problem
in /etc/rc.d/growfs in the snapshot to try to see if the growfs
otherwise worked.
# uname -apKU # long output line split for reability
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64 aarch64 1400076 1400076
===
Mark Millard
marklmi at yahoo.com
Re: ZFS rename with associated snapshot present: odd error message
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 >>> . . . >>> 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 - 1.44G >>> -. . . >>> . . . >>> (copied/pasted from somewhat earlier) and then attempted: >>> # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm >>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 >>> cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot >>> delimiter '@' is not expected here >>> Despite the "cannot open" message, the result looks like: >>> # zfs list -tall >>> NAME USED AVAIL >>> REFER MOUNTPOINT >>> . . . >>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G >>> 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 >>> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - >>> 1.44G - >>> . . . >>> Still, it leaves me wondering if everything is okay >>> given that internal attempt to use the old name with >>> @dirty-style when it was apparently no longer >>> available under that naming. >>> For reference: >>> # uname -apKU >>> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 >>> releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 >>> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 >>> arm64 aarch64 1300139 1300139 >> >> Cannot reproduce here (but with much simpler names and on stable/13): >> zfs create testz/test >> zfs snapshot testz/test@snap1 >> zfs rename testz/test testz/test2 >> >> All worked. >> > > I've noticed that sometimes in my explorations it has been > silent instead of complaining. I've no clue at this point > what prior activity (or lack of activity) makes the > difference for if a message will be generated vs. not. One difference in context is that your above sort of sequence generates the after-snapshot context (using some things I have around now): zroot/DESTDIRs/13_0R-CA53-poud 1.45G 127G 1.45G /usr/obj/DESTDIRs/13_0R-CA53-poud zroot/DESTDIRs/13_0R-CA53-poud@test 0B - 1.45G - where my example had something more like (hand edited the above just for illustration): zroot/DESTDIRs/13_0R-CA53-poud 1.45G 125G 96K /usr/obj/DESTDIRs/13_0R-CA53-poud zroot/DESTDIRs/13_0R-CA53-poud@test1.45G - 1.45G - before the rename. In other words, I'd updated the original (almost?) completely after the snapshot (as a side effect of my overall activity). It was only later that I tried the rename to track a new purpose/context that I was going to switch to. I'm not claiming that such is sufficient to (always? ever?) reproduce the message. I'm just pointing out that I'd had some significant activity on the writable file system before the rename. Some of my activity has been more like your test and I'd not seen the problems from such. But it is not a very good comparison/contrast context so I'd not infer much. I still can not at-will set up a context to produce the messages. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS rename with associated snapshot present: odd error message
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 117G 96K >> /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm >> zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G >> -. . . >> . . . >> (copied/pasted from somewhat earlier) and then attempted: >> # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm >> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 >> cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot >> delimiter '@' is not expected here >> Despite the "cannot open" message, the result looks like: >> # zfs list -tall >> NAME USED AVAIL >> REFER MOUNTPOINT >> . . . >> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G >> 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 >> zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - >> 1.44G - >> . . . >> Still, it leaves me wondering if everything is okay >> given that internal attempt to use the old name with >> @dirty-style when it was apparently no longer >> available under that naming. >> For reference: >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 >> releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 >> root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 >> arm64 aarch64 1300139 1300139 > > Cannot reproduce here (but with much simpler names and on stable/13): > zfs create testz/test > zfs snapshot testz/test@snap1 > zfs rename testz/test testz/test2 > > All worked. > I've noticed that sometimes in my explorations it has been silent instead of complaining. I've no clue at this point what prior activity (or lack of activity) makes the difference for if a message will be generated vs. not. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS rename with associated snapshot present: odd error message
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 zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G -. . . . . . (copied/pasted from somewhat earlier) and then attempted: # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot delimiter '@' is not expected here Despite the "cannot open" message, the result looks like: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - 1.44G - . . . Still, it leaves me wondering if everything is okay given that internal attempt to use the old name with @dirty-style when it was apparently no longer available under that naming. For reference: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 Cannot reproduce here (but with much simpler names and on stable/13): zfs create testz/test zfs snapshot testz/test@snap1 zfs rename testz/test testz/test2 All worked. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS rename with associated snapshot present: odd error message
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 - 1.44G -. . . . . . (copied/pasted from somewhat earlier) and then attempted: # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot delimiter '@' is not expected here Despite the "cannot open" message, the result looks like: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - 1.44G - . . . Still, it leaves me wondering if everything is okay given that internal attempt to use the old name with @dirty-style when it was apparently no longer available under that naming. For reference: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
diffoscope's odd UnicodeDecodeError error message: reason found
I had reported in the reproducable build list messages:
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
> invalid start byte
Well, it turns out that the file name pattern was
incorrect and only matched one file.
By contrast:
# diffoscope /.zfs/snapshot/2021-04-*/bin/sh
$<3/>2021-05-04 11:05:25 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
worked fine.
And making the "one file" status obvious:
# diffoscope c_tests/a.out
$<3/>2021-05-04 11:11:45 W: diffoscope.main: Fuzzy-matching is currently
disabled as the "tlsh" module is unavailable.
$<3/>Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 745,
in main
sys.exit(run_diffoscope(parsed_args))
File "/usr/local/lib/python3.7/site-packages/diffoscope/main.py", line 677,
in run_diffoscope
difference = load_diff_from_path(path1)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 31, in load_diff_from_path
return load_diff(codecs.getreader("utf-8")(fp), path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/__init__.py",
line 35, in load_diff
return JSONReaderV1().load(fp, path)
File "/usr/local/lib/python3.7/site-packages/diffoscope/readers/json.py",
line 33, in load
raw = json.load(fp)
File "/usr/local/lib/python3.7/json/__init__.py", line 293, in load
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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
error message during "mergemaster"
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 in /var/tmp/temproot make[4]: "/usr/src/lib/libc/net/Makefile.inc" line 130: warning: duplicate script for target "afterinstallconfig" ignored make[4]: "/usr/src/lib/libc/gen/Makefile.inc" line 554: warning: using previous script for "afterinstallconfig" defined here I looks like the generated kernel correctly works but the error message should not be there... What can be the cuase and how can I repair it? Best regards Krasznai András rendszermérnök [M_logo] 1136 Budapest, Pannónia utca 11. Tel: +36 1 703 2923 Mobil: +36 30 703 2923 Központ: +36 1 703 2920 Fax: +36 1 703 2949 email: krasznai.and...@mands.hu ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: error message from pkg on HEAD
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:
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
/usr/local/etc/pkg/repos/FreeBSD.conf: SRV
pkg does seem to work so I'm not sure what I need to do. I think I was
told to add these lines to the file, though I'm not sure, so I don't want
to delete them.
Thanks for help in letting me know what the solution is.
# pkg -v
1.2.4_1
# uname -a
FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4
r260082M: Wed Jan 1 12:08:41 PST 2014
j...@carbon.funkthat.com:/usr/obj/usr/src/sys/lockprof
amd64
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD:
URL: http://pkg.freebsd.org/${ABI}/latest
ENABLED: YES
MIRROR_TYPE: SRV
The file format is incorrect.
FreeBSD: {
url: http://pkg.freebsd.org/${ABI}/latest;,
enabled: yes,
mirror_type: srv
}
Shouldn't the URL start with pkg+http://?
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
error message from pkg on HEAD
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 /usr/local/etc/pkg/repos/FreeBSD.conf:
SRV
pkg does seem to work so I'm not sure what I need to do. I think I was
told to add these lines to the file, though I'm not sure, so I don't want
to delete them.
Thanks for help in letting me know what the solution is.
# pkg -v
1.2.4_1
# uname -a
FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r260082M: Wed
Jan 1 12:08:41 PST 2014
j...@carbon.funkthat.com:/usr/obj/usr/src/sys/lockprof amd64
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD:
URL: http://pkg.freebsd.org/${ABI}/latest
ENABLED: YES
MIRROR_TYPE: SRV
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: error message from pkg on HEAD
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
/usr/local/etc/pkg/repos/FreeBSD.conf: true
pkg: Ignoring bad configuration entry in
/usr/local/etc/pkg/repos/FreeBSD.conf: SRV
pkg does seem to work so I'm not sure what I need to do. I think I was
told to add these lines to the file, though I'm not sure, so I don't want
to delete them.
Thanks for help in letting me know what the solution is.
# pkg -v
1.2.4_1
# uname -a
FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r260082M:
Wed Jan 1 12:08:41 PST 2014
j...@carbon.funkthat.com:/usr/obj/usr/src/sys/lockprof amd64
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD:
URL: http://pkg.freebsd.org/${ABI}/latest
ENABLED: YES
MIRROR_TYPE: SRV
The file format is incorrect.
FreeBSD: {
url: http://pkg.freebsd.org/${ABI}/latest;,
enabled: yes,
mirror_type: srv
}
Glen
pgpIE3sTUerRe.pgp
Description: PGP signature
Re: error message from pkg on HEAD
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:
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
/usr/local/etc/pkg/repos/FreeBSD.conf: SRV
pkg does seem to work so I'm not sure what I need to do. I think I was
told to add these lines to the file, though I'm not sure, so I don't want
to delete them.
Thanks for help in letting me know what the solution is.
# pkg -v
1.2.4_1
# uname -a
FreeBSD carbon.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r260082M:
Wed Jan 1 12:08:41 PST 2014
j...@carbon.funkthat.com:/usr/obj/usr/src/sys/lockprof amd64
# cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD:
URL: http://pkg.freebsd.org/${ABI}/latest
ENABLED: YES
MIRROR_TYPE: SRV
The file format is incorrect.
FreeBSD: {
url: http://pkg.freebsd.org/${ABI}/latest;,
enabled: yes,
mirror_type: srv
}
For the archives.
Glen helped me in IRC, it turns out that this file was no longer
necessary. I beileve I was told to add it at one point to make pkg
work, but the correct solution was to remove the file...
Thanks Glen.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PR 181532: src/sbin/route/route.c patch for a more useful error message
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://www.freebsd.org/cgi/query-pr.cgi?pr=181532 changes this to: route get requires a parameter, try 'default' Can someone commit this change ? -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error message while updating src for FreeBSD 9 current
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, wireless devices and hardware only found on laptops. The early results are encouraging. I run fold...@home in a VirtualBox with Unbuntu x64 as a guest OS. Since trying a custom kernel, floating point performance has improved over 20%. This may also be due to some kernel improvements in FreeBSD 9. So far I am very impressed with the stability of the OS. I have not had problems with any of the programs that I run on a regular basis. I had expected to hit more bugs. I will get started on the rebuilds but with 1700 ports installed, I will wait for a free weekend to compile the big stuff. Thanks again Ralph Ellis ralphell...@netscape.ca Glad to hear everything worked out in the end! Just a side note, clang is already included in the base system in FreeBSD 9, so unless you've opted out from that with WITHOUT_CLANG in /etc/src.conf then you don't need the port. Regards! //Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error message while updating src for FreeBSD 9 current
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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca Are you using cvsup or csup? Have you recompiled cvsup in case you use that? What's in your make.conf file? Illegal instruction is usually because the program is compiled for another CPU than what it's running on. It can also be that syscalls has changed, but then it usually complains about that. When doing a major version upgrade, you usually have to recompile all ports. Hope this helps! //Niclas 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 ralphell...@netscape.ca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[SPAM] Re: Error message while updating src for FreeBSD 9 current
On 2010-09-23 13:21, Ralph Ellis wrote: 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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca Are you using cvsup or csup? Have you recompiled cvsup in case you use that? What's in your make.conf file? Illegal instruction is usually because the program is compiled for another CPU than what it's running on. It can also be that syscalls has changed, but then it usually complains about that. When doing a major version upgrade, you usually have to recompile all ports. Hope this helps! //Niclas 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 ralphell...@netscape.ca Try to recompile everything, or at least cvsup, and see if it works. //Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [SPAM] Re: Error message while updating src for FreeBSD 9 current
On 2010-09-23 13:36, Niclas Zeising wrote: On 2010-09-23 13:21, Ralph Ellis wrote: 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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca Are you using cvsup or csup? Have you recompiled cvsup in case you use that? What's in your make.conf file? Illegal instruction is usually because the program is compiled for another CPU than what it's running on. It can also be that syscalls has changed, but then it usually complains about that. When doing a major version upgrade, you usually have to recompile all ports. Hope this helps! //Niclas 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 ralphell...@netscape.ca Try to recompile everything, or at least cvsup, and see if it works. //Niclas Niclas, did you perform 'make delete-old make delete-old-libs' after upgrade to CURRENT? If you did, many of your ports won't longer work properly (or at all) because of missing libraries. If you didn't, you definitely should do something like 'portupgrade -afrRi' and after you done, you can get rid of these old files with commands above. Of course it could take VERY long time depending on installed ports and machine spec., so if you just need to get your sources updated quickly I recommend: 1. Try csup instead of cvsup. It's integrated in both 8.x and in CURRENT, so should work out of the box 2. If you (for some strange reasons) want to stick to cvsup, you'll probably make it work again by portupgrade -fR 'cvsup*' 3. another approach is to get cvsup binaries from package instead of compiling ports - check man pkg_add 4. If you need cvsup to update ports tree, try portsnap instead. It's faster and smarter, and integrated with system :) - check man portsnap Good luck! -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error message while updating src for FreeBSD 9 current
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 ralphell...@netscape.ca Try to recompile everything, or at least cvsup, and see if it works. //Niclas Niclas, did you perform 'make delete-old make delete-old-libs' (...) I mean Ralph, not Niclas, sorry for that :) -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[SPAM] Re: Error message while updating src for FreeBSD 9 current
On 2010-09-23 14:02, Bartosz Stec wrote: On 2010-09-23 13:36, Niclas Zeising wrote: On 2010-09-23 13:21, Ralph Ellis wrote: 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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca Are you using cvsup or csup? Have you recompiled cvsup in case you use that? What's in your make.conf file? Illegal instruction is usually because the program is compiled for another CPU than what it's running on. It can also be that syscalls has changed, but then it usually complains about that. When doing a major version upgrade, you usually have to recompile all ports. Hope this helps! //Niclas 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 ralphell...@netscape.ca Try to recompile everything, or at least cvsup, and see if it works. //Niclas Niclas, did you perform 'make delete-old make delete-old-libs' after upgrade to CURRENT? If you did, many of your ports won't longer work properly (or at all) because of missing libraries. If you didn't, you definitely should do something like 'portupgrade -afrRi' and after you done, you can get rid of these old files with commands above. You wouldn't get illegal instruction then though. Usually the application fails to load if dynamic libraries are missing. Of course it could take VERY long time depending on installed ports and machine spec., so if you just need to get your sources updated quickly I recommend: 1. Try csup instead of cvsup. It's integrated in both 8.x and in CURRENT, so should work out of the box That's a good idea. 2. If you (for some strange reasons) want to stick to cvsup, you'll probably make it work again by portupgrade -fR 'cvsup*' 3. another approach is to get cvsup binaries from package instead of compiling ports - check man pkg_add 4. If you need cvsup to update ports tree, try portsnap instead. It's faster and smarter, and integrated with system :) - check man portsnap Good luck! //Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [SPAM] Re: Error message while updating src for FreeBSD 9 current
Niclas Zeising wrote: On 2010-09-23 14:02, Bartosz Stec wrote: On 2010-09-23 13:36, Niclas Zeising wrote: On 2010-09-23 13:21, Ralph Ellis wrote: 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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca Are you using cvsup or csup? Have you recompiled cvsup in case you use that? What's in your make.conf file? Illegal instruction is usually because the program is compiled for another CPU than what it's running on. It can also be that syscalls has changed, but then it usually complains about that. When doing a major version upgrade, you usually have to recompile all ports. Hope this helps! //Niclas 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 ralphell...@netscape.ca Try to recompile everything, or at least cvsup, and see if it works. //Niclas Niclas, did you perform 'make delete-old make delete-old-libs' after upgrade to CURRENT? If you did, many of your ports won't longer work properly (or at all) because of missing libraries. If you didn't, you definitely should do something like 'portupgrade -afrRi' and after you done, you can get rid of these old files with commands above. You wouldn't get illegal instruction then though. Usually the application fails to load if dynamic libraries are missing. Of course it could take VERY long time depending on installed ports and machine spec., so if you just need to get your sources updated quickly I recommend: 1. Try csup instead of cvsup. It's integrated in both 8.x and in CURRENT, so should work out of the box That's a good idea. 2. If you (for some strange reasons) want to stick to cvsup, you'll probably make it work again by portupgrade -fR 'cvsup*' 3. another approach is to get cvsup binaries from package instead of compiling ports - check man pkg_add 4. If you need cvsup to update ports tree, try portsnap instead. It's faster and smarter, and integrated with system :) - check man portsnap Good luck! //Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org 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, wireless devices and hardware only found on laptops. The early results are encouraging. I run fold...@home in a VirtualBox with Unbuntu x64 as a guest OS. Since trying a custom kernel, floating point performance has improved over 20%. This may also be due to some kernel improvements in FreeBSD 9. So far I am very impressed with the stability of the OS. I have not had problems with any of the programs that I run on a regular basis. I had expected to hit more bugs. I will get started on the rebuilds but with 1700 ports installed, I will wait for a free weekend to compile the big stuff. Thanks again Ralph Ellis ralphell...@netscape.ca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Error message while updating src for FreeBSD 9 current
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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error message while updating src for FreeBSD 9 current
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 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? Just for reference, the contents of my supfile are *default tag=. *default host=cvsup2.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all ports-all doc-all Thanks in advance for your assistance, Ralph Ellis ralphell...@netscape.ca Are you using cvsup or csup? Have you recompiled cvsup in case you use that? What's in your make.conf file? Illegal instruction is usually because the program is compiled for another CPU than what it's running on. It can also be that syscalls has changed, but then it usually complains about that. When doing a major version upgrade, you usually have to recompile all ports. Hope this helps! //Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
error message
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 unsubscribe freebsd-current in the body of the message
Re: error message
Thierry Herbelot wrote: 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) You need to let it rest... 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. In theory, the only thing that will suffer from this is that some things will not be witnessed correctly, which means that you could have any of the problems witness ordinarily catches for you, but not know about them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pstat -s error message
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 symbol: _numvnodes I rebuilt world and the kernel twice... I must be missing something. Bill +---+ | Bill Pechter | Lucent Technologies | Voice 732-949-1417 | Fax 732-949-5477| | 101 Crawfords Corner Road, Holmdel, NJ 07733 | [EMAIL PROTECTED]| | This message brought to you by the letters PDP and the numbers 11 and 45 | +---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Error message from CAM layer
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 also be that you've got your cable too close to the power supply. I thinks it's too close to the power supply (da0 terminates the bus). In any case, check your hardware. Thanks, Alexander. -- I've given up trying to change the world. I'm going to toilet train it so that I never have to change it again. http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Error message from CAM layer
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 longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 16 SCBs aborted -current from Jan, 30. At this time I did a "tar -xzf mozilla-FreBSD3x.M13.tar.gz" (btw: the M13 binary from mozilla.org segfaults with -current). 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? ---snip--- ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xb000-0xb0ff mem 0xd980-0xd9800fff irq 9 at device 6.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs [...] da0 at ahc0 bus 0 target 0 lun 0 da0: MICROP 4743NS S168 Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 4100MB (8398656 512 byte sectors: 255H 63S/T 522C) cd0 at ahc0 bus 0 target 1 lun 0 cd0: TEAC CD-R55S 1.0Q Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 2 lun 0 cd1: PIONEER CD-ROM DR-U16S 1.01 Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present ---snip--- Bye, Alexander. -- Do I look like a freakin' people person? http://www.Leidinger.net Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Error message from CAM layer
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 phase really in Data-in phase 54, SEQADDR == 0x113 (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 16 SCBs aborted -current from Jan, 30. At this time I did a "tar -xzf mozilla-FreBSD3x.M13.tar.gz" (btw: the M13 binary from mozilla.org segfaults with -current). 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 also be that you've got your cable too close to the power supply. In any case, check your hardware. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: error message, what does this mean?
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 VT_PROCFS, type 5, pid 252, mode 180, flags 0 May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4, ... 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 ?? Probably. Procfs has bugs that cause bad things to happen when some files in it are copied. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: error message, what does this mean?
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 23:39:23 p100 /kernel: tag VT_PROCFS, type 5, pid 252, mode 180, flags 0 May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4, ... 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 ?? Probably. Procfs has bugs that cause bad things to happen when some files in it are copied. Hmm. Never seen it before. But doing a cd / ; find . -fstype ufs -print | cpio -pudm /mnt works like a charm without the vnode_pager messages. So looks like procfs alright. | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: error message, what does this mean?
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 - :|/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org It seems to me that a cp command like is probably trying to cp -R /mnt to /mnt ... /* will include /mnt, right? I'm not sure what would be causing the errors, though, unless the cp is recursing endlessly due to the cp of /mnt on top of /mnt and running the filesystem out of space... In the end that happens, but not after a couple of seconds already. I'm quite sure it is the copying of /proc that triggers the messages. The VT_PROCFS like in May 28 10:04:15 p100 /kernel: tag VT_PROCFS, type 6, pid 193, mode 180, flags 0 also seems to indicate this. If I do: cd / ; find . -fstype ufs -print | cpio -pdum /mnt it works just fine without messages (of course until /mnt becomes full like you mention above). I've never seen this procfs behaviour before BTW. | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
error message, what does this mean?
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, refcount 0, flags (VOBJBUF) May 27 23:39:23 p100 /kernel: tag VT_PROCFS, type 5, pid 252, mode 180, flags 0 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 VT_PROCFS, type 5, pid 252, mode 180, flags 0 May 27 23:39:23 p100 /kernel: vnode_pager_getpages: I/O read error May 27 23:39:23 p100 /kernel: vm_fault: pager read error, pid 252 (cp) 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: : 0xc36002c0: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF) 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 - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: error message, what does this mean?
: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 : http://www.tcja.nl http://www.freebsd.org It seems to me that a cp command like is probably trying to cp -R /mnt to /mnt ... /* will include /mnt, right? I'm not sure what would be causing the errors, though, unless the cp is recursing endlessly due to the cp of /mnt on top of /mnt and running the filesystem out of space... -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
