On Tue, 28 Jan 2025 15:33:30 -0500
Ian FREISLICH wrote:
> On 2025-01-28 06:23, Milan Obuch wrote:
[ snip ]
> > It looks like the right thing, in my case adding
> > vm.pmap.pcid_enabled=0 to /boot/loader.conf helps. I consider this
> > easier than installing port for microcode update...
> >
> >
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 changi
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
in-src/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/lib/libcxx
bcxxrt.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:
>>>
2021
>>>>>> /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
gt;>>> 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 -> ../
021
>>> /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 -> ../../l
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 r
_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
el 64 Dec 30 08: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
> 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
> ( /lib/libc++.so.1
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 De
match to what is reported 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
> 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++: err
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 .)
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
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
rote:
> Hi Larry,
>
> This looks 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:
>&g
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-
y 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 u
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
uot; 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
se to have a match: 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
at 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, zp
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
> feat
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 shows
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 crash
> 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 LLV
> 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:
>
>
all-stage2-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
arm6
> 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
directories 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 N
ired by the application
*** Error code 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):
>>>>>>>>>
>>>&
:
>>>>>>>
>>>>>>>> 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
, esr 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 up
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 u
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
>>>>>>
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
ry /usr/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 s
id changed. fsid 0:0: 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 -
: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.0-CURRENT FreeBSD 14.0-CURRENT #10
main-n250667-20aa359773be-dirty: Sun Nov 14 00:24:51 PST 2021
> 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 thr
lard 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-890cae1
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 wen
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/m
9:35 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)
===>
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: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.
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
&
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-
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
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/GE
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
/usr/tests/lib/libc/has
(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
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
> --- a/tools/bu
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
+++ b/tools/build/mk/OptionalObso
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 rebu
e 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-Oc
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
/usr/lib/debug/boot/kernel
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.)
>>
before 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
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 by
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
aphics/drm-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 s
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
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 usr/src/sys/netgraph/ng_messag
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 defa
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:
> >
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
> j...@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:
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
uname -apKU
> 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 1300
-CA72
arm64 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/GENER
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 with
1 - 100 of 373 matches
Mail list logo
