Quoting Rick Macklem (from Tue, 4 Jan 2022
03:18:36 +):
Konstantin Belousov wrote:
[good stuff snipped]
The v4 NFS is very different from v3, it is not an upgrade, it is rather
a different network filesystem with some (significant) similarities to v3.
That said, it should be fine
Hi,
Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2.
The manual page says:
nfsv2 Use the NFS Version 2 protocol (the default is to try
version 3 first then version 2). Note that NFS version 2
has a file size limit of 2 gigabytes.
And the
c/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
>>>>>>>> ( /lib/libc++.so.1 /usr/lib/libcxxrt.so
>>>>>>>> and:
>>>>>>>> lrwxr-xr-x 1 root wheel23 Dec 29 13:17:01 2021
>>>>>>>> /usr/
t.so
>>>>>>> and:
>>>>>>> lrwxr-xr-x 1 root wheel23 Dec 29 13:17:01 2021
>>>>>>> /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1
>>>>>>>
>>>>>>> Why did libc++.so.1 not get a:
>>>&
>>>>>> /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1
>>>>>>
>>>>>> Why did libc++.so.1 not get a:
>>>>>>
>>>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1
>>>>> I forgot to r
t;>> and:
>>>> lrwxr-xr-x 1 root wheel23 Dec 29 13:17:01 2021
>>>> /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1
>>>>
>>>> Why did libc++.so.1 not get a:
>>>>
>>>> /usr/lib/libc++.so.1 -> .
>>> /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1
>>>
>>> Why did libc++.so.1 not get a:
>>>
>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1
>> I forgot to remove the .1 on the left hand side:
>> /usr/lib/libc++.so -> ../../li
On 2021-Dec-30, at 19:15, Mark Millard wrote:
>
>> On 2021-Dec-30, at 15:14, Cy Schubert wrote:
>>
>> In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard
>> write
>> s:
>>> On 2021-Dec-30, at 11:52, Mark Millard wrote:
>> . . .
>> It was a NO_CLEAN build. A CLEAN build
_at_head:~/freebsd-src % uname -a
>> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd:
>> Thu Dec 30 11:33:16 CET 2021
>> root_at_head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP amd64
>> tuexen_at_head:~/freebsd-src % sudo make
30:43 2021 /usr/obj/BUILDs/main-amd
>> 64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so
>>>
>>> So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been
>>> updated.
>>>
>>> I used META_MODE.
>>>
>>> So I do not get a full ma
> Dear all,
>
> on a system updated yesterday I get
>
> tuexen_at_head:~/freebsd-src % git branch
> * main
> tuexen_at_head:~/freebsd-src % git pull
> Already up to date.
> tuexen_at_head:~/freebsd-src % uname -a
> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRE
On 2021-Dec-30, at 13:05, Mark Millard wrote:
> This asks a question in a different direction that my prior
> reports about my builds vs. Cy's reported build.
>
> Background:
>
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
> (
This asks a question in a different direction that my prior
reports about my builds vs. Cy's reported build.
Background:
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
( /lib/libc++.so.1 /usr/lib/libcxxrt.so
and:
lrwxr-xr-x 1 root wheel23
ported but the use of
> the tmp/usr/lib/libc++.so path does seem odd.
>
> I've not looked at what a system from before the first move of
> libc++.so.1 does. I may be able to check that in a while.
So I've now looked at a build (not installed) that was done on:
# uname -apKU
FreeBSD CA7
> This commit results in a different error.
>
> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64.am
> d64/tmp
> >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
> >>> ^
> c++:
Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing
and rebooting did not put in place a /lib/libc++.so.1 but
delete-old-libs removed the /usr/lib/libc++.so.1 .
(Luckily my environment has sufficient recent near-redundancy
to recover easily by putting in place a /usr/lib/libc++.so.1 .)
ied to get past this. There could be more that
fails to build after lldb.
I'm not sure if WITH_ASAN= WITH_UBSAN= is supposed to do
anything for buildkernel but I've not managed to get a
buildworld to finish everything yet.
May be src.conf is just ahead of what the build environment
is set up for?
For
Confirmed. The kernel at ..
FreeBSD 14.0-CURRENT #0 f06f1d1fdb9: Mon Dec 20 12:24:51 EST 2021
.. boots successfully.
The kernel at ..
FreeBSD 14.0-CURRENT #1 553af8f1ec7: Tue Dec 21 15:16:10 EST 2021
.. fails immediately after printing something like ..
Timecounters tick every 1.000 msec
like some use-after-free or otherwise corrupted callout
> structure. Unfortunately the backtrace does not tell what was the
> callout. When was the previous update to look what could change?
>
> On 10.12.2021 11:24, Larry Rosenman wrote:
>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14
On 2021-Dec-18, at 09:30, Ed Maste wrote:
> On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote:
>>
>> I'm confused, beyond just LGPL claims in the (fairly
>> current) source code, but GPL more generally:
>>
>> # grep -rl "SPDX.*GPL" /usr/main-src/
public license, only one under
> > LGPL
> > which will be soon gone.
> >
> > As for the commands, various is now a bit overrated, only diff3 is under GPL
>
> Good point, in main right now we have LGPL dialog and libdialog, and
> GPL diff3, with additional ones in the stable branch
Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for
readability):
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main
From: FreeBSD User wrote on
Date: Wed, 15 Dec 2021 18:55:09 +0100 :
> . . .
>
> It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole
> box even if
> the essential operating system stuff is isolated on a dedicated UFS
> filesystem.
I would guess that, for ZFS being in
thing like this will improve things.
if (0 == print "test\015\012") {
return;
}
Regards and happy hacking,
Ronald.
PS: I think this does not have to do a lot with freebsd-current. Might move it
to https://lists.freebsd.org/subscription/freebsd-perl or some
send" and "man 2 socket" for a lot more information.
So it depends a bit on the type of socket you created.
Regards and happy hacking,
Ronald.
Van: Piper H
Datum: woensdag, 15 december 2021 07:52
Aan: freebsd-current@freebsd.org
Onderwerp: question on socket server
Hello
I have litt
tch: it was not obvious from my
background knowledge.
(From what you have reported, I'd not expect stable/* or
main to have such links.)
Thanks for the information. I know better what to do now.
>>> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
>>>&g
that would have the final
version?
> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
>> I just noticed that main reports that my pools were created
>> implicitly matching openzfs-2.1-freebsd (and without
>> an explicit compatibility assignment) but, under main, zpool
&
On 2021-Dec-14, at 16:36, Mark Millard wrote:
> I just noticed that main reports that my pools were created
> implicitly matching openzfs-2.1-freebsd (and without
> an explicit compatibility assignment) but, under main, zpool
> import and zpool status for those pools report a new, disabled
>
I just noticed that main reports that my pools were created
implicitly matching openzfs-2.1-freebsd (and without
an explicit compatibility assignment) but, under main, zpool
import and zpool status for those pools report a new, disabled
feature. Turns out the issue matches what the diff below
Since it was booting before, does the old loader start? I see the iKVM windo
does have record menu entry, can it be used to record whole incident?
rgds,
toomas
> чт, 9 дек. 2021 г. в 18:19, Toomas Soome :
>
>>
>>
>>> On 9. Dec 2021, at 20:06, Sergey Dyatko wrote:
>
> On 17 Nov 2021, at 09:00, Marcin Wojtas wrote:
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.
Firstly, thank your for your efforts here, it is appreciated :)
I am finding that the lang/sdcc port is
> On 25 Nov 2021, at 18:50, FreeBSD User wrote:
>
> Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov
> 22 18:17:54
> CET 2021 amd64) troubles me with our DNS server/service.
> Aproximately the same time we switched on CURRENT to the CURRENT
> On 9. Dec 2021, at 20:06, Sergey Dyatko wrote:
>
> I was sure the installer did it when I reinstalled the system from scratch. I
> can load 14-current successfully after boot via PXE and installworld with
> 13-current
> now I did the following:
> 1) boot from HDDs Fr
: Probing bus
. . .
mmc0: SD probe: failed
mmc0: MMC probe: OK (OCR: 0x40ff8080)
mmc0: Current OCR: 0x00ff8080
mmc0: Probing cards
mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313)
mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d)
mmc0: Card at relative address 0x0002 added
As of my update to (some line splitting applied):
# uname -apKU
FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64
ecording.o] Error 1
> gmake[4]: *** [Makefile:1142: jit/jit-playback.o] Error 1
> rm gcc.pod gfortran.pod
> gmake[4]: Leaving directory '/wrkdirs/usr/ports/lang/gcc11/work/.build/gcc'
> gmake[3]: *** [Makefile:4817: all-stage2-gcc] Error 2
>
>
> For reference:
>
> # uname -
2-gcc] Error 2
For reference:
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #24
main-n251362-9f32cb5b1c81-dirty: Sun Dec 5 21:16:30 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64
> dropping https://github.com/DankBSD/ports/commit/56cb9dc72 and
Err, the right commit: https://github.com/DankBSD/base/commit/52ff26f21
> It appears that your build environment does not have the b366ee486 version
> of /usr/src/sys/ufs/ffs/fs.h installed in /usr/include/ufs/ffs/fs.h.
>
> That would normally happen after your did a buildworld and installworld.
> You should be able to fix your current compile f
I was updating from
commit 20aa359773befc8182f6b5dcb5aad7390cab6c26
Author: Dimitry Andric
Date: Sat Nov 13 21:02:29 2021 +0100
Bump __FreeBSD_version for llvm-project 13.0.0 merge
PR: 258209
MFC after: 2 weeks
to
commit b366ee4868bca2b3ebe4bb29c9590a29b6cecc29
tories run 'make delete-old'.
To remove old libraries run 'make delete-old-libs'.
in /usr/obj/DESTDIRs/main-amd64-poud for:
# chroot /usr/obj/DESTDIRs/main-amd64-poud uname -apKU
FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #14
main-n250972-319e9fc642a1-dirty: Tue Nov 23 11:43:26 PST 2021
de 1
Stop.
make: stopped in /usr/ports/devel/py-pycparser
===>>> make build failed for devel/py-pycparser@py38
===>>> Aborting update
FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62
heads/main-n251146-d109559ddbf: Mon Nov 29 12:18:48 CET 2021
root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64
On 11/29/21 06:22, Jamie Landeg-Jones wrote:
> Dennis Clarke via freebsd-current wrote:
>
>> europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump
>>
>> europa#
>> europa# pkg backup -r /var/db/pkg/local.sqlite.dump
>> Restoring data
://docs.freebsd.org/en/books/handbook/ports/#pkgng-intro
However that does not work and issues a truely worthless error :
europa# uname -apKU
FreeBSD europa 14.0-CURRENT FreeBSD 14.0-CURRENT #6
main-n250839-be60d8f276f: Fri Nov 19 00:02:38 GMT 2021
root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
On 11/22/21 12:55 PM, Warner Losh wrote:
On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote:
On Mon, Nov 22, 2021 at 9:34 AM Chris wrote:
On 2021-11-22 08:47, Chuck Tuffli wrote:
Running on a recent-ish -current
# uname -a
FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT
rote:
>>>>>>>
>>>>>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>>>>>>>
>>>>>>>>> I updated from (shown a system that I've not updated yet):
>>>>>>>>>
>>>>&g
:
>>>>>>>
>>>>>>>> I updated from (shown a system that I've not updated yet):
>>>>>>>>
>>>>>>>> # uname -apKU
>>>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT Free
0x200
vt_conswindow() at vt_conswindow+0x10
(null)() at -0x4
(null)() at 0x0001
Uptime: 3s
The full log is here:
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-4082b189d2c/failed-boot1.txt
On 11/18/2021 12:22 AM, Dustin Marquess wrote:
I just updated
ard wrote:
>>>>
>>>>> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>>>>>
>>>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>>>>>
>>>>>>> I updated from (shown a system that I've not update
ard wrote:
>>>>
>>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>>>>
>>>>>> I updated from (shown a system that I've not updated yet):
>>>>>>
>>>>>> # uname -apKU
>>>>>> Fre
ork and ^T did not echo out what
>> would be expected for poudriere (or even the kernel backtrace).
>> I was able to escape to ddb.
>>
>> The context was Cortex-A72 based aarch64 system using:
>>
>> # poudriere jail -jmain-CA7 -i
>> Jail name: main-C
sr/local/lib/firefox/libmozsqlite3.soI then
symlinked the above to /usr/local/lib and got this error:XPCOMGlueLoad error
for file
/usr/local/lib/firefox/libxul.so:/usr/local/lib/firefox/libmozsqlite3.so:
version libmozsqlite3.so required by /usr/local/lib/firefox/libxul.so not
defined FreeBSD sting
: expected fileid 0xa, got 0x2. (BROKEN NFS SERVER OR
> MIDDLEWARE)
> Nov 18 03:01:09 amd64_ZFS kernel: newnfs: server '192.168.1.148' error:
> fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS SERVER OR
> MIDDLEWARE)
>
> # uname -apKU
> FreeBSD amd64_ZFS 14
: newnfs: server '192.168.1.148' error: fileid
changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS SERVER OR
MIDDLEWARE)
# uname -apKU
FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #10
main-n250667-20aa359773be-dirty: Sun Nov 14 00:24:51 PST 2021
root@amd64_ZFS:/usr/obj/BUILDs
> On 2021-Nov-18, at 12:31, tue...@freebsd.org wrote:
>
>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current
>> wrote:
>>
>> I've not noticed the ertt message before in:
>>
>> . . .
>> Waiting (max 60 seconds) for system thread `
illard wrote:
>>>>
>>>>> I updated from (shown a system that I've not updated yet):
>>>>>
>>>>> # uname -apKU
>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
>>>>> main-n250455-890cae197737
I've not noticed the ertt message before in:
. . .
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done
All buffers synced.
Uptime: 1d9h57m18s
Khelp module "ertt" can't unload until its refcount drops from 1 to 0.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net
I've not updated yet):
>>>>
>>>> # uname -apKU
>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
>>>> main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
>>>> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-C
PM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:
Haven't had time to identify which change caused this yet but I now get ..
===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib
Haven't had time to identify which change caused this yet but I now get ..
===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error:
On 2021-Nov-15, at 13:13, Mark Millard wrote:
> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>
>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>
>>> I updated from (shown a system that I've not updated yet):
>>>
>>> # uname -apKU
>&g
On 2021-Nov-15, at 12:51, Mark Millard wrote:
> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>
>> I updated from (shown a system that I've not updated yet):
>>
>> # uname -apKU
>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
>> main-n2504
On 2021-Nov-15, at 11:31, Mark Millard wrote:
> I updated from (shown a system that I've not updated yet):
>
> # uname -apKU
> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
> main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
> root@CA72
I updated from (shown a system that I've not updated yet):
# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC
In my update sequence to install FreeBSD with the clang 13
related materials, the first -j32 installworld attempt got:
. . .
--- realinstall_subdir_lib/libc/tests/hash ---
install -o root -g wheel -m 444
/usr/main-src/contrib/netbsd-tests/lib/libc/hash/data/md5test-out
ere (or even the kernel backtrace).
> I was able to escape to ddb.
>
> The context was Cortex-A72 based aarch64 system using:
>
> # poudriere jail -jmain-CA7 -i
> Jail name: main-CA7
> Jail version: 14.0-CURRENT
> Jail arch: arm.armv7
> Jail method: null
was Cortex-A72 based aarch64 system using:
# poudriere jail -jmain-CA7 -i
Jail name: main-CA7
Jail version: 14.0-CURRENT
Jail arch: arm.armv7
Jail method: null
Jail mount:/usr/obj/DESTDIRs/main-CA7-poud
Jail fs:
Jail updated: 2021-06-27 17:58:33
Jail
I confirm, the attached patch fixes ports mentioned in my previous mail.
Ports graphics/cairo, multimedia/ffmpeg, www/firefox are also affected.
On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current
wrote:
>On current as of this morning (I haven't tried to bisect yet) ..
>
> .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod,
>trying to start a VirtualBox VM triggers this pani
On current as of this morning (I haven't tried to bisect yet) ..
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
14.0-CURRENT #42 main-a670e1c13a: Tue Nov 2 09:29:28 EDT 2021
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
amd64
On 2021-Oct-27, at 15:21, Mark Millard wrote:
> Unfortunately(?) this update added the .so.10 to mk/OptionalObsoleteFiles.inc
> :
>
> diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
> b/tools/build/mk/OptionalObsoleteFiles.inc
> index a8b0329104c4..91822aac492a 100644
> ---
Unfortunately(?) this update added the .so.10 to mk/OptionalObsoleteFiles.inc :
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index a8b0329104c4..91822aac492a 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++
BSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT
#57 heads/main-n250195-6ba2210ee03: Thu Oct 21 21:19:23 CEST 2021
filippo@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 Filippo
But kernel failed to install. I will include log tomorrow, I'm doing a
clean build with /usr/obj/.. deleted.
Michael Butler via freebsd-current <mailto:freebsd-current@freebsd.org>> escreveu no dia quinta, 21/10/2021
à(s) 20:14:
Well this is different .. I did a full rebuild (
the changes, there by not matching
old programs built under releng/13.0 or stable/13 .
Turns out that this explains the crashes I get when I attempt
to use a releng/13 based dialog4ports under main [so: 14]. For
a particular example, see:
https://lists.freebsd.org/archives/freebsd-current/2021-October
On 2021-Oct-21, at 16:24, Mark Millard wrote:
> On 2021-Oct-21, at 11:53, Mark Millard wrote:
>
>> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>>
>>> On Thu, 21 Oct 2021 07:40:36 -0700
>>> Mark Millard via freebsd-current wrote:
>>>
&g
On 2021-Oct-21, at 11:53, Mark Millard wrote:
> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>
>> On Thu, 21 Oct 2021 07:40:36 -0700
>> Mark Millard via freebsd-current wrote:
>>
>>>
>>>
>>> On 2021-Oct-21, at 06:14, Gary Jennejohn
Well this is different .. I did a full rebuild (after "rm -rf
/usr/obj/*") this morning and now see ..
===> linux_common (install)
install -T release -o root -g wheel -m 555 linux_common.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 linux_common.ko.debug
On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
> On Thu, 21 Oct 2021 07:40:36 -0700
> Mark Millard via freebsd-current wrote:
>
>>
>>
>> On 2021-Oct-21, at 06:14, Gary Jennejohn wrote:
>>
>>> On Thu, 21 Oct 2021 01:34:47 -0700
>>> Mark
On 2021-Oct-21, at 06:14, Gary Jennejohn wrote:
> On Thu, 21 Oct 2021 01:34:47 -0700
> Mark Millard via freebsd-current wrote:
>
>> I get the following crash (amd64 example shown), as reported
>> via gdb afterwards. (devel/llvm13 is just an example context.)
>>
efore that (no line drawing, just odd text instead),
but is sufficient to be usable at that stage.
I've not had any other of the ports that I built in/for releng/13.0
(and have used) fail to operate under main [so: under 14]. (But the
variety used is not wide.)
For reference . . .
# uname -apKU
Free
On 12/10/21 14:21, Gary Jennejohn wrote:
On Tue, 12 Oct 2021 06:59:00 -0400
grarpamp wrote:
No. The system shell is supposed to make the system usable
by the users. Actually, the real problem is that the easiest way
to shoot one's own foot is by changing the language (say, the
shell) spoken
red *active_cred __unused, struct thread *td __unused)
+#endif
{
/* XXX need to define flags for st_mode */
On 10/11/21, Michael Butler via freebsd-current
wrote:
After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..
--- dma-bu
-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi
1 error
make[3]: stopped in
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi
I get a similar error with drm-current-kmod. What changed?
imb
On 10-10-2021 07:57, Rick Macklem wrote:
This leads me to a couple of questions:
- Is there a good reason for not using vop_stdallocate() for ZFS?
Yes. posix_fallocate is supposed to guarantee that subsequent writes
to the file will not fail with ENOSPC. But ZFS, being a copy-on-write
file
On 10/7/21 20:19, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:
On 10/7/21 16:52, Mark Johnston wrote:
On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
wrote:
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07
On 10/7/21 16:52, Mark Johnston wrote:
On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
wrote:
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
While building a local release bundle
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the build
While building a local release bundle, I sometimes get bsdtar failing
(and dumping core) as follows below. Worse, as can be seen below, it
doesn't stop the build unless I happen to notice and it yields an
incomplete package.
a usr/src/sys/netgraph/ng_checksum.h
a
Ignored: 0 Fetched: 0 Tobuild: 1 Time:
> -666894:-15:-9
> [00:00:00] Recording filesystem state for prepkg... done
> . . .
>
>
> For reference:
>
> # poudriere version
> poudriere-git-3.3.99.20210907_1
>
> # uname -apKU
> FreeBSD OPiP2E_RPi2v11 14.0
Will history/completion continue to work the same way? (for example
typing part of the command, pressing UP and having it complete based on
history)
On 9/22/2021 4:36 AM, Baptiste Daroussin wrote:
Hello,
TL;DR: this is not a proposal to deorbit csh from base!!!
For years now, csh is the
On 2021-Sep-16, at 16:27, Freddie Cash wrote:
>
> [message chopped and butchered, don't follow the quotes, it's just to show
> some bits together from different messages]
>
> On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current
> wrote:
> > > F
On 2021-Sep-16, at 15:16, Alan Somers wrote:
> On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote:
>
>
> On 2021-Sep-16, at 13:39, Alan Somers wrote:
>
> > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current
> > wrote:
> > What do I go
.@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
>
>
>> On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current
>> wrote:
>>
>> What do I go about:
>>
>> QUOTE
>> # zpool import
>> pool: zopt0
On 2021-Sep-16, at 13:39, Alan Somers wrote:
> On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current
> wrote:
> What do I go about:
>
> QUOTE
> # zpool import
>pool: zopt0
> id: 18166787938870325966
> state: FAULTED
> status: One or m
U
> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4
> releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
> arm64 aarch64 1300139 130013
m64 aarch64 1300139 1300139
I have also tried under:
# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12
main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-C
After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to
recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set.
For example ..
imb@vm01:/home/imb> date
Tue Sep 14 01:25:57 2021
Every other daemon also thinks it's running in UTC+0 :-(
When libc is recompiled
On 14/09/21 00:12, Konstantin Belousov wrote:
On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote:
On 13/09/21 19:08, Konstantin Belousov wrote:
On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote:
Hi,
I updated head recently and today I noticed
1 - 100 of 372 matches
Mail list logo
