FYI: A main-n259064-f83db6441a2f-dirty non-reproducing crash of system clang

[Mark Millard]

This is after having upgraded to and booted into (long output
line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #65
main-n259064-f83db6441a2f-dirty: Sun Nov  6 17:08:00 PST 2022
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400073 1400073

I then started doing more builds and got the failure
indicated later. /var/log/messages and dmesg -a output
show no messages about the failure and no messages near
the time of the failure.

Unfortunately, the error did not reproduce via either:

A) The reproducer materials in /tmp/ .
or:
B) Restarting the build that failed.

Nor was a core file left behind to look at.

The system has been stable for a long time prior to this (hours,
days, weeks, months, . . .). The only new environmental thing
has been I've starting using dpni0 (via the new DPAA2 support)
instead of using an Ethernet dongle. This does not have a long
history yet but I had been using it since after my prior FreeBSD
update as well.

It was a -j16 buildworld that got the failure. The failure
messages look like:

. . .

PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the 
crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: cc -O2 -pipe -fno-common -I. 
-I/usr/main-src/usr.sbin/config -DNDEBUG -g -gz=zlib -std=gnu99 
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition 
-Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-variable -mcpu=cortex-a53 
-Qunused-arguments 
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/legacy/usr/include
 -c lang.c -o lang.o
. . .
#0 0x038fa404 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/usr/main-src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
#1 0x038f8720 llvm::sys::RunSignalHandlers() 
/usr/main-src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:98:18
#2 0x038acb8c HandleCrash 
/usr/main-src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:79:5
#3 0x038acb8c CrashRecoverySignalHandler(int) 
/usr/main-src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:392:51
#4 0x89f2ba58 handle_signal 
/usr/main-src/lib/libthr/thread/thr_sig.c:0:3
cc: error: clang frontend command failed with exit code 139 (use -v to see 
invocation)
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git 
llvmorg-14.0.5-0-gc12386ae247c)
Target: aarch64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg:  

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/lang-0c2772.c
cc: note: diagnostic msg: /tmp/lang-0c2772.sh
cc: note: diagnostic msg:  

*** [lang.o] Error code 139

make[3]: stopped in /usr/main-src/usr.sbin/config
.ERROR_TARGET='lang.o'
.ERROR_META_FILE='/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/obj-tools/usr.sbin/config/lang.o.meta'
.MAKE.LEVEL='3'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='cc  -O2 -pipe -fno-common -I. -I/usr/main-src/usr.sbin/config  
-DNDEBUG  -g -gz=zlib -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts 
-Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wthread-safety 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable  -mcpu=cortex-a53 -Qunused-arguments
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/legacy/usr/include
 -c lang.c -o lang.o; ;'
.CURDIR='/usr/main-src/usr.sbin/config'
.MAKE='make'
.OBJDIR='/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/obj-tools/usr.sbin/config'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='arm64'
MACHINE_ARCH='aarch64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/main-src/share/mk'
MAKE_VERSION='20220726'
PATH='/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/main-src'

aarch64 main [so: 14] upgrade native boot message: "sh: /usr/libexec/hyperv/hyperv_vfattach: not found"

[Mark Millard]

The upgrade was to (long output line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #65
main-n259064-f83db6441a2f-dirty: Sun Nov  6 17:08:00 PST 2022
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400073 1400073

This was a native FreeBSD boot on a HoneyComb, with hyperv not involved.

The sequencing of the message was:

. . .
Starting devd.
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Waiting 30s for the default route interface: ..(dpni0)
. . .

/usr/libexec/hyperv/ is empty:

# ls -Tla /usr/libexec/hyperv/
total 9
drwxr-xr-x   2 root  wheel   2 Apr  8 22:40:03 2021 .
drwxr-xr-x  10 root  wheel  68 Nov  6 20:31:00 2022 ..



===
Mark Millard
marklmi at yahoo.com

Re: Seeking an idiot's guide to etcupdate/mergemaster

[Graham Perrin]

etcupdate
=

On 06/11/2022 17:35, George Michaelson wrote:


I am probably alone in this


You're not alone.



… I find the … 
markers in the update diffs intensely confusing.


diff3 bracketing.

<<< is where a conflict begins,
>>> is where it ends.

Beyond that, it was difficult for me to find an explanation that's simple.

In the midst of a long page from twenty-nine years ago:

 
begins with simplicity.


 
(2016-08-05) puts diff3(1) in the context of etcupdate(8).


 
suggests a command that has no effect:


    info diff3



For people who prefer complexity, from the outset, when attempting to 
grasp (or remember) something that's new, or complex:




– the team includes Alice and Bob developing a recipe book with a soup 
with six ingredients, one of which is a common allergen – celery, 
garlic, onions, salmon, tomatoes, wine – things get chunky when both 
Alice and Bob differ from the original and neither Adam nor Eve are 
emitted; adapted from Khanna, S., Kunal, K., Pierce, B.C. (2007). A 
Formal Investigation of Diff3. In: Arvind, V., Prasad, S. (eds) FSTTCS 
2007: Foundations of Software Technology and Theoretical Computer 
Science. FSTTCS 2007. Lecture Notes in Computer Science, vol 4855. 
Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-77050-3_40


:-)



Given many merges are
large blocks, its almost impossible to keep context flitting about in
vi …






TL;DR the merge process for FreeBSD-update and like, can be intensely
confusing when you try to reconcile what it tells you about /etc/

-G

On Sun, Nov 6, 2022 at 12:07 PM Tomoaki AOKI  wrote:
…


OpenPGP_signature
Description: OpenPGP digital signature

linsysfs on /usr/src/sys (linsysfs, local)

[Graham Perrin]

On 29/10/2022 21:30, Graham Perrin wrote:


Subject: poudriere jail update from source: syscall.mk does not exist


After updating to yesterday's 
aba921bd9e1869dae9ae4cc6e0c048f997401034, I aimed for a routine update 
of the jail that I used for poudriere.



poudriere jail -u -J 1 -j main
…
===> lib/libc (install)
make[5]: "/usr/src/lib/libc/sys/Makefile.inc" line 9: Cannot open 
/usr/src/sys/sys/syscall.mk

make[5]: Fatal errors encountered -- cannot continue
make[5]: stopped in /usr/src/lib/libc
*** Error code 1
…



bdrewery and others in IRC helped me to realise an offending mount.


With linux_enable: YES,

root@mowa219-gjp4-8570p-freebsd:~ # mount | grep sys
linsysfs on /usr/src/sys (linsysfs, local)
root@mowa219-gjp4-8570p-freebsd:~ # exit
logout
% grep linsysfs /etc/fstab
# linsysfs  /compat/linux/sys   linsysfs 
rw 0 0
# linsysfs    /compat/ubuntu/sys  linsysfs 
rw,late    0 0

%


After linux_enable: NO and a reboot,

% sysrc -f /etc/rc.conf linux_enable
linux_enable: NO
% mount | grep sys
% date ; uname -aKU
Wed 2 Nov 2022 19:06:01 GMT
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #24 
main-n258900-aba921bd9e18: Sat Oct 29 14:39:59 BST 2022 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
amd64 1400073 1400073

% sudo service linux onestart
grahamperrin's password:
kldload: an error occurred while loading module linux. Please check 
dmesg(8) for more details.

/etc/rc.d/linux: WARNING: Unable to load kernel module linux
kldload: an error occurred while loading module linux64. Please check 
dmesg(8) for more details.

/etc/rc.d/linux: WARNING: Unable to load kernel module linux64
% mount | grep sys
linsysfs on /compat/linux/sys (linsysfs, local)
% sudo sysrc linux_enable="YES"
linux_enable: NO -> YES
%


With linux_enable: YES (re-enabled) and a reboot, the clobber of 
/usr/src/sys recurred.




Resolved through an OS update on 3rd November:

% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25 
main-n259004-2c10be9e06d4: Thu Nov  3 00:14:52 GMT 2022 
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
amd64 1400073 1400073




OpenPGP_signature
Description: OpenPGP digital signature

Re: How to disable ACPI? (on FreeBSD14 CURRENT)

[Mike Karels]

On 6 Nov 2022, at 16:47, Alexander Motin wrote:

> Hi Louis,
>
> You should not try to disable ACPI these days.  It was a recommendation in 
> some cases probably ~15 years ago, but for many years now modern systems 
> depend on ACPI for proper operation.  I have no idea what causes crash in 
> your case, but I would not expect it to end up good any way.
>
> I know nothing about GNOME, haven't touched it for many years, but it must be 
> it what makes your laptop to sleep.  FreeBSD itself does not implement such 
> automatic policies.

It could the BIOS also if this is a laptop.

Mike

> On 06.11.2022 09:04, louis.free...@xs4all.nl wrote:
>> I need to disable acpi and the indicated method for that is to add 
>> ^hint.acpi.0.disabled="1"^ in /boot/loader.conf .
>>
>> However that crashes my system !!
>>
>> Not only that, to make it work again I have to edit loader.conf on a system 
>> which does ^not start^.
>>
>> After a lot of searching Internet came to the help with, I could start the 
>> system again:
>>
>> 1. Select 3. Escape to loader prompt at the splash screen
>>
>> 2. Type set hint.acpi.0.disabled="0" on the loader prompt
>>
>> 3. Then type boot on the loader prompt
>>
>> edit the loader.conf
>>
>> Very very glad with that fix however
>>
>> However the problem is still there, no idea how to prevent the system from 
>> going to sleep (after about 10 minutes).
>>
>> No idea how to change those 10 minutes to a much longer time as well 
>>
>> Note that I have gnome as gui and use the system more or less as server and 
>> manage the machine partly local via the GUI and partly remote via SSH.
>>
>> Related to GNOME I did try ^gsettings set 
>> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, 
>> however that did not solve the problem as well.
>>
>> In the end there seems to two problems
>>
>> a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and
>>
>> b) a GNOME issue (switching the system off during user inactivity, which is 
>> bullshit for a server / for ssh-login / with multiple users).
>>
>> What IMHO apart from the screen lock, this is not a GNOME task but an OS  
>> function to be configured by the system administrator.
>>
>> A third problem, not to be addressed here, is that recovery from sleep mode 
>> does not work on my system as well (even not S1).
>>
>> Most important for the moment is that the system keeps running / is not 
>> going down after x-time !
>
> -- 
> Alexander Motin

Re: How to disable ACPI? (on FreeBSD14 CURRENT)

[Alexander Motin]

Hi Louis,

You should not try to disable ACPI these days.  It was a recommendation 
in some cases probably ~15 years ago, but for many years now modern 
systems depend on ACPI for proper operation.  I have no idea what causes 
crash in your case, but I would not expect it to end up good any way.


I know nothing about GNOME, haven't touched it for many years, but it 
must be it what makes your laptop to sleep.  FreeBSD itself does not 
implement such automatic policies.


On 06.11.2022 09:04, louis.free...@xs4all.nl wrote:
I need to disable acpi and the indicated method for that is to add 
^hint.acpi.0.disabled="1"^ in /boot/loader.conf .


However that crashes my system !!

Not only that, to make it work again I have to edit loader.conf on a 
system which does ^not start^.


After a lot of searching Internet came to the help with, I could start 
the system again:


1. Select 3. Escape to loader prompt at the splash screen

2. Type set hint.acpi.0.disabled="0" on the loader prompt

3. Then type boot on the loader prompt

edit the loader.conf

Very very glad with that fix however

However the problem is still there, no idea how to prevent the system 
from going to sleep (after about 10 minutes).


No idea how to change those 10 minutes to a much longer time as well 

Note that I have gnome as gui and use the system more or less as server 
and manage the machine partly local via the GUI and partly remote via SSH.


Related to GNOME I did try ^gsettings set 
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, 
however that did not solve the problem as well.


In the end there seems to two problems

a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! 
! and


b) a GNOME issue (switching the system off during user inactivity, which 
is bullshit for a server / for ssh-login / with multiple users).


What IMHO apart from the screen lock, this is not a GNOME task but an 
OS  function to be configured by the system administrator.


A third problem, not to be addressed here, is that recovery from sleep 
mode does not work on my system as well (even not S1).


Most important for the moment is that the system keeps running / is not 
going down after x-time !


--
Alexander Motin

Re: trpt(8) to be decomissioned

[Gleb Smirnoff]

  Chris,

On Fri, Nov 04, 2022 at 10:35:17AM -0700, Chris wrote:
C> > the reason I want to retire it is not that it consumes 40 Kb
C> > in the repository.  The reason is that knows kernel structures,
C> > and fails to compile after changes to them.  So the tool that
C> > nobody uses requires special care when working on TCP.  The
C> > kernel headers disclose the structures for trpt (with some
C> > protection with _WANT_TCPCB, though) and some software from
C> > ports (not calling names!) would start use them too. Now a
C> > kernel developer needs to care not only about trpt, but
C> > about this software, too.
C> > 
C> > On the kernel side there is also TCPDEBUG code that needs
C> > to be kept compilable, while apparently nobody uses it.
C> While I really hate hearing that small utils
C> (almost elegant in their simplicity) that have worked perfectly
C> well for a great many years must be kicked to the curb. I guess
C> I can see your point. However I think TCPDEBUG affects a great
C> deal more that trpt(8). I hope your not implying that it should
C> go as well.

I'd like to hear use scenarios of TCPDEBUG without trpt. What does
it provide that other logging facilities (BB, DTrace) doesn't?

-- 
Gleb Smirnoff

Re: Seeking an idiot's guide to etcupdate/mergemaster

[George Michaelson]

I am probably alone in this but I find the CVS style 
markers in the update diffs intensely confusing. Given many merges are
large blocks, its almost impossible to keep context flitting about in
vi to find the old/new insertions. The odd thing is that post edit,
the view you get afterward is traditional diff/patch mode, so its
really bizarre: shown one way in edit mode, shown another in review
mode before commit.

There are far more urgent problems than fixing my 61 year old diff
format confusion, I don't think this justifies a bug report.

TL;DR the merge process for FreeBSD-update and like, can be intensely
confusing when you try to reconcile what it tells you about /etc/

-G

On Sun, Nov 6, 2022 at 12:07 PM Tomoaki AOKI  wrote:
>
> On Sat, 5 Nov 2022 20:12:04 -0700
> bob prohaska  wrote:
>
> > On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> > >
> > > Your /etc/rc.d/ldconfig script seems to have not been updated
> > > by use of etcupdate or mergemaster or other such. (How much
> > > else is also out of date? How much of what you have for /etc/
> > > and the like goes back to 2022-Jan-07 or before?)
> > >
> >
> > Alas, that is too true. The system was set up on July 2, 2020
> > and I've never managed to make sense of either mergemaster nor
> > etcupdate. Far as I could tell it didn't matter, the host ran
> > correctly, until now.
> >
> > It's been transplanted to a new hard drive, which allows the
> > installation of a ports tree. Ports don't install because of
> > the stale /etc/rc.d/ldconfig file.
> >
> > Since no changes have been made to /etc/ apart from /etc/rc.conf
> > is it possible to simply let mergemaster or etcupdate install
> > the latest defaults? I have looked at the manpage for etcupdate
> > and didn't recognize any straightforward way to simply accept
> > all updates. This particular system is expendable, so I'd be
> > glad to try things that might not work well, or at all.
> >
> > Apologies if I'm being dumb (probably guilty) or lazy (definitely
> > guilty). The barrage of questions generated by etcupdate  and
> > mergemaster is simply overwhelming. And, I suspect, largely
> > unnecessary.
> >
> > Thanks for reading!
> >
> > bob prohaska
>
> For a relatively casual way.
>
> If I'm facing the same situation, I will...
>
>  1. `mergemaster -UFiP` for now, then...
>  2. `etcupdate extract -B` for next upgrade.
>
> And on next upgrade, `etcupdate -p` before installing upgrade,
> and then `etcupdate -B` after install.
> You can add -n for dry-run before actual etcupdate.
>
>
> For some notes:
> mergemaster, the old and less maintained tool, uses current installation
> and updated tree. Old dedault state is not at all considered.
>
> So it could be used for already-updated states.
>
> etcupdate, the currently maintained tool, uses previous and updated
> defaults, and current installation (working environment).
> It compares differences between old and new default, check if the
> differences can be sanely applicable to currently working environment
> or not, and if it's sane, apply the diff automatically.
> If any conflict happenes, ask the admin (this case, you) for actions.
>
> So it requires previous default state, thus cannot use for this case,
> except you are sure what the actual previous revision was and can
> prepare the source tree (possibly obj tree, too?) and somehow create
> "current" tree ATM (will be turned over to "previous" tree on etcupdate
> run).
>
> See manpages for detail.
>
> --
> Tomoaki AOKI
>

Re: SAMBA 416-4.16.6 ad GNOME together is impossible :(

[Paul Mather]

On Nov 6, 2022, at 9:20 AM,   
wrote:

> I try to get FreeBSD14 current running with both
> - GNOME
> - SAMBA
> That seems to be impossible ☹  GNOME and SAMBA416 seems to be conflicting ! 
> I need SAMBA416 since SAMBA413 is simply not working :(
>  
> Installing SAMBA does remove GNOME components and vice versa.
>  
> How to work around this !!??
> So, that is a squeeze which urgently need repair IMHO
>  
> Louis
>  
>  
> pkg install samba416-4.16.6
> Message from samba416-4.16.6
> [1/4] Deinstalling gnome-shell-42.4_1...
> [1/4] Deleting files for gnome-shell-42.4_1: 100%
> [2/4] Deinstalling gnome-control-center-43.0...
> [2/4] Deleting files for gnome-control-center-43.0: 100%
> [3/4] Deinstalling samba413-4.13.17_4...
> [3/4] Deleting files for samba413-4.13.17_4: 100%
> [4/4] Installing samba416-4.16.6...
> [4/4] Extracting samba416-4.16.6: 100%
>  
> And then I have a fatal GNOME problem, and I have to install GNOME shell
> Nov  6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 deinstalled
> Nov  6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 installed
> Nov  6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 installed
> Nov  6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 installed
>  
> SAMBA and GNOME are both working ….. apart from each other. 
> Where SAMBA is not yet 100% ok e.g. it indicates that the config is not ok 
> where testparm says it is ok 


I am not using GNOME, but I am using Samba 4.16 and it coexists with other 
ports for me.  I suspect the problem is that GNOME is being built against the 
current default for Samba (4.13) and so GNOME has the 4.13 version as a 
dependency.  Samba 4.16 and 4.13 conflict against each other, so when you try 
and install Samba 4.16 it will uninstall Samba 4.13 (and GNOME, which depends 
upon it).  Conversely, if you install GNOME it will uninstall Samba 4.16 to 
make way for its Samba 4.13 dependency.

The way to fix this is to have your ports build against a common default 
version of Samba.  In my case, I build ports locally using Poudriere and added 
"samba=4.16" to the "DEFAULT_VERSIONS" definition in make.conf for that 
Poudriere ports jail.  So, any ports that build against Samba will use Samba 
4.16 as a dependency, not 4.13.

If you are using FreeBSD repositories, you might have to wait for Samba to 
switch to 4.16 in /usr/ports/Mk/bsd.default-versions.mk before GNOME/Samba 
ports shake out the way you like.

Cheers,

Paul.

SAMBA 416-4.16.6 ad GNOME together is impossible :(

[louis.freebsd]

I try to get FreeBSD14 current running with both

- GNOME

- SAMBA

That seems to be impossible ☹  GNOME and SAMBA416 seems to be conflicting ! 

I need SAMBA416 since SAMBA413 is simply not working :(

 �

Installing SAMBA does remove GNOME components and vice versa.

 �

How to work around this !!??

So, that is a squeeze which urgently need repair IMHO

 �

Louis

 �

 �

pkg install samba416-4.16.6

Message from samba416-4.16.6

[1/4] Deinstalling gnome-shell-42.4_1...

[1/4] Deleting files for gnome-shell-42.4_1: 100%

[2/4] Deinstalling gnome-control-center-43.0...

[2/4] Deleting files for gnome-control-center-43.0: 100%

[3/4] Deinstalling samba413-4.13.17_4...

[3/4] Deleting files for samba413-4.13.17_4: 100%

[4/4] Installing samba416-4.16.6...

[4/4] Extracting samba416-4.16.6: 100%

 �

And then I have a fatal GNOME problem, and I have to install GNOME shell

Nov  6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 deinstalled

Nov  6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 installed

Nov  6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 installed

Nov  6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 installed

 �

SAMBA and GNOME are both working ….. apart from each other. 

Where SAMBA is not yet 100% ok e.g. it indicates that the config is not ok 
where testparm says it is ok 

How to disable ACPI? (on FreeBSD14 CURRENT)

[louis.freebsd]

I need to disable acpi and the indicated method for that is to add 
^hint.acpi.0.disabled="1"^ in /boot/loader.conf .

However that crashes my system !! 

Not only that, to make it work again I have to edit loader.conf on a system 
which does ^not start^.  

 �

After a lot of searching Internet came to the help with, I could start the 
system again:

1. Select 3. Escape to loader prompt at the splash screen

2. Type set hint.acpi.0.disabled="0" on the loader prompt

3. Then type boot on the loader prompt

edit the loader.conf

Very very glad with that fix however

 �

However the problem is still there, no idea how to prevent the system from 
going to sleep (after about 10 minutes).

No idea how to change those 10 minutes to a much longer time as well  

 �

Note that I have gnome as gui and use the system more or less as server and 
manage the machine partly local via the GUI and partly remote via SSH.

 �

Related to GNOME I did try ^gsettings set 
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, however 
that did not solve the problem as well.

 �

In the end there seems to two problems

a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and 

b) a GNOME issue (switching the system off during user inactivity, which is 
bullshit for a server / for ssh-login / with multiple users).

What IMHO apart from the screen lock, this is not a GNOME task but an OS  
function to be configured by the system administrator.

 �

A third problem, not to be addressed here, is that recovery from sleep mode 
does not work on my system as well (even not S1).

 �

Most important for the moment is that the system keeps running / is not going 
down after x-time ! 

 �

Louis

Build error in FreeBSD head, main-n259058-105019e0d6c -> main-n259061-b1258b76435

[David Wolfskill]

And the only commit after main-n259061-b1258b76435 so far is
004bb636ca65f3239da284c20abb7f9d1d953dee, which claims:

| tcp: Move sysctl OIDs related to ECN to tcp_ecn.
| Keep all ECN related code in (mostly) one place.
| 
| No functional change.

I'm seeing:

...
building shared library libBIG5.so.5
Building 
/common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/DECHanyu/libDECHanyu.so.5.full
In file included from /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:56:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
warning: declaration of 'struct tcpcb' will not be visible outside of this 
function [-Wvisibility]
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
Building 
/common/S4/obj/usr/src/amd64.amd64/lib/googletest/gtest/libprivategtest.a
building static gtest library
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:19: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
   ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:34: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:15: 
error: incomplete definition of type 'struct tcpcb'
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:30: 
error: incomplete definition of type 'struct tcpcb'
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
 ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
1 warning and 4 errors generated.
building static devdctl library
Building 
/common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/EUC/libEUC.so.5.full
In file included from /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:56:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
warning: declaration of 'struct tcpcb' will not be visible outside of this 
function [-Wvisibility]
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:19: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
   ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:34: 
error: incomplete definition of type 'struct tcpcb'
return ((ack - tp->snd_una) / tp->t_maxseg +
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:15: 
error: incomplete definition of type 'struct tcpcb'
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
  ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:30: 
error: incomplete definition of type 'struct tcpcb'
Building /common/S4/obj/usr/src/amd64.amd64/lib/libwrap/libwrap.a
ack - tp->snd_una) % tp->t_maxseg) != 0) ? 1 : 0));
 ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29: 
note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
^
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdwarf/dwarf_funcs.pico
building static wrap library
building shared library 

Re: Seeking an idiot's guide to etcupdate/mergemaster

[Tomoaki AOKI]

On Sat, 5 Nov 2022 20:12:04 -0700
bob prohaska  wrote:

> On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> > 
> > Your /etc/rc.d/ldconfig script seems to have not been updated
> > by use of etcupdate or mergemaster or other such. (How much
> > else is also out of date? How much of what you have for /etc/
> > and the like goes back to 2022-Jan-07 or before?)
> >
>  
> Alas, that is too true. The system was set up on July 2, 2020
> and I've never managed to make sense of either mergemaster nor
> etcupdate. Far as I could tell it didn't matter, the host ran
> correctly, until now.
> 
> It's been transplanted to a new hard drive, which allows the
> installation of a ports tree. Ports don't install because of
> the stale /etc/rc.d/ldconfig file.
> 
> Since no changes have been made to /etc/ apart from /etc/rc.conf
> is it possible to simply let mergemaster or etcupdate install
> the latest defaults? I have looked at the manpage for etcupdate
> and didn't recognize any straightforward way to simply accept
> all updates. This particular system is expendable, so I'd be
> glad to try things that might not work well, or at all. 
> 
> Apologies if I'm being dumb (probably guilty) or lazy (definitely
> guilty). The barrage of questions generated by etcupdate  and
> mergemaster is simply overwhelming. And, I suspect, largely 
> unnecessary.   
>  
> Thanks for reading!
> 
> bob prohaska

For a relatively casual way.

If I'm facing the same situation, I will...

 1. `mergemaster -UFiP` for now, then...
 2. `etcupdate extract -B` for next upgrade.

And on next upgrade, `etcupdate -p` before installing upgrade,
and then `etcupdate -B` after install.
You can add -n for dry-run before actual etcupdate.


For some notes:
mergemaster, the old and less maintained tool, uses current installation
and updated tree. Old dedault state is not at all considered.

So it could be used for already-updated states.

etcupdate, the currently maintained tool, uses previous and updated
defaults, and current installation (working environment).
It compares differences between old and new default, check if the
differences can be sanely applicable to currently working environment
or not, and if it's sane, apply the diff automatically.
If any conflict happenes, ask the admin (this case, you) for actions.

So it requires previous default state, thus cannot use for this case,
except you are sure what the actual previous revision was and can
prepare the source tree (possibly obj tree, too?) and somehow create
"current" tree ATM (will be turned over to "previous" tree on etcupdate
run).

See manpages for detail.

-- 
Tomoaki AOKI

RE: Seeking an idiot's guide to etcupdate/mergemaster

[Mark Millard]

bob prohaska  wrote on
Date: Sun, 06 Nov 2022 03:12:04 UTC :

> On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> > 
> > Your /etc/rc.d/ldconfig script seems to have not been updated
> > by use of etcupdate or mergemaster or other such. (How much
> > else is also out of date? How much of what you have for /etc/
> > and the like goes back to 2022-Jan-07 or before?)
> >
> 
> Alas, that is too true. The system was set up on July 2, 2020
> and I've never managed to make sense of either mergemaster nor
> etcupdate. Far as I could tell it didn't matter, the host ran
> correctly, until now.
> 
> It's been transplanted to a new hard drive, which allows the
> installation of a ports tree. Ports don't install because of
> the stale /etc/rc.d/ldconfig file.
> 
> Since no changes have been made to /etc/ apart from /etc/rc.conf
> is it possible to simply let mergemaster or etcupdate install
> the latest defaults? I have looked at the manpage for etcupdate
> and didn't recognize any straightforward way to simply accept
> all updates. This particular system is expendable, so I'd be
> glad to try things that might not work well, or at all. 
> 
> Apologies if I'm being dumb (probably guilty) or lazy (definitely
> guilty). The barrage of questions generated by etcupdate and
> mergemaster is simply overwhelming. And, I suspect, largely 
> unnecessary.   


[We will see if this helps or not . . .]

Before worrying about the actual updates, I'd start by just
establishing a set of default files to look at.

There are 2 contexts overall:

A) The source commit vintage for the live system
vs.
B) The source commit vintage for the update to be installed
   at some point

At this point I'm only dealing with (A).

Is your /usr/src/ the proper content for (A)? (B)? Something
else?

If you do not have a /usr/src/ that is the proper content for
(A), then you need to create a directory tree that does contain
such a source tree, such as via using git or other such to
establish the source tree.

I'll refer to: /usr/livesrc/ 

The command:

# etcupdate extras -s /usr/livesrc

will create: /var/db/etcupdate/current/

There you can look at the various default file contents.
More than /etc/ material will be present, for example:

/var/db/etcupdate/current/.cshrc
/var/db/etcupdate/current/.profile
/var/db/etcupdate/current/COPYRIGHT
/var/db/etcupdate/current/root/.cshrc
/var/db/etcupdate/current/root/.k5login
/var/db/etcupdate/current/root/.login
/var/db/etcupdate/current/root/.profile
/var/db/etcupdate/current/root/.shrc
/var/db/etcupdate/current/usr/share/nls/POSIX
/var/db/etcupdate/current/usr/share/nls/en_US.US_ASCII
/var/db/etcupdate/current/var/crash/minfree

Some files that you create or edit might not show up
under current/ at all. ( /etc/fstab and /etc/rc.conf
would be examples. )

You might not want to look at all the mismatches. But
you might want to look at the output of something like:

# find -s /var/db/etcupdate/current/ -print | more

to see if it reminds you of any files that you do want
preserve a copy of the old content of for reference. An
example might be: /etc/sysctl.conf
There could be others.

I'd expect that the following sort of command sequence
would mostly replace the live system's files with the
defaults (presumes done as root to be sure that files
are replaceable):

# cd /var/db/etcupdate/current/
# cp -aRx . /

However, there might be questions about hard links and
softlinks in the from-side or the to-side and how
things end up with such involved (after the cp -aRx
completes).

Note that you may have more build installs around that
you might need to be sure that they track, such as
directories for chroot use. This can get into using
command line options that indicate context so that
each context gets its own tracking. It should also
change things, like /var/db/etcupdate/current/
to have a path prefix involved:

/PATHPREFIX/var/db/etcupdate/current/

As for updates, I have scripts that do something like:

# #PRIOR source update and buildworld buildkernel ACTIVITY HERE.
# etcupdate . . . -p
# etcupdate . . . resolve -p
# make . . . installkernel . . .
# make . . . installworld . . .
# etcupdate
# etcupdate resolve
# make . . . delete-old check-old -DBATCH_DELETE_OLD_FILES

Note: delete-old-libs may need to be in its own time frame,
  after one is sure that those libraraies are no longer
  in use so that the delete will not break anything.

# etcupdate status
# etcupdate resolve

However, being paranoid, I use a script that runs each
etcupdate command with a context specified. An example
is:

env __MAKE_CONF="/usr/home/root/src.configs/make.conf" \
SRCCONF="/dev/null" 
SRC_ENV_CONF="/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host"
 \
MAKEOBJDIRPREFIX="/tmp/usr/obj/BUILDs/main-CA72-nodbg-clang" \
etcupdate $* -s /usr/main-src -M TARGET_ARCH=aarch64

Note the $* which is where the command line arguments to the
script would go.

Similarly for my make commands:

kldload -n