Re: New console output at boot?

[Ronald Klop]

Van: Thomas Laus 
Datum: woensdag, 25 september 2024 15:37
Aan: freebsd-current@freebsd.org
Onderwerp: Re: New console output at boot?


On 9/25/24 08:03, Ronald Klop wrote:
> Hi,
>
> Nice work. I did the video trick also in the past with boot issues.
>
> Can you tell us what the errors are? Like what filenames are mentioned. > 
Maybe post the screenshot of the video somewhere.
>
> My /boot/fonts on raspberry pi 4 15.0-CURRENT contains.
> $ ls -l /boot/fonts/
> total 187
> -r--r--r--  1 root wheel 15355 Jul  7  2023 10x18.fnt.gz
> -r--r--r--  1 root wheel 15579 Jul  7  2023 10x20.fnt.gz
> -r--r--r--  1 root wheel 16772 Jul  7  2023 11x22.fnt.gz
> -r--r--r--  1 root wheel 17078 Jul  7  2023 12x24.fnt.gz
> -r--r--r--  1 root wheel 17158 Jul  7  2023 14x28.fnt.gz
> -r--r--r--  1 root wheel 20084 Jul  7  2023 16x32.fnt.gz
> -r--r--r--  1 root wheel  5874 Jul  7  2023 6x12.fnt.gz
> -r--r--r--  1 root wheel 12452 Jul  7  2023 8x14.fnt.gz
> -r--r--r--  1 root wheel  6472 Jul  7  2023 8x14v.fnt.gz
> -r--r--r--  1 root wheel 12604 Jul  7  2023 8x16.fnt.gz
> -r--r--r--  1 root wheel  6536 Jul  7  2023 8x16b.fnt.gz
> -r--r--r--  1 root wheel  6568 Jul  7  2023 8x16v.fnt.gz
> -r--r--r--  1 root wheel  2087 Aug 26  2023 INDEX.fonts
>
I have those exact fonts in my /boot/fonts/ that you do.  The file sizes are 
the same but my dates are all July 24, 2023.  It looks to me that either 
gptzfsboot should not look for some fonts or the buildworld process should 
install whatever gptzfsboot requires.  My cellphone video only has this visible 
for a few frames and the entire video only lasts 5 seconds after typing in my 
GELI password until the boot menu is displayed.

Tom


--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
 







I think it is still valuable to other developers if you could show us what the 
exact error messages are.

Ronald.

Re: New console output at boot?

[Ronald Klop]

Hi,

Nice work. I did the video trick also in the past with boot issues.

Can you tell us what the errors are? Like what filenames are mentioned. Maybe 
post the screenshot of the video somewhere.

My /boot/fonts on raspberry pi 4 15.0-CURRENT contains.
$ ls -l /boot/fonts/
total 187
-r--r--r--  1 root wheel 15355 Jul  7  2023 10x18.fnt.gz
-r--r--r--  1 root wheel 15579 Jul  7  2023 10x20.fnt.gz
-r--r--r--  1 root wheel 16772 Jul  7  2023 11x22.fnt.gz
-r--r--r--  1 root wheel 17078 Jul  7  2023 12x24.fnt.gz
-r--r--r--  1 root wheel 17158 Jul  7  2023 14x28.fnt.gz
-r--r--r--  1 root wheel 20084 Jul  7  2023 16x32.fnt.gz
-r--r--r--  1 root wheel  5874 Jul  7  2023 6x12.fnt.gz
-r--r--r--  1 root wheel 12452 Jul  7  2023 8x14.fnt.gz
-r--r--r--  1 root wheel  6472 Jul  7  2023 8x14v.fnt.gz
-r--r--r--  1 root wheel 12604 Jul  7  2023 8x16.fnt.gz
-r--r--r--  1 root wheel  6536 Jul  7  2023 8x16b.fnt.gz
-r--r--r--  1 root wheel  6568 Jul  7  2023 8x16v.fnt.gz
-r--r--r--  1 root wheel  2087 Aug 26  2023 INDEX.fonts

An RPI3 running 14.1-RELEASE has the same filenames with the same sizes but 
with a date of May 2022. I didn't compare the content of the files.
I'm not sure how they end up in that directory.

In the FreeBSD sources I could only find share/syscons/fonts which contains 
some *.fnt files. I don't know if these are the same files as in /boot/fonts.

Regards,
Ronald.


Van: Thomas Laus 
Datum: woensdag, 25 september 2024 13:42
Aan: freebsd-current@freebsd.org
Onderwerp: Re: New console output at boot?


On 9/24/24 15:26, Warner Losh wrote:
>
> Thinking about it, I found a hole. If gptzfsboot picked the wrong BE > this 
could happen. And updating it might fix a bug that's causing it. > Knowing when your 
system last updated the gptzfsboot would be useful...
>
After getting a hint to use my cellphone camera to capture the error messages, 
the errors all indicate missing fonts in /boot/fonts.  How does this directory 
get populated when building world?  All of the fonts in this directory date 
back to July 24, 2023 and nothing newer.

Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
 

Re: powerd forgets top CPU frequency ?

[Ronald Klop]

Van: Poul-Henning Kamp 
Datum: zondag, 25 augustus 2024 10:29
Aan: Ronald Klop 
CC: Bob Bishop , "curr...@freebsd.org" 
Onderwerp: Re: powerd forgets top CPU frequency ?


----
Ronald Klop writes:

> A bit weird to try to give suggestions knowing how experienced you are in 
FreeBSD. But here we go,

I'm not very experienced with how modern CPU's are modulated :-)

> 1. What does the sysctl about cpu frequencies say. Does that value decrease 
too?
> On my machine it is this:
> # sysctl dev.cpu  | grep freq
> dev.cpu.0.freq_levels: 1500/-1 600/-1
> dev.cpu.0.freq: 1500

Right now:
dev.cpu.7.freq_levels: 2803/-1
dev.cpu.7.freq: 3103
dev.cpu.5.freq_levels: 2803/-1
dev.cpu.5.freq: 3103
dev.cpu.3.freq_levels: 2803/-1
dev.cpu.3.freq: 3103
dev.cpu.1.freq_levels: 2803/-1
dev.cpu.1.freq: 3103
dev.cpu.6.freq_levels: 2803/-1
dev.cpu.6.freq: 3103
dev.cpu.4.freq_levels: 2803/-1
dev.cpu.4.freq: 3103
dev.cpu.2.freq_levels: 2803/-1
dev.cpu.2.freq: 3103
dev.cpu.0.freq_levels: 2803/-1
dev.cpu.0.freq: 3103

> 2. Does https://www.freshports.org/sysutils/powerdxx/ exhibit the same issue? 
To rule out if it is in the binary or in the kernel.

Will try.

> 3. out-of-the-box: are your CPUs similar? So, do both have the same top 
frequency?

Yes, it's a: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz

> 4. And powerd(8) mentions a -v option: "Verbose mode.  Messages about power 
changes will be printed to stdout and powerd will operate in the foreground."
> Does that print anything useful?

Yes, that's where I noticed the "gradually run slower and slower"...

Initially I thought it was some kind of thermal throttling, but leaving the 
computer
idle overnight did not lead to automatic recovery, whereas reboots and as far 
as I
can tell, restarting powerd does.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.







   dev.cpu.7.freq_levels: 2803/-1
   dev.cpu.7.freq: 3103


This is interesting by itself. According to the sysctl the CPU only has 1 
frequency to select, which is 2803, but it is running on 3103. Maybe there is 
some other mechanism which influences the CPU freq on your machine. I hope 
somebody else can shine some light on this.
Doesn't the output (or source) of powerd give some insight on why it makes the 
decisions it makes?

Regards,
Ronald.

Re: powerd forgets top CPU frequency ?

[Ronald Klop]

Van: Poul-Henning Kamp 
Datum: zondag, 25 augustus 2024 07:13
Aan: Bob Bishop 
CC: "curr...@freebsd.org" 
Onderwerp: Re: powerd forgets top CPU frequency ?



Bob Bishop writes:

> Possibly buggy ACPI on the Thinkpad not reporting any frequency higher
> than it's actually running at?

But that wouldn't explain why restarting powerd helps ?


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
 







Hi,

A bit weird to try to give suggestions knowing how experienced you are in 
FreeBSD. But here we go,

1. What does the sysctl about cpu frequencies say. Does that value decrease too?
On my machine it is this:
# sysctl dev.cpu  | grep freq
dev.cpu.0.freq_levels: 1500/-1 600/-1
dev.cpu.0.freq: 1500

2. Does https://www.freshports.org/sysutils/powerdxx/ exhibit the same issue? 
To rule out if it is in the binary or in the kernel.

3. out-of-the-box: are your CPUs similar? So, do both have the same top 
frequency?

4. And powerd(8) mentions a -v option: "Verbose mode.  Messages about power changes 
will be printed to stdout and powerd will operate in the foreground."
Does that print anything useful?

Regards,
Ronald.

Re: Missing Drivers?

[Ronald Klop]

Van: Larry Rosenman 
Datum: zondag, 25 augustus 2024 01:33
Aan: Freebsd current 
Onderwerp: Re: Missing Drivers?


anyone?

On 08/21/2024 9:40 am, Larry Rosenman wrote:
> Any chance of getting Bluetooth working on this box and/or any other > 
missing pieces?
>
> dmesg.boot: https://www.lerctr.org/~ler/ryzen/dmesg.boot
> pciconf -lv: https://www.lerctr.org/~ler/ryzen/pciconf.txt
>
> Thanks1

--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
 




 


ubt0 on uhub1
ubt0:  on 
usbus1
ubt1 on uhub1
ubt1:  on 
usbus1
ubt1: ubt_attach:674: could not get two interfaces
device_attach: ubt1 attach returned 6
ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command 
OGF=0x3, OCF=0x3. Timeout

Device ubt0 seems to attach properly (at least no errors). Can you disable ubt1 
and just use ubt0?

Re: GENERIC boot hangs on `enabling pf`

[Ronald Klop]

Van: Alexander Ziaee 
Datum: 24 augustus 2024 21:56
Aan: freebsd-current 
Onderwerp: GENERIC boot hangs on `enabling pf`




Hi everyone,

On a new laptop GENERIC sometimes hangs on `enabling pf`. When it does, 
ctrl-alt-del or the power button will begin power off, but hangs on 
`uhub0:detached` after `uptime: 6m39s`. Sometimes it does this multiple boots 
in a row. Usually at least once out of every ten times.

My old laptop doesn't ever do this. It takes 14hrs to makeworld and dies randomly 
so I only try to update it during stabilization week (<3 for stabilization 
week).

This is my hobby laptop for working on freebsd, so it is available for any and 
all testing that may be helpful, but I don't know where to begin with this type 
of issue.

Best,
Alex






What version of freebsd?
Do you have a pf config?
If it hangs what does ctrl-t output?

Regards,
Ronald

Re: exited on signal 11 (no core dump - other error)

[Ronald Klop]

Van: Konstantin Belousov 
Datum: vrijdag, 12 juli 2024 13:15
Aan: FreeBSD Current 
Onderwerp: Re: exited on signal 11 (no core dump - other error)


On Fri, Jul 12, 2024 at 10:45:31AM +, Dave Cottlehuber wrote:
> On Fri, 12 Jul 2024, at 03:39, Zhenlei Huang wrote:
> > Hi
> >
> > I observed something weird on Release 14.1.
> >
> > When rebooting my dev machine, I got
> > ...
> > IIUC all processes will get signal to quit on system reboot. But what does 
the
> > signal 11 mean ? Is it EDEADLK in sys/sys/errno.h ?
> >
> > If yes, then why they get dead locked ?
>
> I see the same on 15.0-CURRENT too here. In my case this is just after 
syslog-ng is stopped.
>
> <6>[1920] pid 6090 (wezterm-gui), jid 0, uid 1002: exited on signal 11 (no 
core dump - other error)
> <6>[1920] pid 6039 (polkitd), jid 0, uid 565: exited on signal 11 (no core 
dump - bad address)
> <6>[1920] pid 4306 (dbus-daemon), jid 0, uid 556: exited on signal 11 (no 
core dump - bad address)

Most natural cause for SIGSEGV during shutdown is because root is unmounted
while the processes are still handling signals (SIGTERM) from init.  The
text vnodes for the process binary and shared libraries are force-reclaimed,
and any page-in request results in the unhandled fault.

I regularly see these SIGSEGVs on nfs-booted crash boxes.
 







I can also easily reproduce this on my RPI4/15-CURRENT using 2 ZFS disks via 
USB.
Just did a shutdown -r now to check and appended the serial output here.

FreeBSD/arm64 (rpi4) (ttyu0)   
  
login: Jul  7 23:47:46 rpi4 shuStopping jails: jail14 jail13 jenkins monitoring loghost.   
Stopping node_exporter.
Stopping sshd. 
Waiting for PIDS: 1910.
Stopping cron. 
Waiting for PIDS: 1863.
Stopping powerd.   
Waiting for PIDS: 1832.

Stopping rtsold.
Waiting for PIDS: 1484.
Stopping devd.
Waiting for PIDS: 1475.
Writing RTC file: /var/db/fakertc.
Writing entropy file: .
Writing early boot entropy file: .
.
Terminated
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 0 done
All buffers synced.
pid 23288 (sshd), jid 0, uid 1001: exited on signal 4 (no core dump - bad 
address)
pid 23329 (bash), uid (0):  Path `/var/tmp/0.bash.0.23329.core' failed on 
initial open test, error = 2
pid 23286 (sshd), jid 0, uid 0: exited on signal 4 (no core dump - bad address)
pid 23329 (bash), jid 0, uid 0: exited on signal 4 (no core dump - other error)
pid 23328 (su), jid 0, uid 0: exited on signal 4 (no core dump - bad address)
pid 23289 (bash), uid (1001):  Path `/var/tmp/1001.bash.0.23289.core' failed on 
initial open test, error = 2
pid 23289 (bash), jid 0, uid 1001: exited on signal 4 (no core dump - other 
error)
Uptime: 23h48m34s
Resetting system ... pid 1769 (syslogd), uid (0):  Path 
`/var/tmp/0.syslogd.0.1769.core' failed on initial open test, error = 2
pid 1769 (syslogd), jid 0, uid 0: exited on signal 4 (no core dump - other 
error)

To me it looks like the sshd process in which I typed 'shutdown -r now' is 
still available somehow.

Regards,
Ronald.

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Ronald Klop]

Van: Poul-Henning Kamp 
Datum: woensdag, 12 juni 2024 12:39
Aan: Ronald Klop 
CC: curr...@freebsd.org
Onderwerp: Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure 
out


Ronald Klop writes:

> What do you thing about defaulting to /32 on a missing netmask?
> An interface with 1 IP address without any information about the network. All 
traffic can go to the gateway.

I dont think that will work ?

The gateway will not be inside any of the attached networks, so you have no 
route to it ?

Poul-Henning

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.






Ai. Of course. Typed quicker than I was thinking. :-)

Well. Then it is maybe best to just error out on boot with a misconfigured 
network. Or revert back to the pre-14.1 behavior because of POLA.
I'll leave it up to you and will make sure I configure my interfaces with a 
netmask.

Regards,
Ronald.

Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

[Ronald Klop]

Van: Poul-Henning Kamp 
Datum: woensdag, 12 juni 2024 09:47
Aan: curr...@freebsd.org
Onderwerp: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.

The main symptom was that DNS was /really/ busted, which makes sense
when none of the DNS servers in the 192/8 "swamp" can be reached.

Since we all know that it is always DNS(SEC), I spent a lot of time
having fun with that, before I noticed the /8 netmask on the interface.

I agree that the class A/B/C netmask assumptions should have died long ago.

But from a foot-shooting point of view, it makes no sense to default
192.168/16 to a /8 netmask.

If we're going to default to /8, at the very least ifconfig should
spitting out a very noisy warning and wait 5 seconds before proceeding,
when the netmask is not explicitly specified.

But I also think we can do better than /8.

One option is to go for "limit the damage in RFC1918" and default
them according to their size: reach:

10/8
172.16/12
192.168/16

That will prevent the DNS weirdness I had to figure out, and probably
still DWIM in most cases.

Another option is to default all three to /24, which in my experience
is how people deploy RFC1918.

A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.

Poul-Henning

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
 







What do you thing about defaulting to /32 on a missing netmask?
An interface with 1 IP address without any information about the network. All 
traffic can go to the gateway.

Regards,
Ronald.

devd nomatch does not load uslcom anymore

[Ronald Klop]

Hi,

May 16th upgraded the kernel of my RPI4. Previous kernel was fom April 10th.

From:
FreeBSD 15.0-CURRENT #35 main-5716d902ae1: Wed Apr 10 22:59:37 CEST 2024

To:
FreeBSD 15.0-CURRENT #36 main-42b28f81521: Thu May 16 07:54:05 CEST 2024

Today I noticed my USB serial cable to my RPI3 was not available anymore. It 
hadn't loaded 'uslcom' at boot.
Adding 'hw.bus.devctl_nomatch_enabled=1' to /boot/loader.conf resolves the 
issue for now.

The proper output during boot is:
Starting devd.
Autoloading module: uslcom
uslcom0 on uhub1
uslcom0:  on usbus0

Does anybody need more information about this?

Regards,
Ronald.

Re: after trivial update, 15.0 ARM64 system no longer boots

[Ronald Klop]

I have no clue. But can you boot in “verbose” mode?

And as the last message is usb, can you remove all usb devices and boot again?


Regards,
Ronald

Van: Lexi Winter 
Datum: 15 maart 2024 16:57
Aan: freebsd-...@freebsd.org, freebsd-current@freebsd.org
Onderwerp: after trivial update, 15.0 ARM64 system no longer boots





hi lists,

i have a FreeBSD 15.0/arm64 system, an RPi4, which was previously
running 15.0 with pkgbase.  i rebuilt main on my pkg server and updated
the RPi with 'pkg update', which only included ~2 commits neither of
which seemed like they had anything to do with booting, but after the
update, the system no longer boots.

the problem seems to be a hang during kernel initialisation:

https://www.le-fay.org/tmp/30d/9fE0NG.jpeg

i am not really an expert on either ARM64 in general or on the RPi
hardware in particular.  could anyone suggest how i could debug this
problem, e.g. to get more information about why the system won't finish
booting?

thanks, lexi.

Re: vmm_load crashes to debugger early

[Ronald Klop]

Hi,

Can you mount /boot on another system?

Can you press a key to interrupt booting the kernel? I'm not sure what the name 
of this stage of the booting is called and if it depends on which bootloader 
you are using.

In my VM I get this on the text "Beastie"-menu with the text:


"Autoboot in 9 seconds. [Space] to pause".



"3. Escape to loader prompt"

<3>

Type '?' for a list of commands, 'help' for more detailed help.
OK

set vmm_load=NO

OK

unload vmm

OK

boot


You can use the command "lsmod" and "show" to see what modules are already 
loaded and what variables are used while booting.

I hope this helps.

Regards,
Ronald.


Van: void 
Datum: maandag, 22 januari 2024 12:46
Aan: freebsd-current@freebsd.org
CC: freebsd-virtualizat...@freebsd.org
Onderwerp: vmm_load crashes to debugger early


Hello,

On a very recent -current, vmm_load="YES" in /boot/loader.conf crashes
the system to debugger early on in the boot sequence. I can't even reach
single user mode

How can I prevent this one element of /boot/loader.conf from loading?

thanks in advance for any advice
--
 

Re: NFSv4 crash of CURRENT

[Ronald Klop]

Van: FreeBSD User 
Datum: 13 januari 2024 19:34
Aan: FreeBSD CURRENT 
Onderwerp: NFSv4 crash of CURRENT




Hello,

running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat 
Jan 13 18:08:32
CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client, 
other is FreeBSD
13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.

I can crash the client reproducable by accessing the one or other NFSv4 FS (a 
simple ls -la).
The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla access 
to the client
host, luckily the box recovers.

I have no idea what causes this problem ...

Kind regards,

O. Hartmann


--
O. Hartmann








Do you have something like a panic message, stack trace or core dump?

Regards
Ronald

Re: poudriere: swap_pager: out of swap space

[Ronald Klop]

On 1/11/24 03:21, Lexi Winter wrote:

hi list,

i'm having a recurring problem with poudriere that i hope someone might
have an idea about.

i'm building packages with poudriere on a system with 32GB memory, with
tmpfs and md disabled in poudriere (so it's using ZFS only) and with the
ZFS ARC limited to 8GB.

running poudriere produces many kernel log messages like this:

Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space
Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed
Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space
Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed
Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space
Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed
Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed
Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed

this is despite the system having a large amount of "Inact" memory
according to top(1):

Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, 892M Free
ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M Other
  1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio
Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse

from what i can tell, these swap errors don't cause any issues with the
poudriere build, but they do seem to hinder interactive usage by causing
long hangs.

does anyone have some idea what's going on here?  i don't really
understand why the system has used 100% of available swap space when it
has plenty of Inact memory it could free to fulfill requirements.



My first guess would be that you are using a tmpfs tmp dir which uses swap as 
the backing-storage which is now full.
Configure poudriere with USE_TMPFS=no to prevent this.

Hope this helps.

Regards,
Ronald.

Re: noatime on ufs2

[Ronald Klop]

Van: Olivier Certner 
Datum: woensdag, 10 januari 2024 11:01
Aan: Warner Losh 
CC: freebsd-current@freebsd.org
Onderwerp: Re: noatime on ufs2


Hi Warner,

> It has also been used for almost as long to see if log files have changed
> if you set your MAIL variable to that. So not just for email...

This seems to be an example in point of a "niche" scenario, both in terms of 
spread of usage (even then) and the fact that it's easy to get the functionality by other 
means.

Again, I'm not opposing anyone from working on "relatime" if they personally have a 
strong need and motivation.  I'm not even asking for removing the "atime" functionality, 
which can have its uses.

What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) 
experience and some late reflection, is that "noatime" should be the default (everywhere, all 
mounts and all FSes), and that working on "relatime" won't make any real difference for most users 
(IOW, I think that developing "relatime" is a bad idea *in general*).  And I think this is a 
sufficiently reasonable conclusion that anyone with the same inputs would conclude the same.  So, if it's not 
the case, I would be interested in knowing why, ideally.

Regards.

--
Olivier Certner



 



"And I think this is a sufficiently reasonable conclusion that anyone with the same 
inputs would conclude the same."

This is an interesting type of argument.

Ronald.

Re: NFS exports of ZFS snapshots broken

[Ronald Klop]

On 11/18/23 17:09, Rick Macklem wrote:

On Fri, Nov 17, 2023 at 8:19 PM Mike Karels  wrote:


On 17 Nov 2023, at 22:14, Mike Karels wrote:


On 17 Nov 2023, at 21:24, Rick Macklem wrote:


Most of the changes in stable/13 that are not in releng/13.2
are the "make it work in a jail" stuff. Unfortunately, they are
a large # of changes (mostly trivial edits adding vnet macros),
but it also includes export check changes.

I have attached a trivial patch that I think disables the export
checks for jails. If either of you can try it and see if it fixes
the problem, that would be great.
(Note that this is only for testing, although it probably does not
  matter unless you are running nfsd(8) in vnet jails.)


Yes, I can see snapshots with the patch.  This system is just a test
system that doesn't normally run ZFS or NFS, so no problem messing
with permissions.  It's a bhyve VM, so I just added a small disk and
enabled ZFS for testing.


btw, you might try to get mm@ or maybe mav@ to help out from the ZFS
side.  It must be doing something differently inside a snapshot than
outside, maybe with file handles or something like that.

Yes. I've added freebsd-current@ (although Garrett is not on it, he is
cc'd) and these guys specifically...

So, here's what appears to be the problem...
Commit 88175af (in main and stable/13, but not 13.2) added checks for
nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred
used when the file system is exported.
When mnt_exjail is found NULL, the current nfsd code assumes that there
is no access allowed for the mount.

My vague understanding is that when a ZFS snapshot is accessed, it is
"pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that
mnt_exjail is NULL as a result.
Since I do not know the ZFS code and don't even have an easy way to
test this (thankfully Mike can test easily), I do not know what to do from
here?

Is there a "struct mount" constructed for this pseudo mount
(or it actually appears to be the lookup of ".." that fails, so it
might be the parent of the snapshot subdir?)?

One thought is that I can check to see if the mount pointer is in the
mountlist (I don't think the snapshot's mount is in the mountlist) and
avoid the jail test for this case.  This would assume that snapshots are
always within the file system(s) exported via that jail (which includes
the case of prison0, of course), so that they do not need a separate
jail check.

If this doesn't work, there will need to be some sort of messing about
in ZFS to set mnt_exjail for these.

I will try and get a test setup going here, which leads me to..
how do I create a ZFS snapshot? (I do have a simple ZFS pool running
on a test machine, but I've never done a snapshot.)


# zfs list
...
zroot/usr/local4.59G  27.5G  2.76G  /usr/local
zroot/usr/ports1.03G  27.5G   952M  /usr/ports
...

# zfs snapshot zroot/usr/local@myfirstsnapshot
-- to view them
# zfs list -t snapshot zroot/usr/local
-- and to remove it:
# zfs destroy zroot/usr/local@myfirstsnapshot
-- more info
# man zfs-snapshot

If you get used to this you are going to love it. :-)

Regards and happy hacking,
Ronald.




Although this problem is not in 13.2, it will have shipped in 14.0.

Any help with be appreciated, rick



 Mike



rick

On Fri, Nov 17, 2023 at 6:14 PM Mike Karels  wrote:


CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca.


Rick, have you been following this thread on freebsd-stable?  I have been able
to reproduce this using a 13-stable server from Oct 7 and a 15-current system
that is up to date using NFSv3.  I did not reproduce with a 13.2 server.  The
client was running 13.2.  Any ideas?  A full bisect seems fairly painful, but
maybe you have an idea of points to try.  Fortunately, these are all test
systems that I can reboot at will.

 Mike

Forwarded message:


From: Garrett Wollman 
To: Mike Karels 
Cc: freebsd-sta...@freebsd.org
Subject: Re: NFS exports of ZFS snapshots broken
Date: Fri, 17 Nov 2023 17:35:04 -0500

< said:


I have not run into this, so I tried it just now.  I had no problem.
The server is 13.2, fully patched, the client is up-to-date -current,
and the mount is v4.


On my 13.2 client and 13-stable server, I see:

  25034 ls   CALL  
open(0x237d32f9a000,0x120004)
  25034 ls   NAMI  "/mnt/tools/.zfs/snapshot/weekly-2023-45"
  25034 ls   RET   open 4
  25034 ls   CALL  fcntl(0x4,F_ISUNIONSTACK,0x0)
  25034 ls   RET   fcntl 0
  25034 ls   CALL  getdirentries(0x4,0x237d32faa000,0x1000,0x237d32fa7028)
  25034 ls   RET   getdirentries -1 errno 5 Input/output error
  25034 ls   CALL  close(0x4)
  25034 ls   RET   close 0
  25034 ls   CALL  exit(0)

Certainly a libc bug here that 

Re: crash zfs_clone_range()

[Ronald Klop]

Van: Ronald Klop 
Datum: dinsdag, 14 november 2023 13:59
Aan: Konstantin Belousov 
CC: Alexander Motin , curr...@freebsd.org
Onderwerp: Re: crash zfs_clone_range()


Response below
 
Van: Konstantin Belousov 

Datum: zondag, 12 november 2023 19:47
Aan: Alexander Motin 
CC: Ronald Klop , curr...@freebsd.org
Onderwerp: Re: crash zfs_clone_range()


On Sun, Nov 12, 2023 at 11:51:40AM -0500, Alexander Motin wrote:
> Hi Ronald,
>
> As I can see, the clone request to ZFS came through nullfs, and it crashed
> immediately on enter.  I've never been a VFS layer expert, but to me it may
> be a nullfs problem, not zfs.  Is there chance you was (un-)mounting
> something when this happened?
It is not nullfs issue, I believe, but the lack of the busy reference on the
upper mount.  I think https://reviews.freebsd.org/D42554 should cover it.

>
> On 10.11.2023 05:12, Ronald Klop wrote:
> > Hi,
> >
> > Had this crash today on RPI4/15-CURRENT.
> >
> > FreeBSD rpi4 15.0-CURRENT FreeBSD 15.0-CURRENT #19
> > main-b0203aaa46-dirty: Sat Nov  4 11:48:33 CET 2023 
ronald@rpi4:/home/ronald/dev/freebsd/obj/home/ronald/dev/freebsd/src/arm64.aarch64/sys/GENERIC-NODEBUG
> > arm64
> >
> > $ sysctl -a | grep bclon
> > vfs.zfs.bclone_enabled: 1
> >
> > I started a jail with poudriere to build a package. The jail uses null
> > mounts over ZFS.
> >
> > [root]# cu -s 115200 -l /dev/cuaU0
> > Connected
> >
> > db> bt
> > Tracing pid 95213 tid 100438 td 0xe1e97900
> > db_trace_self() at db_trace_self
> > db_stack_trace() at db_stack_trace+0x120
> > db_command() at db_command+0x2e4
> > db_command_loop() at db_command_loop+0x58
> > db_trap() at db_trap+0x100
> > kdb_trap() at kdb_trap+0x334
> > handle_el1h_sync() at handle_el1h_sync+0x18
> > --- exception, esr 0xf200
> > kdb_enter() at kdb_enter+0x48
> > vpanic() at vpanic+0x1dc
> > panic() at panic+0x48
> > data_abort() at data_abort+0x2fc
> > handle_el1h_sync() at handle_el1h_sync+0x18
> > --- exception, esr 0x9604
> > rms_rlock() at rms_rlock+0x1c
> > zfs_clone_range() at zfs_clone_range+0x68
> > zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
> > null_bypass() at null_bypass+0x118
> > vn_copy_file_range() at vn_copy_file_range+0x18c
> > kern_copy_file_range() at kern_copy_file_range+0x36c
> > sys_copy_file_range() at sys_copy_file_range+0x8c
> > do_el0_sync() at do_el0_sync+0x634
> > handle_el0_sync() at handle_el0_sync+0x48
> > --- exception, esr 0x5600
> >
> >
> > Oh.. While typing this I rebooted the machine and it happened again. I
> > didn't start anything in particular although the machine runs some
> > jails.
> >
> > x0: 0x00e0
> >x1: 0xa00090317a48
> >x2: 0xa000f79d4f00
> >x3: 0xa000c61a44a8
> >x4: 0xdeefe460 ($d.2 + 0xdd776560)
> >x5: 0xa001250e4c00
> >x6: 0xe54025b5 ($d.5 + 0xc)
> >x7: 0x030a
> >x8: 0xe1559000 ($d.2 + 0xdfdd1100)
> >x9: 0x0001
> >   x10: 0x
> >   x11: 0x0001
> >   x12: 0x0002
> >   x13: 0x
> >   x14: 0x0001
> >   x15: 0x
> >   x16: 0x016dce88 (__stop_set_modmetadata_set + 0x1310)
> >   x17: 0x004e0d44 (rms_rlock + 0x0)
> >   x18: 0xdeefe280 ($d.2 + 0xdd776380)
> >   x19: 0x
> >   x20: 0xdeefe460 ($d.2 + 0xdd776560)
> >   x21: 0x7fff
> >   x22: 0xa00090317a48
> >   x23: 0xa000f79d4f00
> >   x24: 0xa001067ef910
> >   x25: 0x00e0
> >   x26: 0xa000158a8000
> >   x27: 0x
> >   x28: 0xa000158a8000
> >   x29: 0xdeefe280 ($d.2 + 0xdd776380)
> >sp: 0xdeefe280
> >lr: 0x01623564 (zfs_clone_range + 0x6c)
> >   elr: 0x004e0d60 (rms_rlock + 0x1c)
> > spsr: 0xa045
> >   far: 0x0108
> >   esr: 0x9604
> > panic: data abort in critical section or under mutex
> > cpuid = 1
> > time = 1699610885
> > KDB: stack backtrace:
> > db_trace_self() at db_trace_self
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x38
> > vpanic() at vpanic+0x1a0
> > panic() at panic+0x48
> > data_abort() at data_abort+0x2fc
> > handle_el1h_sync() at handle_el1h_sync+0x18
> > --- exception, esr 0x9604
> > rms_rlock() at rms_rlock+0x1c
> > zfs_clone_range() at zfs_clon

Re: crash zfs_clone_range()

[Ronald Klop]

Response below

Van: Konstantin Belousov 
Datum: zondag, 12 november 2023 19:47
Aan: Alexander Motin 
CC: Ronald Klop , curr...@freebsd.org
Onderwerp: Re: crash zfs_clone_range()


On Sun, Nov 12, 2023 at 11:51:40AM -0500, Alexander Motin wrote:
> Hi Ronald,
>
> As I can see, the clone request to ZFS came through nullfs, and it crashed
> immediately on enter.  I've never been a VFS layer expert, but to me it may
> be a nullfs problem, not zfs.  Is there chance you was (un-)mounting
> something when this happened?
It is not nullfs issue, I believe, but the lack of the busy reference on the
upper mount.  I think https://reviews.freebsd.org/D42554 should cover it.

>
> On 10.11.2023 05:12, Ronald Klop wrote:
> > Hi,
> >
> > Had this crash today on RPI4/15-CURRENT.
> >
> > FreeBSD rpi4 15.0-CURRENT FreeBSD 15.0-CURRENT #19
> > main-b0203aaa46-dirty: Sat Nov  4 11:48:33 CET 2023 
ronald@rpi4:/home/ronald/dev/freebsd/obj/home/ronald/dev/freebsd/src/arm64.aarch64/sys/GENERIC-NODEBUG
> > arm64
> >
> > $ sysctl -a | grep bclon
> > vfs.zfs.bclone_enabled: 1
> >
> > I started a jail with poudriere to build a package. The jail uses null
> > mounts over ZFS.
> >
> > [root]# cu -s 115200 -l /dev/cuaU0
> > Connected
> >
> > db> bt
> > Tracing pid 95213 tid 100438 td 0xe1e97900
> > db_trace_self() at db_trace_self
> > db_stack_trace() at db_stack_trace+0x120
> > db_command() at db_command+0x2e4
> > db_command_loop() at db_command_loop+0x58
> > db_trap() at db_trap+0x100
> > kdb_trap() at kdb_trap+0x334
> > handle_el1h_sync() at handle_el1h_sync+0x18
> > --- exception, esr 0xf200
> > kdb_enter() at kdb_enter+0x48
> > vpanic() at vpanic+0x1dc
> > panic() at panic+0x48
> > data_abort() at data_abort+0x2fc
> > handle_el1h_sync() at handle_el1h_sync+0x18
> > --- exception, esr 0x9604
> > rms_rlock() at rms_rlock+0x1c
> > zfs_clone_range() at zfs_clone_range+0x68
> > zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
> > null_bypass() at null_bypass+0x118
> > vn_copy_file_range() at vn_copy_file_range+0x18c
> > kern_copy_file_range() at kern_copy_file_range+0x36c
> > sys_copy_file_range() at sys_copy_file_range+0x8c
> > do_el0_sync() at do_el0_sync+0x634
> > handle_el0_sync() at handle_el0_sync+0x48
> > --- exception, esr 0x5600
> >
> >
> > Oh.. While typing this I rebooted the machine and it happened again. I
> > didn't start anything in particular although the machine runs some
> > jails.
> >
> > x0: 0x00e0
> >x1: 0xa00090317a48
> >x2: 0xa000f79d4f00
> >x3: 0xa000c61a44a8
> >x4: 0xdeefe460 ($d.2 + 0xdd776560)
> >x5: 0xa001250e4c00
> >x6: 0xe54025b5 ($d.5 + 0xc)
> >x7: 0x030a
> >x8: 0xe1559000 ($d.2 + 0xdfdd1100)
> >x9: 0x0001
> >   x10: 0x
> >   x11: 0x0001
> >   x12: 0x0002
> >   x13: 0x
> >   x14: 0x0001
> >   x15: 0x
> >   x16: 0x016dce88 (__stop_set_modmetadata_set + 0x1310)
> >   x17: 0x004e0d44 (rms_rlock + 0x0)
> >   x18: 0xdeefe280 ($d.2 + 0xdd776380)
> >   x19: 0x
> >   x20: 0xdeefe460 ($d.2 + 0xdd776560)
> >   x21: 0x7fff
> >   x22: 0xa00090317a48
> >   x23: 0xa000f79d4f00
> >   x24: 0xa001067ef910
> >   x25: 0x00e0
> >   x26: 0xa000158a8000
> >   x27: 0x
> >   x28: 0xa000158a8000
> >   x29: 0xdeefe280 ($d.2 + 0xdd776380)
> >sp: 0xdeefe280
> >lr: 0x01623564 (zfs_clone_range + 0x6c)
> >   elr: 0x004e0d60 (rms_rlock + 0x1c)
> > spsr: 0xa045
> >   far: 0x0108
> >   esr: 0x9604
> > panic: data abort in critical section or under mutex
> > cpuid = 1
> > time = 1699610885
> > KDB: stack backtrace:
> > db_trace_self() at db_trace_self
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x38
> > vpanic() at vpanic+0x1a0
> > panic() at panic+0x48
> > data_abort() at data_abort+0x2fc
> > handle_el1h_sync() at handle_el1h_sync+0x18
> > --- exception, esr 0x9604
> > rms_rlock() at rms_rlock+0x1c
> > zfs_clone_range() at zfs_clone_range+0x68
> > zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
> > null_bypass() at null_bypass+0x118
> > vn_copy_file_range() at vn

crash zfs_clone_range()

[Ronald Klop]

Hi,

Had this crash today on RPI4/15-CURRENT.

FreeBSD rpi4 15.0-CURRENT FreeBSD 15.0-CURRENT #19 main-b0203aaa46-dirty: Sat 
Nov  4 11:48:33 CET 2023 
ronald@rpi4:/home/ronald/dev/freebsd/obj/home/ronald/dev/freebsd/src/arm64.aarch64/sys/GENERIC-NODEBUG
 arm64

$ sysctl -a | grep bclon
vfs.zfs.bclone_enabled: 1

I started a jail with poudriere to build a package. The jail uses null mounts 
over ZFS.

[root]# cu -s 115200 -l /dev/cuaU0
Connected

db> bt
Tracing pid 95213 tid 100438 td 0xe1e97900
db_trace_self() at db_trace_self
db_stack_trace() at db_stack_trace+0x120
db_command() at db_command+0x2e4
db_command_loop() at db_command_loop+0x58
db_trap() at db_trap+0x100
kdb_trap() at kdb_trap+0x334
handle_el1h_sync() at handle_el1h_sync+0x18
--- exception, esr 0xf200
kdb_enter() at kdb_enter+0x48
vpanic() at vpanic+0x1dc
panic() at panic+0x48
data_abort() at data_abort+0x2fc
handle_el1h_sync() at handle_el1h_sync+0x18
--- exception, esr 0x9604
rms_rlock() at rms_rlock+0x1c
zfs_clone_range() at zfs_clone_range+0x68
zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
null_bypass() at null_bypass+0x118
vn_copy_file_range() at vn_copy_file_range+0x18c
kern_copy_file_range() at kern_copy_file_range+0x36c
sys_copy_file_range() at sys_copy_file_range+0x8c
do_el0_sync() at do_el0_sync+0x634
handle_el0_sync() at handle_el0_sync+0x48
--- exception, esr 0x5600


Oh.. While typing this I rebooted the machine and it happened again. I didn't 
start anything in particular although the machine runs some jails.

x0: 0x00e0
 x1: 0xa00090317a48
 x2: 0xa000f79d4f00
 x3: 0xa000c61a44a8
 x4: 0xdeefe460 ($d.2 + 0xdd776560)
 x5: 0xa001250e4c00
 x6: 0xe54025b5 ($d.5 + 0xc)
 x7: 0x030a
 x8: 0xe1559000 ($d.2 + 0xdfdd1100)
 x9: 0x0001
x10: 0x
x11: 0x0001
x12: 0x0002
x13: 0x
x14: 0x0001
x15: 0x
x16: 0x016dce88 (__stop_set_modmetadata_set + 0x1310)
x17: 0x004e0d44 (rms_rlock + 0x0)
x18: 0xdeefe280 ($d.2 + 0xdd776380)
x19: 0x
x20: 0xdeefe460 ($d.2 + 0xdd776560)
x21: 0x7fff
x22: 0xa00090317a48
x23: 0xa000f79d4f00
x24: 0xa001067ef910
x25: 0x00e0
x26: 0xa000158a8000
x27: 0x
x28: 0xa000158a8000
x29: 0xdeefe280 ($d.2 + 0xdd776380)
 sp: 0xdeefe280
 lr: 0x01623564 (zfs_clone_range + 0x6c)
elr: 0x004e0d60 (rms_rlock + 0x1c)
spsr: 0xa045
far: 0x0108
esr: 0x9604
panic: data abort in critical section or under mutex
cpuid = 1
time = 1699610885
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x38
vpanic() at vpanic+0x1a0
panic() at panic+0x48
data_abort() at data_abort+0x2fc
handle_el1h_sync() at handle_el1h_sync+0x18
--- exception, esr 0x9604
rms_rlock() at rms_rlock+0x1c
zfs_clone_range() at zfs_clone_range+0x68
zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
null_bypass() at null_bypass+0x118
vn_copy_file_range() at vn_copy_file_range+0x18c
kern_copy_file_range() at kern_copy_file_range+0x36c
sys_copy_file_range() at sys_copy_file_range+0x8c
do_el0_sync() at do_el0_sync+0x634
handle_el0_sync() at handle_el0_sync+0x48
--- exception, esr 0x5600
KDB: enter: panic
[ thread pid 3792 tid 100394 ]
Stopped at  kdb_enter+0x48: str xzr, [x19, #768]
db>

I'll keep the debugger open for a while. Can I type something for additional 
info?

Regards,
Ronald.

Re: RFC: NFS over TLS stats

[Ronald Klop]

Maybe tracking of errors can be useful.

Great work on this!

Regards,
Ronald.


Van: Rick Macklem 
Datum: woensdag, 25 oktober 2023 04:50
Aan: FreeBSD CURRENT , Garrett Wollman 

Onderwerp: RFC: NFS over TLS stats


Garrett Wollman asked me via email how a server
admin could tell what usage NFS over TLS was
happening.

I admitted that there was nothing. I have come up
with a patch that generates the following:
kern.rpctls.snd_tls_msgbytes: 21508
kern.rpctls.snd_msgbytes: 20828
kern.rpctls.snd_tls_msgcnt: 57
kern.rpctls.snd_msgcnt: 58
kern.rpctls.rcv_tls_msgbytes: 12336
kern.rpctls.rcv_msgbytes: 12072
kern.rpctls.rcv_tls_msgcnt: 57
kern.rpctls.rcv_msgcnt: 58

Basically counts of number of RPC messages
and total number of bytes those messages
result in. (Both with/without TLS.)

Does this seem reasonable or are there better
statistics that could be generated?  Obviously
any other suggestion might or might not be
practical to implement.

Thanks, rick
 

Re: [UPDATE] FreeBSD 14.0-BETA3 Now Available

[Ronald Klop]

On 9/25/23 22:18, James Comfort wrote:

Just out of curiosity, is there a reason that virtualbox-ose-additions don’t 
show up in a pkg search? I’ve tried compiling it from ports, but keep getting 
errors.




Yes. The pkg build was failing on FreeBSD 14 and 15 for some time. Recently a 
patch was committed which fixes this. The first pkg build containing this patch 
just finished. The pkgs will probably appear on the download servers tomorrow 
or the day after if nothing unexpected happens.

This is the log of the successful build of virtualbox-ose-additions on 
releng/14:
https://pkg-status.freebsd.org/beefy12/data/140releng-amd64-default/e88d010d0a2b/logs/virtualbox-ose-additions-6.1.46.log

Regards,
Ronald.




Jim Comfort

Sent from Mail  for Windows

*From: *Nuno Teixeira 
*Sent: *Saturday, September 23, 2023 5:11 AM
*To: *Kurt Jaeger 
*Cc: *Glen Barber ; freebsd-current@freebsd.org 
; freebsd-sta...@freebsd.org 
; FreeBSD Release Engineering Team 

*Subject: *Re: [UPDATE] FreeBSD 14.0-BETA3 Now Available

Same error but it seems that upgrade completed and pkgs cleaned:

---

=>> Building lang/rust
build started at Sat Sep 23 12:26:01 WEST 2023
port directory: /usr/ports/lang/rust
package name: rust-1.72.0
building for: FreeBSD 140amd64-main-job-02 14.0-BETA3 FreeBSD 14.0-BETA3 amd64
maintained by: r...@freebsd.org
Makefile datestamp: -rw-r--r--  1 1001 1001 11640 Sep  9 08:02 
/usr/ports/lang/rust/Makefile
Poudriere version: poudriere-git-3.3.99.20220831
Host OSVERSION: 151
Jail OSVERSION: 1400097
Job Id: 02

---

Kurt Jaeger mailto:p...@freebsd.org>> escreveu no dia 
sábado, 23/09/2023 à(s) 12:33:

Hi!

 > On Fri, Sep 22, 2023 at 10:50:08PM +, Glen Barber wrote:
 > > === Upgrading ===
 > >
 > > Due to a known delay, freebsd-update(8) binary update builds are not 
yet
 > > ready for BETA3.  A separate email will be sent once they are 
available.
 > >
 >
 > Binary updates via freebsd-update(8) are now available for systems
 > already running 14.0-BETA.

If I try to update my poudriere 14.0-BETA2 jail with this command:

poudriere jail -u -j 140 -t 14.0-BETA3

it fails, see here:

https://people.freebsd.org/~pi/logs/pou-fail.txt 

(short, only 1550 bytes)

I have:

140   14.0-BETA2      amd64 http    2023-09-16 08:20:01 /pou/jails/140

with

/usr/local/bin/poudriere installed by package 
poudriere-devel-3.3.99.20220831

-- 
p...@freebsd.org         +49 171 3101372                  Now what ?




--

Nuno Teixeira
FreeBSD Committer (ports)

Re: changes to ps -d?

[Ronald Klop]

Van: Michael Gmelin 
Datum: dinsdag, 19 september 2023 13:01
Aan: Ronald Klop 
CC: ps...@freebsd.org, freebsd-current@freebsd.org
Onderwerp: Re: changes to ps -d?


 
 
 
 

On 19. Sep 2023, at 12:30, Ronald Klop  wrote:
 > 


Hi,

In current the way ps -p works has been changed [1].
I could use "ps axd -p " to see the process tree of some ongoing task.
In current this has changed to always need an extra option "ps axd -p  -D 
down". Can this become the default again? At least when -d is used.
 


 
There was a discussion on the FreeBSD-current mailing list that lead to the decision to make this change:
 
https://lists.freebsd.org/archives/freebsd-current/2023-July/004071.html
 
Best
 



Thanks, I missed that conversation.
Curious about the meaning of "would be the best in that -d would go back to what it 
was" in https://lists.freebsd.org/archives/freebsd-current/2023-August/004277.html.

Currently in "ps -d -p " -d is not back at what it was.

Regards,
Ronald.

changes to ps -d?

[Ronald Klop]

Hi,

In current the way ps -p works has been changed [1].
I could use "ps axd -p " to see the process tree of some ongoing task.
In current this has changed to always need an extra option "ps axd -p  -D 
down". Can this become the default again? At least when -d is used.

Regards,
Ronald.

[1] 
https://cgit.freebsd.org/src/commit/bin/ps?id=5c0a1c15ff8cb66128f4826ace8ba91e0a31486d

Re: Continually count the number of open files

[Ronald Klop]

On 9/12/23 08:38, Graham Perrin wrote:

Can anything like systat(1) present a count, continually?

I'd like to monitor, after log in to Plasma (X11), in connection with 
.





I don't think you mean:
# sysctl -d kern.openfiles
kern.openfiles: System-wide number of open files

It is more like a gauge than a counter.

Regards,
Ronald.

Re: building with llvm16 pkg fails in tests

[Ronald Klop]

On 8/19/23 22:28, Ronald Klop wrote:

On 8/17/23 21:33, Brooks Davis wrote:

On Thu, Aug 17, 2023 at 12:45:06PM +0200, Ronald Klop wrote:

Hi,

To save time on my Raspberry Pi I would like to build FreeBSD using a llvm pkg 
instead of llvm in the tree.

My /etc/make.conf:
WITHOUT_TOOLCHAIN=yes
LD=/usr/local/llvm16/bin/ld.lld
CC=/usr/local/llvm16/bin/clang
CXX=/usr/local/llvm16/bin/clang++
CPP=/usr/local/llvm16/bin/clang-cpp
OBJCOPY=/usr/local/llvm16/bin/llvm-objcopy

#WITHOUT_CLEAN=yes


This fails in:

/usr/local/llvm16/bin/clang++ -O2 -pipe -fno-common -fPIE -Wno-format-zero-length -nobuiltininc -idirafter /usr/local/llvm16/lib/clang/16/include -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wdate-time -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -O0 -g0 -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private -I/usr/src/contrib/googletest/googlemock/include -I/usr/src/contrib/googletest/googlemock -I/usr/src/contrib/googletest/googletest/include -I/usr/src/contrib/googletest/googletest -I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private -DGTEST_HAS_POSIX_RE=1 -DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti -Wno-deprecated-copy -Wno-signed-unsigned-wchar -DGTEST_HAS_POSIX_RE=1 
-DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti -Wno-deprecated-copy -Wno-signed-unsigned-wchar -fPIE -std=c++14 -Wno-deprecated-copy -Wno-error=inconsistent-missing-override -Wno-error=missing-variable-declarations -Wno-error=sign-compare -Wno-error=unused-parameter -Wno-c++11-extensions  -Wl,-zrelro -pie  --ld-path=/usr/local/llvm16/bin/ld.lld -o gmock-actions_test  gmock-actions_test.o -lprivategmock_main -lprivategmock -lprivategtest

ld.lld: error: undefined symbol: testing::internal::DeathTest::Create(char const*, 
testing::Matcher, 
std::__1::allocator> const&>, char const*, int, testing::internal::DeathTest**)

referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForNonDefaultConstructibleType_Test::TestBody())
referenced 4 more times


ld.lld: error: undefined symbol: 
testing::Expectation::Expectation(std::__1::shared_ptr
 const&)


Any thoughts on how to fix this?
Compiling with the in tree llvm does work properly.


Did it work with exactly this git revision?  I suspect an issue with the
recent google test update rather than an llvm16 issue.  Note that for
every sync to github we build the tree with the llvm16 port (all be it
on amd64 by default).

It's worth noting one difference between your configuration and the
CI one:  We don't set CC and friends directly.  Instead we use
CROSS_TOOLCHAIN=llvm16.

-- Brooks



Hi,

What I would like to accomplish is this:

CROSS_TOOLCHAIN=llvm16
WITHOUT_TOOLCHAIN=yes

yes | make delete-old delete-old-libs
make buildworld buildkernel

So I can run a system with only external toolchain.
But doing this quickly errors out because /usr/bin/cc does not exist and the 
build uses that even though CROSS_TOOLCHAIN is set. To circumvent that I set 
CC, etc. instead of CROSS_TOOLCHAIN.

Regards,
Ronald.




Hi,

I found what was going on. Passing CC=/usr/local/llvm16/bin/clang does not pass 
the -target, --sysroot and -B option. If I set those in CFLAGS everything 
compiles fine.

What I do now is this:

pkg -j ${JAIL_NAME} install -y ${CROSS_TOOLCHAIN} byacc

jexec ${JAIL_NAME} sh -c "yes | /usr/bin/make CC=${LLVM_DIR}/bin/clang 
LD=${LLVM_DIR}/bin/ld.lld -C /usr/src delete-old delete-old-libs"

cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang cc
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang CC
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang++ c++
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang-cpp cpp
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/llvm-objcopy objcopy
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/ld
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/bin/yacc

jexec ${JAIL_NAME} /usr/bin/make -C /usr/src -j${NUM_CPUS} 
CROSS_TOOLCHAIN=llvm16 WITHOUT_TOOLCHAIN=yes buildworld buildkernel


This builds fine also. Because CC is not set SYSROOT is just the default.

Any advice on how to make set CC and use the proper sysroot instead of the 
(ugly) symlinking?
And why do parts of buildworld use CROSS_TOOLCHAIN and other parts don't?

Regards,
Ronald.

Re: building with llvm16 pkg fails in tests

[Ronald Klop]

On 8/17/23 21:33, Brooks Davis wrote:

On Thu, Aug 17, 2023 at 12:45:06PM +0200, Ronald Klop wrote:

Hi,

To save time on my Raspberry Pi I would like to build FreeBSD using a llvm pkg 
instead of llvm in the tree.

My /etc/make.conf:
WITHOUT_TOOLCHAIN=yes
LD=/usr/local/llvm16/bin/ld.lld
CC=/usr/local/llvm16/bin/clang
CXX=/usr/local/llvm16/bin/clang++
CPP=/usr/local/llvm16/bin/clang-cpp
OBJCOPY=/usr/local/llvm16/bin/llvm-objcopy

#WITHOUT_CLEAN=yes


This fails in:

/usr/local/llvm16/bin/clang++ -O2 -pipe -fno-common -fPIE 
-Wno-format-zero-length -nobuiltininc -idirafter 
/usr/local/llvm16/lib/clang/16/include -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
-Wunused-parameter -Wcast-align -Wchar-subscripts -Wdate-time 
-Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter -O0 -g0 
-Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private 
-I/usr/src/contrib/googletest/googlemock/include 
-I/usr/src/contrib/googletest/googlemock 
-I/usr/src/contrib/googletest/googletest/include 
-I/usr/src/contrib/googletest/googletest 
-I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private -DGTEST_HAS_POSIX_RE=1 
-DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti 
-Wno-deprecated-copy -Wno-signed-unsigned-wchar -DGTEST_HAS_POSIX_RE=1 
-DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti 
-Wno-deprecated-copy -Wno-signed-unsigned-wchar -fPIE -std=c++14 
-Wno-deprecated-copy -Wno-error=inconsistent-missing-override 
-Wno-error=missing-variable-declarations -Wno-error=sign-compare 
-Wno-error=unused-parameter -Wno-c++11-extensions  -Wl,-zrelro -pie  
--ld-path=/usr/local/llvm16/bin/ld.lld -o gmock-actions_test  
gmock-actions_test.o -lprivategmock_main -lprivategmock -lprivategtest
ld.lld: error: undefined symbol: testing::internal::DeathTest::Create(char const*, 
testing::Matcher, 
std::__1::allocator> const&>, char const*, int, testing::internal::DeathTest**)

referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForNonDefaultConstructibleType_Test::TestBody())
referenced 4 more times


ld.lld: error: undefined symbol: 
testing::Expectation::Expectation(std::__1::shared_ptr
 const&)


Any thoughts on how to fix this?
Compiling with the in tree llvm does work properly.


Did it work with exactly this git revision?  I suspect an issue with the
recent google test update rather than an llvm16 issue.  Note that for
every sync to github we build the tree with the llvm16 port (all be it
on amd64 by default).

It's worth noting one difference between your configuration and the
CI one:  We don't set CC and friends directly.  Instead we use
CROSS_TOOLCHAIN=llvm16.

-- Brooks



Hi,

What I would like to accomplish is this:

CROSS_TOOLCHAIN=llvm16
WITHOUT_TOOLCHAIN=yes

yes | make delete-old delete-old-libs
make buildworld buildkernel

So I can run a system with only external toolchain.
But doing this quickly errors out because /usr/bin/cc does not exist and the 
build uses that even though CROSS_TOOLCHAIN is set. To circumvent that I set 
CC, etc. instead of CROSS_TOOLCHAIN.

Regards,
Ronald.

Re: Status for zfs upgrade?

[Ronald Klop]

Hi,

This blog might be interesting to you.
https://vermaden.wordpress.com/2022/03/25/zfs-compatibility/

BTW: stable/14 is delayed one week: 
https://www.freebsd.org/releases/14.0R/schedule/

Regards,
Ronald.

Van: Tomoaki AOKI 
Datum: vrijdag, 18 augustus 2023 00:00
Aan: freebsd-current@freebsd.org
Onderwerp: Status for zfs upgrade?


Hi.

Creation of stable/14 is planned at Aug.18, 2023 (Already TODAY in
Japan, JST+9).

Is it safe for now to `zfs upgrade `, if tunable
vfs.zfs.bclone_enabled is set to 0?

If not, I should wait until next stable branch, /15.
(I upgrade pool only when ZFS codes are 100% match between main and
latest stable. Meaning doable only when new stable branch is created.)

Regards.

--
Tomoaki AOKI
 

building with llvm16 pkg fails in tests

[Ronald Klop]

Hi,

To save time on my Raspberry Pi I would like to build FreeBSD using a llvm pkg 
instead of llvm in the tree.

My /etc/make.conf:
WITHOUT_TOOLCHAIN=yes
LD=/usr/local/llvm16/bin/ld.lld
CC=/usr/local/llvm16/bin/clang
CXX=/usr/local/llvm16/bin/clang++
CPP=/usr/local/llvm16/bin/clang-cpp
OBJCOPY=/usr/local/llvm16/bin/llvm-objcopy

#WITHOUT_CLEAN=yes


This fails in:

/usr/local/llvm16/bin/clang++ -O2 -pipe -fno-common -fPIE 
-Wno-format-zero-length -nobuiltininc -idirafter 
/usr/local/llvm16/lib/clang/16/include -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
-Wunused-parameter -Wcast-align -Wchar-subscripts -Wdate-time 
-Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter -O0 -g0 
-Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private 
-I/usr/src/contrib/googletest/googlemock/include 
-I/usr/src/contrib/googletest/googlemock 
-I/usr/src/contrib/googletest/googletest/include 
-I/usr/src/contrib/googletest/googletest 
-I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private -DGTEST_HAS_POSIX_RE=1 
-DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti 
-Wno-deprecated-copy -Wno-signed-unsigned-wchar -DGTEST_HAS_POSIX_RE=1 
-DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti 
-Wno-deprecated-copy -Wno-signed-unsigned-wchar -fPIE -std=c++14 
-Wno-deprecated-copy -Wno-error=inconsistent-missing-override 
-Wno-error=missing-variable-declarations -Wno-error=sign-compare 
-Wno-error=unused-parameter -Wno-c++11-extensions  -Wl,-zrelro -pie  
--ld-path=/usr/local/llvm16/bin/ld.lld -o gmock-actions_test  
gmock-actions_test.o -lprivategmock_main -lprivategmock -lprivategtest
ld.lld: error: undefined symbol: testing::internal::DeathTest::Create(char const*, 
testing::Matcher, 
std::__1::allocator> const&>, char const*, int, testing::internal::DeathTest**)

referenced by gmock-actions_test.cc
  gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
  gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
  gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForNonDefaultConstructibleType_Test::TestBody())
referenced 4 more times


ld.lld: error: undefined symbol: 
testing::Expectation::Expectation(std::__1::shared_ptr
 const&)


Any thoughts on how to fix this?
Compiling with the in tree llvm does work properly.

NB: building 14-CURRENT in a 14-CURRENT jail on 13.2-RELEASE. And this example 
is my test on amd64 to make it work before I will do this in the slow RPI4.

Regards,
Ronald.

ssh 9.4 fails to build

[Ronald Klop]

Hi,

I get this error while building world.
NB: I'm building with llvm15 from a pkg. But I don't think that should make a 
difference.
ld.lld: error: undefined symbol: Fssh_lib_contains_symbol

referenced by ssh-pkcs11.c:1538 (/usr/src/crypto/openssh/ssh-pkcs11.c:1538)
  ssh-pkcs11.o:(Fssh_pkcs11_add_provider)



git reset --hard  fixes the build for me.

Regards,

Ronald.

Re: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?

[Ronald Klop]

Van: Michael Grimm 
Datum: maandag, 7 augustus 2023 22:43
Aan: freebsd-current@freebsd.org
Onderwerp: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?


Hi,

I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I 
upgraded one of my sytems from 13-STABLE to 14-CURRENT.

Everything went fine, except for programs that need /usr/lib/pam_opie.so which 
are:

1) jexec  /usr/bin/login -u 
2) redis-server
3) mariadb1011-server

Error messages:

su[6371]: in openpam_load_module(): no pam_opie.so found
su[6371]: pam_start: System error

Well, although it has been reported some time ago that pam_opie and 
pam_opieaccess.so will become removed in Freebsd 14, there is a port 
security/opie providing both libraries. Quick workaround.

But I want to understand why the above mentioned programs do fail although not 
dynamically linked against /usr/lib/pam_opie.so

MWN> ldd /usr/bin/login
/usr/bin/login:
libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000)
libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000)
libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000)
libc.so.7 => /lib/libc.so.7 (0xd408f99d000)
[vdso] (0xd408e18f630)

MWN> ldd /usr/local/bin/redis-server
/usr/local/bin/redis-server:
libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000)
libm.so.5 => /lib/libm.so.5 (0x89a87beb000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000)
libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000)
libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000)
[vdso] (0x89a87323630)

MWN> ldd /usr/local/libexec/mariadbd
/usr/local/libexec/mariadbd:
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000)
libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000)
libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000)
libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000)
libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000)
libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000)
libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000)
libthr.so.3 => /lib/libthr.so.3 (0x145aebf1)
libc.so.7 => /lib/libc.so.7 (0x145aec7fa000)
libelf.so.2 => /lib/libelf.so.2 (0x145aee867000)
[vdso] (0x145ae5010630)

Which alternatives to pam_opie should I investigate?
Reason: I want to get rid of security/opie

Thanks and regards,
Michael

 







Hi,

Might it be possible that pam_opie is still mentioned in a file in /etc/pam.d/* 
on your machine?
An alternative might be 
https://www.freshports.org/security/pam_google_authenticator

See also: 
https://lists.freebsd.org/archives/freebsd-security/2022-September/81.html

Regards,
Ronald.

Re: problems on new -current install with pkg/ssl

[Ronald Klop]

On 7/9/23 18:27, void wrote:

On Sun, Jul 09, 2023 at 05:17:38PM +0100, void wrote:

Hi,

On a fresh 14-current install (main-n263444-653738e895ba)
I try to use pkg for anything and this error
happens:

# pkg install doas
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.19.2...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1400092
- running kernel: 1400090
Ignore the mismatch and continue? [y/N]: y
Extracting pkg-1.19.2: 100%
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

How can I fix?


I was able to fix this by downloading 
https://download.freebsd.org/ports/ports/ports.tar.xz
manually to /usr and building from the ports tree



If you upgrade your FreeBSD 14 to the latest version it will work also. OpenSSL 
3.0 is imported into 14 which gives a small overlapping time window in which 
users can still be running older FreeBSD versions with OpenSSL 1.1.1 while the 
official pkg repo compiles using 3.0.

After you upgraded FreeBSD please make sure to upgrade pkg to use openssl3.0 before you 
run "make delete-old-libs".

Regards,
Ronald.

Re: find(1): I18N gone wild ?

[Ronald Klop]

 
Van: Poul-Henning Kamp 

Datum: maandag, 17 april 2023 23:06
Aan: curr...@freebsd.org
Onderwerp: find(1): I18N gone wild ?


This surprised me:

# mkdir /tmp/P
# cd /tmp/P
# touch FOO
# touch bar
# env LANG=C.UTF-8 find . -name '[A-Z]*' -print
./FOO
# env LANG=en_US.UTF-8 find . -name '[A-Z]*' -print
./FOO
./bar

Really ?!

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
 







My Mac and a Linux server only give ./FOO in both cases. Just a 2 cents remark.

Regards,
Ronald.
 

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

[Ronald Klop]

Van: bob prohaska 
Datum: 24 februari 2023 22:05
Aan: freebsd-current@freebsd.org
CC: freebsd-...@freebsd.org
Onderwerp: Timekeeping problem in /usr/src on new RPI aarch64 snapshot




After installing 
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img

on a Pi3 and setting up the hard disk to use separate swap and /usr partitions
an oddity came to light regarding dates.

The image file was written to disk the night of the 23rd, from a Pi3 with
a correctly-set time and date. It was left idle overnight, configured the
morning of the 24th and booted without issue. It then cloned -current into
/usr/src, at which point the time was noticed to be wrong, apparently fast.

It turned out ntpdate wasn't running, so it was started and then tzsetup
run. After a reboot the time reported correctly. 


However, make buildworld in /usr/src triggers an exhortation to "check
your time" and refuses run further. 


running date on the system reports
Fri Feb 24 12:49:41 PST 2023
but ls -l /usr/src reports time around 
Feb 24 19:10

an obvious inconsistency.
 
Presumably just waiting until the system clock catches

up with the /usr/src timestamps will fix the error. Is
there a better method?

Still, the date and time handling don't seem quite right. 
In at least one earlier instance it appeared that tzsetup 
altered the reported timeszone without shifting the time

stamp by the UTC/PDT offset. I always thought timestamps
were internally in UTC+timezone, displayed with the right
offset. It looks to a casual observer like something else
is going on. 


An earlier fiasco (on this same Pi3) included wildly wrong
timestamps in a filesystem. The Pi3 has no hardware clock,
how does it set time when booted without a reference?

Thanks for reading,

bob prohaska








UFS stores the current timestamp in the superblock of the FS on clean shutdown/unmount. On boot it reads the time from the timestamp in the superblock of the root FS. Of coarse this timestamp is behind for the duration that the machine was off or rebooting so you need to adjust that using ntp. 
For ZFS root you can use the fakertc port to do something similar. 



You can use the command “touch“ to manipulate the time of your /usr/src dir. 



Regards,
Ronald

Re: An idea for swap partition size vs. swap space size in use handling

[Ronald Klop]

Van: Mark Millard 
Datum: zondag, 22 januari 2023 05:41
Aan: freebsd-current 
Onderwerp: An idea for swap partition size vs. swap space size in use handling


I have boot media that are each set up to boot a variety
of systems that have widely different RAM sizes, from
1 GiBytes to 64 GiBytes for the aarch64 examples of this.

This has lead to having multiple swap partitions of
various sizes so that I can have total swap spaces that
are somewhat under the recommended maximum sizes for the
amount of RAM in each of those systems that a given media
can boot.

It would be nice if I could have just one swap partition
on a given boot media, one that is more than sufficient
in size for all but the biggest RAM system --but to then
be able to tell the system to just use up to the
recommended swap space size and to ignore any extra swap
space in the swap partition.

If such could be done, I'd no longer use multiple swap
partitions at the same time in order to get to a desired
total for the system at hand at the time.

Of course, that still leaves what to do when multiple
swap partitions are enabled if such a "ignore what
would be extra" mode was also enabled. As I'd not use
such, I've no specific recommendations to make that
would make any difference to my use.

===
Mark Millard
marklmi at yahoo.com

 







Hi Mark,

Do you mean you would like to be able to add a "size" parameter to the fstab 
swap line?

/dev/da0p1  noneswapsw,size=1g  0   0

Another option I can think of is using the "gnop" geom provider. It has a -s 
parameter to set the size.

Regards,
Ronald.
 

Re: 14.0-CURRENT panic on boot, i386 VirtualBox client

[Ronald Klop]

On 12/28/22 17:45, Paul Floyd wrote:

Hi

For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a 
VirtualBox VM. I've tried both booting from iso image and the vmdk image. I get 
a kernel panic

The host is running 13.1-RELEASE-p3 amd64

No problems with 14.0-CURRENT amd64 guests.

I haven't been able to see the last message before the panic as it scrolls past 
too quickly.

Any suggestions for a working either how to get more info or what vbox settings 
to use?

A+
Paul




I've had success to capture errors by recording the screen with my phone and 
playing back on slow speed.
Another option might be to enable serial port for the console of the guest and 
capture the output. But I don't know if the default ISO uses that and how hard 
it is to configure VirtualBox to do that properly.

Regards,
Ronald.

Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build

[Ronald Klop]

Van: Warner Losh 
Datum: dinsdag, 8 november 2022 04:28
Aan: Archimedes Gaviola 
CC: Mark Millard , freebsd-current 

Onderwerp: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build


 
 
On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola  wrote:


 
 
On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola  wrote:


 
 
 
On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:

On 2022-Nov-2, at 14:09, Archimedes Gaviola  
wrote:

> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola 
 wrote:
>
> . . .
>
> . . .
>
>
> Hi Mark,
>
> Just an update, as kernel and world compilation is ongoing with my RPi3B 
system (with swap partition) is doing so far, so good. It already surpassed the 
tough part that breaks the compilation process here.
> ...
>
> llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm-project/llvm/include 
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-asm-writer  -I /usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenAsmWriter.inc.d -o 
RISCVGenAsmWriter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-callingconv  -I /usr/src/contrib/llvm-project/llvm/include 
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-compress-inst-emitter  -I 
/usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenDAGISel.inc.d -o 
RISCVGenDAGISel.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-disassembler  -I /usr/src/contrib/llvm-project/llvm/include 
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-global-isel  -I /usr/src/contrib/llvm-project/llvm/include 
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-instr-info  -I /usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenInstrInfo.inc.d -o 
RISCVGenInstrInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-pseudo-lowering  -I 
/usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-bank  -I /usr/src/contrib/llvm-project/llvm/include 
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-info  -I /usr/src/contrib/llvm-project/llvm/include 
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables  -I 
/usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-subtarget  -I /usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables  -I 
/usr/src/contrib/llvm-project/llvm/include -I 
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d 
RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc  
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>
> Any thoughts why this part is quite a challenge when it comes to memory usage? The other architectures do not possess such behavior... just curious.>>> 
 
Hi Mark,
 
Sorry for the late response, I got fully occupied at work for the past few days due to deliverables. Thanks for your feedback and further inputs!
 

I've not done any monitoring of

Re: Beadm can't create snapshot

[Ronald Klop]

Van: Kyle Evans 
Datum: maandag, 22 augustus 2022 17:11
Aan: Ronald Klop 
CC: Peter Jeremy , freebsd-current@freebsd.org, Ryan Moeller 
, "Patrick M. Hausen" 
Onderwerp: Re: Beadm can't create snapshot


On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop  wrote:
>
>
>
> Van: Peter Jeremy 
> Datum: maandag, 22 augustus 2022 10:45
> Aan: "Patrick M. Hausen" 
> CC: Ryan Moeller , freebsd-current@freebsd.org
> Onderwerp: Re: Beadm can't create snapshot
>
> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
> >Isn't beadm retired in favour of bectl?
>
> bectl still has a number of bugs:
> 1) The output from "bectl list" is in filesystem/bename order rather
>than creation date order.  This is an issue if you use (eg) git
>commit hashes as the name.
> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>root filesystem is mounted.
>
> That said "bectl create" appears to be a workable replacement for
> "beadm create" and avoids the current "'snapshots_changed' is
> readonly" bugs.
>
> --
> Peter Jeremy
> 
>
>
>
>
> Hi,
>
> From man bectl:
>  activate [-t | -T] beName
>Activate the given beName as the default boot filesystem.  If
>the -t flag is given, this takes effect only for the next boot.
>Flag -T removes temporary boot once configuration.  Without
>temporary configuration, the next boot will use zfs dataset
>specified in boot pool bootfs property.
>
> So it uses the bootfs property instead of loader.conf. If beadm used a 
different mechaniscm it would by nice to mention that in the HISTORY section of 
the bectl man page.
>

I was not aware that beadm touches loader.conf, but I find that
slightly horrifying. I won't personally make bectl do that, but I
guess I could at least document that it doesn't...






Hi,

Today I looked up something for boot environments myself and read this: 
https://wiki.freebsd.org/BootEnvironments#Setting_Boot_Dataset

"In order for boot environments to be effective, you must let the bootfs zpool 
property control which dataset gets mounted as the root. Particularly, /etc/fstab must be 
purged of any / mount, and /boot/loader.conf must not be setting vfs.root.mountfrom 
directly. "

So it is documented somewhere at least.

Regards,

Ronald.

Re: Beadm can't create snapshot

[Ronald Klop]

Van: Peter Jeremy 
Datum: maandag, 22 augustus 2022 10:45
Aan: "Patrick M. Hausen" 
CC: Ryan Moeller , freebsd-current@freebsd.org
Onderwerp: Re: Beadm can't create snapshot


On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
>Isn't beadm retired in favour of bectl?

bectl still has a number of bugs:
1) The output from "bectl list" is in filesystem/bename order rather
   than creation date order.  This is an issue if you use (eg) git
   commit hashes as the name.
2) "bectl activate" doesn't update /boot/loader.conf so the wrong
   root filesystem is mounted.

That said "bectl create" appears to be a workable replacement for
"beadm create" and avoids the current "'snapshots_changed' is
readonly" bugs.

--
Peter Jeremy



 



Hi,


From man bectl:

activate [-t | -T] beName
  Activate the given beName as the default boot filesystem.  If
  the -t flag is given, this takes effect only for the next boot.
  Flag -T removes temporary boot once configuration.  Without
  temporary configuration, the next boot will use zfs dataset
  specified in boot pool bootfs property.

So it uses the bootfs property instead of loader.conf. If beadm used a 
different mechaniscm it would by nice to mention that in the HISTORY section of 
the bectl man page.

Regards,
Ronald.

freebsd-current@freebsd.org

[Ronald Klop]

Thanks.

I use this pkg-status a lot to check my ports on aarch64 and was also missing 
ampere3.

👍

Regards,
Ronald.


Van: Mark Millard 
Datum: dinsdag, 14 juni 2022 07:44
Aan: Philip Paeps 
CC: freebsd-current , "cluster...@freebsd.org" 

Onderwerp: Re: ampere3 activity is not showing up on 
https://pkg-status.freebsd.org/?all=1&type=package


On 2022-Jun-13, at 22:14, Philip Paeps  wrote:

> On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
>> ampere3's activity is not showing up on the page:
>> https://pkg-status.freebsd.org/?all=1&type=package
>>
>> but:
>>
>> http://ampere3.nyi.freebsd.org/#latest_builds
>> and:
>> 
http://ampere3.nyi.freebsd.org/build.html?mastername=130arm64-default&build=b44e82e7d313
>>
>> shows a currently active build (but with only 2 ports remaining).
>
> pkg-status.freebsd.org is maintained on GitHub, outside the clusteradm 
automation.  I sent in this patch a couple of months ago, when I set up ampere3:
>
> https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files
>
> This was merged last week but it doesn't look like there's any automation to 
keep the running infrastructure in sync with that repository.  There were some 
reassuring screams in a logfile after I chanted some incantations in a the jail 
running pkg-status.freebsd.org.
>
> Let me know if that fixed it.
>

Well, I now see 34 builds that were via ampere3. This
was via use of:

https://pkg-status.freebsd.org/?all=1&type=package

They go back to 2022-Feb-26, with the most recent still
in progress (371 remaining).

Thanks.


===
Mark Millard
marklmi at yahoo.com

 

Re: buildworld fail: ld: error: undefined symbol: test_no_kevents

[Ronald Klop]

Hi,

Mmm, took another look. I doubt my clean build was clean as "wipe out 
workspace" did not work because the Jenkins agent was offline.

The problem might be PEBCAK[1]. :-)

Doing another build with a fresh Jenkins workspace now. Will take 10+ hours to 
compile clang for the millionth time.

Ronald.
[1] https://en.wiktionary.org/wiki/PEBCAK

Van: Dimitry Andric 
Datum: maandag, 6 juni 2022 12:16
Aan: Ronald Klop 
CC: freebsd-current , Mark Johnston 

Onderwerp: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents


Looks like it might be using an old version of 
tests/sys/kqueue/libkqueue/common.h, after 
https://cgit.freebsd.org/src/commit/?id=c728c56c870abe230e45cee5c477f0d890ebacef
 ?
 
Without seeing how the .o files have been compiled, specifically with which -I flags, it is impossible to see what is going wrong, though.
 
-Dimitry
 


On 6 Jun 2022, at 11:59, Ronald Klop  wrote:
 
Hi,


Building on aarch64/14-CURRENT fails with this error on my rpi4.
It failed on incremental build and tried a clean build today.

First failure was on "World build started on Sun May 29 00:25:17 UTC 2022".

This weekend it still fails (I'm building weekly in Jenkins).
10:04:44 ===> tests/sys/kqueue/libkqueue (all)
10:04:44 --- kqueue_test ---
10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  
DEPENDFILE=.depend.kqueue_test  NO_SUBDIR=1 /usr/bin/make -f 
/usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t  PROG=kqueue_test )
10:04:44 --- kqueue_test.full ---
10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -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 -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments  -pie  -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o  
10:04:44 ld: error: undefined symbol: test_no_kevents

10:04:45 >>> referenced by read.c:169 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:75 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:137 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced 31 more times
10:04:45 >>> did you mean: _test_no_kevents
10:04:45 >>> defined in: main.o
10:04:45 
10:04:45 ld: error: undefined symbol: kevent_cmp

10:04:45 >>> referenced by read.c:72 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:145 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:193 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced 14 more times
10:04:45 >>> did you mean: _kevent_cmp
10:04:45 >>> defined in: main.o
10:04:45 cc: error: linker command failed with exit code 1 (use -v to see 
invocation)
10:04:45   668.58 real   125.97 user62.12 sys
10:04:45 
10:04:45 make[1]: stopped in /usr/src
10:04:45 
10:04:45 make: stopped in /usr/src

10:04:45 Build step 'Execute shell' marked build as failure
10:04:46 Skipped archiving because build is not successful
10:04:46 Sending e-mails to: x...@.zzz
10:04:47 Finished: FAILURE

Any thoughts? Similar experience?

Regards,
Ronald.

 


 

buildworld fail: ld: error: undefined symbol: test_no_kevents

[Ronald Klop]

Hi,

Building on aarch64/14-CURRENT fails with this error on my rpi4.
It failed on incremental build and tried a clean build today.

First failure was on "World build started on Sun May 29 00:25:17 UTC 2022".

This weekend it still fails (I'm building weekly in Jenkins).
10:04:44 ===> tests/sys/kqueue/libkqueue (all)
10:04:44 --- kqueue_test ---
10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  
DEPENDFILE=.depend.kqueue_test  NO_SUBDIR=1 /usr/bin/make -f 
/usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t  PROG=kqueue_test )
10:04:44 --- kqueue_test.full ---
10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -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 -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments  -pie  -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o  
10:04:44 ld: error: undefined symbol: test_no_kevents

10:04:45 >>> referenced by read.c:169 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:75 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:137 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced 31 more times
10:04:45 >>> did you mean: _test_no_kevents
10:04:45 >>> defined in: main.o
10:04:45 
10:04:45 ld: error: undefined symbol: kevent_cmp

10:04:45 >>> referenced by read.c:72 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:145 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:193 
(/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
10:04:45 >>>   read.o:(test_evfilt_read)
10:04:45 >>> referenced 14 more times
10:04:45 >>> did you mean: _kevent_cmp
10:04:45 >>> defined in: main.o
10:04:45 cc: error: linker command failed with exit code 1 (use -v to see 
invocation)
10:04:45   668.58 real   125.97 user62.12 sys
10:04:45 
10:04:45 make[1]: stopped in /usr/src
10:04:45 
10:04:45 make: stopped in /usr/src

10:04:45 Build step 'Execute shell' marked build as failure
10:04:46 Skipped archiving because build is not successful
10:04:46 Sending e-mails to: x...@.zzz
10:04:47 Finished: FAILURE

Any thoughts? Similar experience?

Regards,
Ronald.

Re: Sanity limit for length of user/group names?

[Ronald Klop]

Hi,


A google search gives me this page: 
https://forums.freebsd.org/threads/username-length-16.28189/ .
It talks about MAXLOGNAME and limits in utmp. 



Regards,
Ronald


Van: Rick Macklem 
Datum: 13 april 2022 03:08
Aan: freebsd-current 
Onderwerp: Sanity limit for length of user/group names?




Hi,

The NFSv4 RFCs do not specify an upper limit for the length
of a user or group (called Owner/Owner_group in NFSv4) string.

However, PR#260546 notes that a sanity upper limit for their
length is needed.

Is there any constant in FreeBSD that defines the upper limit for
the length of a user or group name?
(I can find the maximum length of a hostname and I think that can
 be used as a safe upper limit for a domain name, as well. The Owner/
 Owner_group names include "@domain" on them.)

Thanks for any help with this, rick

Re: main-n254654-d4e8207317c results in "no pools available to import"

[Ronald Klop]

Van: Thomas Laus 
Datum: dinsdag, 12 april 2022 13:17
Aan: freebsd-current@freebsd.org
Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to 
import"


On 4/11/22 14:18, Ronald Klop wrote:
> On 4/11/22 17:17, Dennis Clarke wrote:
>>
>> Did the usual git pull origin main and buildworld/buildkernel but >> after 
installkernel the machine will not boot.
>>
>> The rev seems to be main-n254654-d4e8207317c.
>>
>> I can boot single user mode and get a command prompt but nothing past
>> that. Is there something borked in ZFS in CURRENT ?
>>
> Up until now you are the only one with this error on the mailinglist > today. 
So I doubt something is borked.
> You could consider to share more details about your setup to help people > to 
think along with you.
>
I can confirm this issue.  My last update was 'main-n253996-1b3af110bc' from March 31, 
2022 that worked fine.  My update yesterday received the same error and refused to boot 
past looking for kernel modules.  I did receive the "no pools available to 
import" message a couple of lines earlier.  My hardware is a Dell Inspiron laptop 
with a SSD and ZFS filesystem.  I have a little time today and plan on git reverting back 
to March 31 to further isolate the problem.

Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
 







Hi,

Are you guys both using NVME or EFI? Just wondering if the common problem is in 
ZFS or some other component.

Ronald.

Re: main-n254654-d4e8207317c results in "no pools available to import"

[Ronald Klop]

Van: Dennis Clarke 
Datum: dinsdag, 12 april 2022 10:41
Aan: freebsd-current@freebsd.org
Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to 
import"


On 4/11/22 14:18, Ronald Klop wrote:
> On 4/11/22 17:17, Dennis Clarke wrote:
>>
>> Did the usual git pull origin main and buildworld/buildkernel but >> after 
installkernel the machine will not boot.
>>
>> The rev seems to be main-n254654-d4e8207317c.
>>
>> I can boot single user mode and get a command prompt but nothing past
>> that. Is there something borked in ZFS in CURRENT ?
>>
>>
>>
>
>
> Up until now you are the only one with this error on the mailinglist > today. 
So I doubt something is borked.
> You could consider to share more details about your setup to help people > to 
think along with you.
>
> Regards,
> Ronald.

I am officially baffled.

I installed latest CURRENT snapshot on another system and then buildworld and 
buildkernel after checkout of d4e8207317c.

At reboot, with a serial console I can get to single user mode no problem :


.
.
.
cd0 at ahcich3 bus 0 scbus3 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: Serial Number K18C36A0237
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray 
closed
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0:  ACS-4 ATA SATA 3.x device
ada0: Serial Number S5VSNG0NB12944W
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 953869MB (1953525168 512 byte sectors)
ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0
ses0: pass1,cd0 in 'Slot 03', SATA Slot: scbus3 target 0
GEOM: new disk ada0
Root mount waiting for: usbus0
uhub0: 26 ports with 26 removable, self powered
ugen0.2:  at usbus0
efirtc0: providing initial system time
start_init: trying /sbin/init
Enter root password, or ^D to go multi-user
Password:
Enter full pathname of shell or RETURN for /bin/sh:
root@:/ # uname -apKU
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #0 d4e8207317c-n254654-d4e8207317c: 
Tue Apr 12 08:10:00 UTC 2022 
root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400056 1400056
root@:/ #


When I go to full multi-user mode I see the same message "no pools available to 
import" but the machine comes up just fine :



root@:/ # exit
Setting hostuuid: 688682c8-76df-3f6f-3af4-b06ebf2eb755.
Setting hostid: 0xc646c1f3.
no pools available to import
Fast boot: skipping disk checks.
Mounting local filesystems:.
Autoloading module: acpi_wmi
AuACPI: Processor \_PR_.CPU2 (ACPI ID 3) ignored
ACPI: Processor \_PR_.CPU3 (ACPI ID 4) ignored
ACPI: Processor \_PR_.CPU4 (ACPI ID 5) ignored
ACPI: Processor \_PR_.CPU5 (ACPI ID 6) ignored
ACPI: Processor \_PR_.CPU6 (ACPI ID 7) ignored
ACPI: Processor \_PR_.CPU7 (ACPI ID 8) ignored
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) 
(20220331/nsarguments-361)
acpi_wmi1:  on acpi0
acpi_wmi1: cannot find EC device
pci0: driver added
found-> vendor=0x8086, dev=0xa2ba, revid=0x00
 domain=0, bus=0, slot=22, func=0
 class=07-80-00, hdrtype=0x00, mfdev=1
 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords)
 lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 intpin=a, irq=16
 powerspec 3  supports D0 D3  current D0
 MSI supports 1 message, 64 bit
pci0:0:22:0: reprobing on driver added
found-> vendor=0x8086, dev=0xa2a1, revid=0x00
 domain=0, bus=0, slot=31, func=2
 class=05-80-00, hdrtype=0x00, mfdev=1
 cmdreg=0x0002, statreg=0x, cachelnsz=0 (dwords)
 lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
pci0:0:31:2: reprobing on driver added
found-> vendor=0x8086, dev=0xa2a3, revid=0x00
 domain=0, bus=0, slot=31, func=4
 class=0c-05-00, hdrtype=0x00, mfdev=0
 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords)
 lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 intpin=a, irq=16
pci0:0:31:4: reprobing on driver added
ichsmb0:  port 0xf040-0xf05f mem 
0xf712a000-0xf712a0ff irq 16 at device 31.4 on pci0
ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 2 vector 53
smbus0:  on ichsmb0
pci1: driver added
pci2: driver added
toloading module: ichsmb
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 
/usr/local/lib/compat/pkg /usr/local/lib/compat/pkg 
/usr/local/lib/perl5/5.32/malo0: link state changed to UP
ch/CORE
32-bit compatibility ldconfig path: /usre0: link state changed to DOWN
r/lib32
Setting hostname: europa.
Setting up harvesting: 
PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
Starting Network: lo0 re0

Re: DHCPDv6 in non-vnet jail

[Ronald Klop]

Hi,

First. I'm not an IPv6 expert. Got it running at home. Although with SLAAC, not 
DHCP yet.
Another disclaimer is that I use VNET-jails nowadays.
But I like to try and think along with you.

What surprises me is that your non-vnet jail does not have a LINKLOCAL fe80::: 
address. These addresses are used for configuration in the local network 
(AFAIK).
And your routing table does not contain a line like this:
ff02::/16 ::1   UGRSlo0

So how is the ff02:: multicast routed in your network?

But the tcpdump shows that the multicast solicit message is received on the 
non-vnet dhcp-server so that seems to work:
18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > 
ff02::1:2.dhcpv6-server: dhcp6 solicit
I don't know if the dhcp-server program also sees this request coming in on its 
interface. Maybe extra logging can help there.

According to https://en.wikipedia.org/wiki/DHCPv6#Example the dhcp-server would 
reply with a link-local fe80:: address.
"Server replies with an advertise from [fe80::0011:22ff:fe33:5566]:547 to 
[fe80::aabb:ccff:fedd:eeff]:546."
But your dhcp-server does not have an fe80::.

So I'm wondering how that would work.

More questions than answers. But I hope it helps.

Regards,
Ronald.



Van: "Goran Mekic" 
Datum: dinsdag, 29 maart 2022 18:11
Aan: Ronald Klop 
CC: freebsd-current@freebsd.org, "Bjoern A. Zeeb" 

Onderwerp: Re: DHCPDv6 in non-vnet jail


On Tue, Mar 29, 2022 at 12:14:20PM +0200, Ronald Klop wrote:
> I think it will help if you share more of your configuration/logs.
Inside non-vnet jail, this is ifconfig output
cbsd0: flags=8843 metric 0 mtu 1500
description: lagg0
ether 58:9c:fc:10:9b:75
inet 172.16.0.253 netmask 0x broadcast 172.16.0.253
inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair1a flags=143
ifmaxaddr 0 port 7 priority 128 path cost 2000
member: epair5a flags=143
ifmaxaddr 0 port 11 priority 128 path cost 2000
member: epair4a flags=143
ifmaxaddr 0 port 10 priority 128 path cost 2000
member: epair3a flags=143
ifmaxaddr 0 port 9 priority 128 path cost 2000
member: epair2a flags=143
ifmaxaddr 0 port 8 priority 128 path cost 2000
groups: bridge
nd6 options=21

There are bunch of other interfaces, but only cbsd0 (bridge interface)
is set up with ip address.


netstat -rn
Routing tables

Internet:
DestinationGatewayFlags Netif Expire
172.16.0.253   link#4 UHcbsd0

Internet6:
Destination   Gateway   Flags Netif 
Expire
fd10:6c79:8ae5:8b91::2link#4UHS lo0


grep -v '^#' /usr/local/etc/dhcpd6.conf

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
allow leasequery;
option dhcp6.name-servers 3ffe:501::100:200:ff:fe00:3f3e;
option dhcp6.domain-search "test.example.com","example.com";
option dhcp6.info-refresh-time 21600;
dhcpv6-lease-file-name "/var/db/dhcpd6/dhcpd6.leases";

subnet6 fd10:6c79:8ae5:8b91::/64 {
  range6 fd10:6c79:8ae5:8b91::/64;
}


ls -l /dev
total 1
crw---  1 root  wheel   0x26 Mar 29 17:35 bpf
lrwxr-xr-x  1 root  wheel  3 Mar 28 09:31 bpf0 -> bpf
crw-rw-rw-  1 root  wheel   0x4a Mar 26 15:54 crypto
dr-xr-xr-x  2 root  wheel512 Mar 29 03:38 fd
crw-rw-rw-  1 root  wheel   0x2a Mar 29 18:00 null
crw-rw  1 root  nsd0x1a5 Mar 24 23:45 pf
crw-rw  1 root  nsd 0x4b Mar 26 15:54 pfil
dr-xr-xr-x  2 root  wheel512 Mar 28 09:31 pts
crw-r--r--  1 root  wheel0x8 Mar 24 23:45 random
lrwxr-xr-x  1 root  wheel  4 Mar 28 09:31 stderr -> fd/2
lrwxr-xr-x  1 root  wheel  4 Mar 28 09:31 stdin -> fd/0
lrwxr-xr-x  1 root  wheel  4 Mar 28 09:31 stdout -> fd/1
lrwxr-xr-x  1 root  wheel  6 Mar 28 09:31 urandom -> random
crw-rw-rw-  1 root  wheel   0x2b Mar 26 15:54 zero



On the host I have /etc/rtadvd.conf:
cbsd0:addr="fd10:6c79:8ae5:8b91::":raflags="m"


On the host ifconfig cbsd0
cbsd0: flags=8843 metric 0 mtu 1500
description: lagg0
ether 58:9c:fc:10:9b:75
inet 172.16.0.254 netmask 0xff00 broadcast 172.16.0.255
inet 172.16.1.254 netmask 0xff00 broadcast 172.16.1.255
inet 172.16.0.253 netmask 0x broadcast 172.16.0.253
inet6 fe80::5a9c:fcff:fe10:9b75%cbsd0 prefixlen 64 scopeid 0x4
inet6 fd10:6c79:8ae5:8b91::1 prefixlen 64
inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 

Re: "set but not used" warnings in the kernel

[Ronald Klop]

Is it time for WARNS=7 in the Makefiles?

Regards,
Ronald.


Van: Mateusz Guzik 
Datum: dinsdag, 29 maart 2022 13:15
Aan: freebsd-current@freebsd.org
Onderwerp: "set but not used" warnings in the kernel


This is way too spammy and there is no consistent effort to clean them up,
that I can see anyway.

As such, I think these warns are doing more damage than help and should be
disabled by default.

Alternatively, perhaps people can step up. I'm pretty sure to date I got
rid of more of these than anyone else.

Comments?
--
Mateusz Guzik 
 

Re: DHCPDv6 in non-vnet jail

[Ronald Klop]

Van: "Goran Mekic" 
Datum: dinsdag, 29 maart 2022 10:11
Aan: "Bjoern A. Zeeb" 
CC: freebsd-current@freebsd.org
Onderwerp: Re: DHCPDv6 in non-vnet jail


On Sun, Mar 27, 2022 at 02:34:11PM +, Bjoern A. Zeeb wrote:
> I assume you have /dev/bpf available inside that jail by a devfs rule so
> effectively you have all network interfaces and traffic available?
As a form of test I've put rtadvd inside the same non-vnet jail and I
can see RA message arrive to the vnet jail. I though I "disconnected"
something concerning IPv6, but that's obviously not the case.

Let's take a step back. Is there any howto/tutorial on how to put
isc-dhcpd6 in a non-vnet jail? I don't care if it's jail.conf or some
jail manager. Can I somehow see where packets end up, like dtrace?
Should I try some other server/client for DHCPv6? If I can make it work
in any scenario, that would be good starting point for me to figure out
what's wrong with my current setup.

Regards,
meka



 



Hi,

I think it will help if you share more of your configuration/logs.
Besides you can take a look with tcpdump/wireshark on what happens on different 
interfaces of your machines to see the traffic flow between client and server.

Regards,
Ronald.

Re: running cron jobs setpriority permission denied

[Ronald Klop]

It sounds similar to this issue.

https://github.com/cbsd/cbsd/issues/437 "default nice 1 prevents cron in jail 
#437"

Does that help?

Regards,
Ronald.


Van: Sami Halabi 
Datum: dinsdag, 8 maart 2022 22:00
Aan: freebsd-sta...@freebsd.org, FreeBSD Current , 
freebsd-j...@freebsd.org, freebsd-...@freebsd.org, Oleg Ginzburg 
Onderwerp: running cron jobs setpriority permission denied


Hi,
 
I have a jail ran by cbsd which has a cronjob like this:

* * * * * root /usr/local/directadmin/dataskq
 
I see every minute this error logged in /var/log/messages:

cron[71002]: setpriority 'root' (daemon): Permission denied
 
I see in ps xau that it runs but at nobody user
 
even when loggin to the jail I have:

cron[68825]: setpriority 'root' (daemon): Permission denied
login[68900]: setpriority 'root' (root): Permission denied
jexec[69404]: setpriority 'root' (root): Permission denied
 
# uname -a

FreeBSD j5.sody.com 12.3-RELEASE-p1 FreeBSD 12.3-RELEASE-p1 GENERIC  amd64
 
what am I missing?
 
Sami
 
--

Sami Halabi
Information Systems Engineer
NMS Projects Expert, FreeBSD SysAdmin Expert
Asterisk Expert

Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Ronald Klop]

Van: Mark Johnston 
Datum: maandag, 7 maart 2022 16:13
Aan: Ronald Klop 
CC: bob prohaska , Mark Millard , 
freebsd-...@freebsd.org, freebsd-current 
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: 
panic: Unknown kernel exception 0 esr_el1 200 (on 14-CURRENT/aarch64 Feb 
28))


On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:
> Dear Mark Johnston,
>
> I did some binary search in the kernels and came to the conclusion that 
https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e 
still works and 
https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a 
panics.
>
> I suspect your commit in 
https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.
>
> Last panic:
>
> panic: vm_fault failed: 0046e708 error 1
> cpuid = 1
> time = 1646660058
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2e8
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x9604
> _rm_rlock_debug() at _rm_rlock_debug+0x8c
> osd_get() at osd_get+0x5c
> zio_execute() at zio_execute+0xf8
> taskqueue_run_locked() at taskqueue_run_locked+0x178
> taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 0 tid 100129 ]
> Stopped at  kdb_enter+0x44: undefined   f902011f
> db>
>
> A more recent kernel (912df91) still panics. See below.
>
> Do you have time to look into this? What can I provide in information to help?

Hmm.  So after my rmlock commits, we have the following disassembly for
_rm_rlock() (with a few annotations added by me).  Note that the pcpu
pointer is stored in register x18 by convention.

   0x0046e304 <+0>: stp x29, x30, [sp, #-16]!
   0x0046e308 <+4>: mov x29, sp
   0x0046e30c <+8>: ldr x8, [x18]
   0x0046e310 <+12>:ldr x9, [x18]
   0x0046e314 <+16>:ldr x10, [x18]
   0x0046e318 <+20>:cmp x9, x10
   0x0046e31c <+24>:b.ne0x0046e3cc <_rm_rlock+200>  // 
b.any
   0x0046e320 <+28>:ldr x9, [x18]
   0x0046e324 <+32>:ldrhw9, [x9, #314]
   0x0046e328 <+36>:cbnzw9, 0x0046e3c0 <_rm_rlock+188>
   0x0046e32c <+40>:str wzr, [x1, #32]
   0x0046e330 <+44>:stp x0, x8, [x1, #16]
   0x0046e334 <+48>:ldrbw9, [x0, #10]
   0x0046e338 <+52>:tbz w9, #4, 0x0046e358 
<_rm_rlock+84>
   0x0046e33c <+56>:ldr x9, [x18]
   0x0046e340 <+60>:ldr w10, [x9, #888]
   0x0046e344 <+64>:add w10, w10, #0x1
   0x0046e348 <+68>:str w10, [x9, #888]
   0x0046e34c <+72>:ldr x9, [x18]
   0x0046e350 <+76>:ldr w9, [x9, #888]
   0x0046e354 <+80>:cbz w9, 0x0046e3f4 <_rm_rlock+240>
   0x0046e358 <+84>:ldr w9, [x8, #1212]
   0x0046e35c <+88>:add x10, x18, #0x90
   0x0046e360 <+92>:add w9, w9, #0x1
   0x0046e364 <+96>:str w9, [x8, #1212]  <--- critical_enter
   0x0046e368 <+100>:   str x10, [x1, #8]
   0x0046e36c <+104>:   ldr x9, [x18, #144]
   0x0046e370 <+108>:   str x9, [x1]
   0x0046e374 <+112>:   str x1, [x9, #8]
   0x0046e378 <+116>:   str x1, [x18, #144]
   0x0046e37c <+120>:   ldr x9, [x18]
   0x0046e380 <+124>:   ldr w10, [x9, #356]
   0x0046e384 <+128>:   add w10, w10, #0x1
   0x0046e388 <+132>:   str w10, [x9, #356]
   0x0046e38c <+136>:   ldr w9, [x8, #1212]
   0x0046e390 <+140>:   sub w9, w9, #0x1
   0x0046e394 <+144>:   str w9, [x8, #1212]  <--- critical_exit
   0x0046e398 <+148>:   ldrbw8, [x8, #304]
   0x0046e39c <+152>:   ldr w9, [x18, #60]   <--- loading 
&pc->pc_cpuid
   ...

A (the?) problem is that the compiler is treating "pc" as an alias
for x18, but the rmlock code assumes that the pcpu pointer is loaded
once, as it dereferences "pc" outside of the critical section.  On
arm64, if a context switch occurs between the store at _rm_rlock+144 and
the load at +152, and the thread is migrated to another CPU, then we'll
end up using the wrong CPU ID in the rm-

Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Ronald Klop]

Dear Mark Johnston,

I did some binary search in the kernels and came to the conclusion that 
https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e
 still works and 
https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a
 panics.

I suspect your commit in 
https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.

Last panic:

panic: vm_fault failed: 0046e708 error 1
cpuid = 1
time = 1646660058
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2e8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x9604
_rm_rlock_debug() at _rm_rlock_debug+0x8c
osd_get() at osd_get+0x5c
zio_execute() at zio_execute+0xf8
taskqueue_run_locked() at taskqueue_run_locked+0x178
taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 0 tid 100129 ]
Stopped at  kdb_enter+0x44: undefined   f902011f
db>

A more recent kernel (912df91) still panics. See below.

Do you have time to look into this? What can I provide in information to help?

Regards,
Ronald.


Van: Ronald Klop 
Datum: maandag, 7 maart 2022 11:38
Aan: Mark Millard 
CC: bob prohaska , freebsd-current 
, freebsd-...@freebsd.org
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: 
panic: Unknown kernel exception 0 esr_el1 200 (on 14-CURRENT/aarch64 Feb 
28))


Yes, I spoke to soon too. Often it crashes as soon as I start a parallel 
poudriere build. But this time it went very far. As soon as nightly backups 
kicked in it was game over again.
I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusion 
that it is about the same problem to the developers. (Have seen enough of wrong 
guessing of causes in my work. )

I will need to go further into the binary search of working kernels.

This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 2022
Fatal data abort:   
  x0: 00f1efd8  x0: 00f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)

  x1:2  x1:2

  x2: 0087dcf2  x2: 0087dcf2 (cam_status_table + 2f28a) 
 (cam_status_table + 2f28a)  x3: 0087dcf2   
  x3: 0087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)

  x4:  102  x4:  102

  x5:7  x5:1

  x6:0  x6:   ff

  x7:0  x7: a00011fc2800
  x8:1  

  x8:1  x9: 00f37c10
  x9: 419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)  

 x10: a0017be2a600 x10: a10fa

Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Ronald Klop]

)
   
x17: 0044a998 x17: 0058ff30 (free + 0) (if_inc_counter + 0)
   
x18: b49a23c0 x18: 000103f11b80 (g_ctx + b3242314) 
(next_index + 3a228c0) x19:  102   

  
x19:  102 x20: b49a2428
x20: 000103f11be8 (g_ctx + b324237c) (next_index + 3a22928)


x21: 0087dcf2 x21: 0087dcf2 (cam_status_table + 2f28a) 
(cam_status_table + 2f28a)

x22: 00f1efd8 x22: 00f1efd8 (mac_policy_rm + 0) (mac_policy_rm 
+ 0)

x23: 0086f107 x23:0 (cam_status_table + 2069f)

x24: a0001fbde6c8 x24: a0008cba0d00
x25:0

x25: 0088aa11 x26:4 (do_execve.fexecv_proc_title + 76b7)

x27:0 x26: a0017be2a600
x28: 00010209fcf0
x27: a00025626a80 (next_index + 1bb0a30)

x28: 000103f11ce0 x29: b49a23e0 (next_index + 3a22a20) (g_ctx + 
b3242334)

x29: 000103f11ba0  sp: b49a23c0
(next_index + 3a228e0)  lr: 0046ef98
 sp: 000103f11b80
(_rm_runlock_debug + 60)  lr: 0046ef98
elr: 0046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)

elr: 0046dc0cspsr:   45
(_rm_assert + a4) far:   10

esr: 9604
spsr:   45

panic: data abort in critical section or under mutex
cpuid = 1
time = 1646609483
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2d4
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x9604
_rm_assert() at _rm_assert+0xa4
_rm_runlock_debug() at _rm_runlock_debug+0x5c
mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
tcp_input_with_port() at tcp_input_with_port+0xab4
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x2e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_demux() at ether_demux+0x178
ether_nh_input() at ether_nh_input+0x3e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_input() at ether_input+0x80
if_input() at if_input+0xc
gen_intr() at gen_intr+0x444
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100063 ]
Stopped at  kdb_enter+0x44: undefined   f902011f
db>

NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi 
connected power switch on it.

Regards,
Ronald.


Van: Mark Millard 
Datum: maandag, 7 maart 2022 02:01
Aan: Ronald Klop 
CC: freebsd-current , bob prohaska 

Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: 
panic: Unknown kernel exception 0 esr_el1 200 (on 14-CURRENT/aarch64 Feb 
28))


From: Ronald Klop  wrote on
Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :

> Did some binary search with kernels from artifact.ci.freebsd.org.
>
> I suspect "rmlock: Micro-optimize read locking" as cause.
>
> 
https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a
>
>
> And "rmlock: Add required compiler barriers to _rm_runlock()" as solution.
>
> 
https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f
>
>
> So I probably just had a bad day.

Well, there is a report of a buildkernel crash after that pair:

https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html

that references additional information at:

http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme

and reported:

QUOTE
The console connection dropped before the crash (unrelated) I didn't
get the preamble, all  I have is the backtrace and buildkernel log.
Here's the backtrace:
db> bt
Tracing pid 14795 tid 100098 td 0xa00017815600
db_trace_self() at db_trace_self
db_stack_trace() at db_stack_trace+0x11c
db_command() at db_command+0x368
db_command_loop() at db_command_loop+0x54
db_trap() at db_trap+0xf8
kdb_trap() at kdb_trap+0x1cc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0xf200
kdb_enter() at kdb_enter+0x44
vpanic() at vpanic+0x1b0
panic() at panic+0x44
data_abort() at data_abort+0x2e8
handle_el1h_sync() at handle_el1h_syn

Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Ronald Klop]

Hi,

Did some binary search with kernels from artifact.ci.freebsd.org.

I suspect "rmlock: Micro-optimize read locking" as cause.
https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a

And "rmlock: Add required compiler barriers to _rm_runlock()" as solution.
https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f

So I probably just had a bad day.

Regards,
Ronald.


Van: Ronald Klop 
Datum: zaterdag, 5 maart 2022 16:09
Aan: FreeBSD Current 
Onderwerp: panic: data abort in critical section or under mutex (was: Re: 
panic: Unknown kernel exception 0 esr_el1 200 (on 14-CURRENT/aarch64 Feb 
28))


Hi,

Another panic while building world/kernel. Different panic message and trace.
 
  x0: 1f5e152c32cc   
  x1: b630a000 (g_ctx + b4c4a254)   
  x2:1  
  x3:   2e  
  x4: a000bb46d600  
  x5:0  
  x6:0  x7: 00f05104 (has_pan + 0)

  x8:1
  x9: 809c227c
 x10:   bd
 x11:   40
 x12:0
 x13:1
 x14: 1782f000
 x15: 1001
 x16: 1782f003
 x17: 1f5e957392f0
 x18: 00010719e630 (next_index + 2cac528)
 x19: 00010719e768 (next_index + 2cac660)
 x20:1
 x21: b630a000 (g_ctx + b4c4a254)
 x22:1
 x23: ffbf
 x24: 00010719e758 (next_index + 2cac650)
 x25: a00026cdd160
 x26:1
 x27: a000bb46d600
 x28: 0092815a (do_execve.fexecv_proc_title + 5483)
 x29: 00010719e630 (next_index + 2cac528)
  sp: 00010719e630
  lr: 0053e890 (uiomove_faultflag + 128)
 elr: 00804f80 (byte_by_byte + 4)
spsr:   45
 far: b630a000 (g_ctx + b4c4a254)
 esr: 9647
panic: data abort in critical section or under mutex
cpuid = 2
time = 1646489189
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2a8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x9647
byte_by_byte() at byte_by_byte+0x4
pipe_write() at pipe_write+0x668
KDB: enter: panic
[ thread pid 68336 tid 100593 ]
Stopped at  kdb_enter+0x44: undefined   f901c11f
db>



Regards,
Ronald.


 
Van: Ronald Klop 

Datum: zaterdag, 5 maart 2022 12:16
Aan: FreeBSD Current 
Onderwerp: panic: Unknown kernel exception 0 esr_el1 200 (on 
14-CURRENT/aarch64 Feb 28)


Hi,

Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly 
backup is started.
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 
06:12:48 CET 2022 
ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG
 arm64

It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 
main-e11ad014d1-dirty: Sat Feb  5 00:09:08 CET 2022".

It runs ZFS-on-root via an USB disk. No other FS involved.
# gpart show
=>40  1953458096  da0  GPT  (931G)
  40  1024001  efi  (50M)
  102440 83886082  freebsd-swap  (4.0G)
 8491048  19449670883  freebsd-zfs  (927G)


Output on serial console:
x0: a59c1380   
  x1: a59b1600  
  x2:3  
  x3: a001862779a0  
  x4:0
  x5:9438238792a1a

  x6:d217e9df58308
  x7:   14
  x8: a59c1398
  x9:1
 x10: a59b1600
 x11:2
 x12:1
 x13: f2557a42c5b0f240
 x14: 1013e6b85a8ecbe4
 x15: 24f981889f30
 x16: 4afedeb89cb8
 x17: fff2
 x18: fe666800 (g_ctx + fcfa6a54)
 x19:0
 x20: fec41000 (g_ctx + fd581254)
 x21:3
 x22: 419bb090 (g_ctx + 402fb2e4)
 x23: 

panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

[Ronald Klop]

Hi,

Another panic while building world/kernel. Different panic message and trace.

 x0: 1f5e152c32cc   
 x1: b630a000 (g_ctx + b4c4a254)   
 x2:1  
 x3:   2e  
 x4: a000bb46d600  
 x5:0  
 x6:0  x7: 00f05104 (has_pan + 0)

 x8:1
 x9: 809c227c
x10:   bd
x11:   40
x12:0
x13:1
x14: 1782f000
x15: 1001
x16: 1782f003
x17: 1f5e957392f0
x18: 00010719e630 (next_index + 2cac528)
x19: 00010719e768 (next_index + 2cac660)
x20:1
x21: b630a000 (g_ctx + b4c4a254)
x22:1
x23: ffbf
x24: 00010719e758 (next_index + 2cac650)
x25: a00026cdd160
x26:1
x27: a000bb46d600
x28: 0092815a (do_execve.fexecv_proc_title + 5483)
x29: 00010719e630 (next_index + 2cac528)
 sp: 00010719e630
 lr: 0053e890 (uiomove_faultflag + 128)
elr: 00804f80 (byte_by_byte + 4)
spsr:   45
far: b630a000 (g_ctx + b4c4a254)
esr: 9647
panic: data abort in critical section or under mutex
cpuid = 2
time = 1646489189
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2a8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x9647
byte_by_byte() at byte_by_byte+0x4
pipe_write() at pipe_write+0x668
KDB: enter: panic
[ thread pid 68336 tid 100593 ]
Stopped at  kdb_enter+0x44: undefined   f901c11f
db>



Regards,
Ronald.



Van: Ronald Klop 
Datum: zaterdag, 5 maart 2022 12:16
Aan: FreeBSD Current 
Onderwerp: panic: Unknown kernel exception 0 esr_el1 200 (on 
14-CURRENT/aarch64 Feb 28)


Hi,

Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly 
backup is started.
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 
06:12:48 CET 2022 
ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG
 arm64

It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 
main-e11ad014d1-dirty: Sat Feb  5 00:09:08 CET 2022".

It runs ZFS-on-root via an USB disk. No other FS involved.
# gpart show
=>40  1953458096  da0  GPT  (931G)
  40  1024001  efi  (50M)
  102440 83886082  freebsd-swap  (4.0G)
 8491048  19449670883  freebsd-zfs  (927G)


Output on serial console:
x0: a59c1380   
  x1: a59b1600  
  x2:3  
  x3: a001862779a0  
  x4:0
  x5:9438238792a1a

  x6:d217e9df58308
  x7:   14
  x8: a59c1398
  x9:1
 x10: a59b1600
 x11:2
 x12:1
 x13: f2557a42c5b0f240
 x14: 1013e6b85a8ecbe4
 x15: 24f981889f30
 x16: 4afedeb89cb8
 x17: fff2
 x18: fe666800 (g_ctx + fcfa6a54)
 x19:0
 x20: fec41000 (g_ctx + fd581254)
 x21:3
 x22: 419bb090 (g_ctx + 402fb2e4)
 x23: 00c09bb7 (lockstat_enabled + 0)
 x24:  180
 x25: 00c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x26: 00c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x27: 00c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x28:0
 x29: fe666800 (g_ctx + fcfa6a54)
  sp: fe666800
  lr: 0154ca38 (zio_dva_throttle + 13c)
 elr: 0154ca80 (zio_dva_throttle + 184)
spsr: 2045
 far: 1f24979f8000
panic: Unknown kernel exception 0 esr_el1 200
cpuid = 2
time = 1646433952
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do

panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)

[Ronald Klop]

Hi,

Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly 
backup is started.
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 
06:12:48 CET 2022 
ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG
 arm64

It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 
main-e11ad014d1-dirty: Sat Feb  5 00:09:08 CET 2022".

It runs ZFS-on-root via an USB disk. No other FS involved.
# gpart show
=>40  1953458096  da0  GPT  (931G)
 40  1024001  efi  (50M)
 102440 83886082  freebsd-swap  (4.0G)
8491048  19449670883  freebsd-zfs  (927G)


Output on serial console:
x0: a59c1380   
 x1: a59b1600  
 x2:3  
 x3: a001862779a0  
 x4:0
 x5:9438238792a1a

 x6:d217e9df58308
 x7:   14
 x8: a59c1398
 x9:1
x10: a59b1600
x11:2
x12:1
x13: f2557a42c5b0f240
x14: 1013e6b85a8ecbe4
x15: 24f981889f30
x16: 4afedeb89cb8
x17: fff2
x18: fe666800 (g_ctx + fcfa6a54)
x19:0
x20: fec41000 (g_ctx + fd581254)
x21:3
x22: 419bb090 (g_ctx + 402fb2e4)
x23: 00c09bb7 (lockstat_enabled + 0)
x24:  180
x25: 00c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
x26: 00c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
x27: 00c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
x28:0
x29: fe666800 (g_ctx + fcfa6a54)
 sp: fe666800
 lr: 0154ca38 (zio_dva_throttle + 13c)
elr: 0154ca80 (zio_dva_throttle + 184)
spsr: 2045
far: 1f24979f8000
panic: Unknown kernel exception 0 esr_el1 200
cpuid = 2
time = 1646433952
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x200
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100128 ]
Stopped at  kdb_enter+0x44: undefined   f901c11f
db>


I'm going to build a newer kernel to see if the problem persists. I can keep 
the current kernel to reproduce this if needed.

Regards,
Ronald.

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Ronald Klop]

Hi,


Where would this sysctl needed to be documented  for the OP to find it?


Regards,
Ronald




Van: Toomas Soome 
Datum: 28 februari 2022 08:29
Aan: Michael Schuster 
CC: FreeBSD CURRENT 
Onderwerp: Re: "vidcontrol -i mode" shows no output except header (in search of 
smaller console font)








On 28. Feb 2022, at 08:23, Michael Schuster  wrote:

Hi Toomas,


On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  wrote:





On 27. Feb 2022, at 23:36, Michael Schuster  wrote:

Hi all,

I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD CURRENT from last week. 



__blockquote_end__
[...] 




UEFI or BIOS setup?



UEFI
 
__blockquote_end__


UEFI
 
__blockquote_start__

 With UEFI, sc and hw.vga.textmode has no effect. With UEFI or 
BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will 
cause the values list to be printed), or use loadfont command with your custom 
font file (created with vtfontcvt).



I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm first time. 


Many thanks!
Michael


You are welcome.

rgds,
toomas

Re: question on socket server

[Ronald Klop via freebsd-current]

Hi,

Your program first waits for the first client to connect. So nothing is written 
anywhere.
You can check by running "nc -v localhost " in another terminal.
After the first client disconnects it keeps looping in the while and the print 
will return 0 which means failure.

Something 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 generic perl 
forum/ML.


Van: Piper H 
Datum: woensdag, 15 december 2021 11:55
Aan: Ronald Klop 
CC: freebsd-current@freebsd.org
Onderwerp: Re: question on socket server


But I write this program to listen on port  who sends a random str to the 
socket every 0.25 second. And there is no client connecting to the port. The 
server just runs there without problem. :( So I am not sure enough...
 
use strict;


package MyPackage;
use base qw(Net::Server);


my @fruit=qw(
...
);


sub process_request {
my $self = shift;
$| = 1;
my $max = scalar @fruit;

while (1) {
my $id1 = int(rand($max));
my $str = $fruit[$id1];

print "$str\015\012";
select(undef, undef, undef, 0.25);
}
}
 
MyPackage->run(port => , ipv => '*');
 
On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop  wrote:


Hi,

Just try it!

I think you will get an error that you are writing to a not-connected socket.
From "man 2 write":
" [EPIPE]An attempt is made to write to a socket of type SOCK_STREAM 
that is not connected to a peer socket."

See also "man 2 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 little knowledge about socket programming.
I have a question that, if I have made a socket server, listening on a
port. The server prints data to the socket, but there is never a client
connection to the port, and the data is never consumed. What will happen to
the server then? will the OS kernel be flushed by junk bytes?

Thanks for your help.
Piper

Re: question on socket server

[Ronald Klop via freebsd-current]

Hi,

Just try it!

I think you will get an error that you are writing to a not-connected socket.

From "man 2 write":

" [EPIPE]An attempt is made to write to a socket of type SOCK_STREAM 
that is not connected to a peer socket."

See also "man 2 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 little knowledge about socket programming.
I have a question that, if I have made a socket server, listening on a
port. The server prints data to the socket, but there is never a client
connection to the port, and the data is never consumed. What will happen to
the server then? will the OS kernel be flushed by junk bytes?

Thanks for your help.
Piper

Re: How do I find out what changed for an freebsd release update?

[Ronald Klop]

See https://cgit.freebsd.org/src/log/?h=releng/12.2
Everything on 2021-06-29.


Regards,
Ronald.


Van: Rick Macklem 
Datum: 16 oktober 2021 01:49
Aan: FreeBSD Current 
Onderwerp: How do I find out what changed for an freebsd release update?




Hi,

PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when
the server was upgraded from 12.2-p8 to 12.2-p9.
I know that nothing changed in NFS server code, but how can I find out
what did get changed by that update?

Thanks in advance for any help, rick

Re: -CURRENT compilation time

[Ronald Klop]

Van: David Chisnall 
Datum: maandag, 6 september 2021 11:43
Aan: freebsd-current@freebsd.org
Onderwerp: Re: -CURRENT compilation time


On 06/09/2021 09:08, Jeremie Le Hen wrote:
> Compiling C++ seems
> extremely CPU heavy and this is made worse by the fact LLVM is built
> twice (once for build/cross tools, once for the actual world).

Note that you need to build LLVM twice only if you are actively debugging LLVM 
reproduceable deployment images.  You actually don't need to build it at all, 
you can use an external toolchain to skip the first build and you can compile 
WITHOUT_TOOLCHAIN  to avoid building the version that's installed and then 
install a toolchain from packages:

https://wiki.freebsd.org/ExternalToolchain

David

 






Hi,

I'm very interested in a base without llvm because of compile times. So I tried 
this in a jail with 14-current and pkg llvm12 installed.

/etc/make.conf:
WITHOUT_TOOLCHAIN=yes
CROSS_TOOLCHAIN=llvm12

Buildworld, installworld and etcupdate went fine. "yes | make delete-old" 
removes the toolchain from base.
Afterwards you can't do buildworld anymore.

# make buildworld
sh: cc: not found
make: "/home/ronald/dev/freebsd/share/mk/bsd.compiler.mk" line 200: warning: "cc -v 2>&1 | 
grep "gcc version"" returned non-zero status
make: "/home/ronald/dev/freebsd/share/mk/bsd.compiler.mk" line 204: Unable to 
determine compiler type for CC=cc.  Consider setting COMPILER_TYPE.

What am I missing?

Regards,
Ronald.

Re: Encrypted swap partition no longer encrypted

[Ronald Klop]

Hi,

For encrypted swap you can put ".eli" behind the device name in fstab.

So change "/dev/ada0p2" to "/dev/ada0p2.eli" in the new fstab and reboot.
NB: after encryption is enabled the device is not available as dumpdev anymore.

I don't know what caused the change for you.

Regards,
Ronald.


Van: Graham Perrin 
Datum: vrijdag, 27 augustus 2021 09:57
Aan: FreeBSD CURRENT 
Onderwerp: Encrypted swap partition no longer encrypted


Yesterday afternoon I installed FreeBSD-CURRENT to a hard disk drive, whilst it 
was in a dock on USB, and chose encrypted swap.

Then, ZFS send and receive to replicate data from a pool that was on the 
internal drive. Finally, I replaced the internal drive with the one from the 
dock.

Now: swap is not encrypted, this was not my intention.

Might the accident have resulted from an inappropriate change to /etc/fstab 
followed by a swapon command?

I did, at one point, activate and boot the wrong boot environment (because 
`bectl list -c creation` can no longer show the true (original) dates of 
creation of boot environments that were replicated).



root@mowa219-gjp4-8570p-freebsd:~ # bectl mount default /tmp/huh
Successfully mounted default at /tmp/huh
root@mowa219-gjp4-8570p-freebsd:~ # cat /tmp/huh/etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
/dev/da0p1  /boot/efi   msdosfs rw 2   2
/dev/da0p2.eli  noneswapsw  0   0
root@mowa219-gjp4-8570p-freebsd:~ # bectl umount default
root@mowa219-gjp4-8570p-freebsd:~ # grep swap /etc/fstab | grep -v \#
/dev/ada0p2 noneswap sw,late0 0
root@mowa219-gjp4-8570p-freebsd:~ # grep ada0 /etc/rc.conf
dumpdev="/dev/ada0p2"
root@mowa219-gjp4-8570p-freebsd:~ # bectl list -c creation
BE Active Mountpoint Space Created
default-  -  789M  2021-08-26 16:33
n247565-b49ba74deeb-f  -  -  39.6G 2021-08-26 19:50
n248685-c9f833abf1d-f  NR /  49.3G 2021-08-26 21:13
14.0-CURRENT_2021-08-19_045942 -  -  1.09G 2021-08-26 22:41
n248269-941650aae97-e  -  -  40.5M 2021-08-26 22:54
n247798-f39dd6a9784-a  -  -  22.9M 2021-08-26 22:54
n248139-3a57f08b504-b  -  -  1.21G 2021-08-26 22:54
n248478-f3a3b061216-a  -  -  51.0M 2021-08-26 22:54
14.0-CURRENT_2021-08-08_145838 -  -  365M  2021-08-26 22:54
n248269-941650aae97-b  -  -  524M  2021-08-26 22:54
n248269-941650aae97-f  -  -  29.3M 2021-08-26 22:54
n248478-f3a3b061216-e  -  -  579M  2021-08-26 22:54
n248478-f3a3b061216-b  -  -  56.7M 2021-08-26 22:55
n247798-f39dd6a9784-e  -  -  328M  2021-08-26 22:55
n248269-941650aae97-d  -  -  260M  2021-08-26 22:55
n248685-c9f833abf1d-e  -  -  216M  2021-08-26 22:55
n247798-f39dd6a9784-j  -  -  4.98G 2021-08-26 22:55
n248478-f3a3b061216-d  -  -  310M  2021-08-26 22:55
n248478-f3a3b061216-c  -  -  101M  2021-08-26 22:55
root@mowa219-gjp4-8570p-freebsd:~ # bectl list | sort
14.0-CURRENT_2021-08-08_145838 -  -  365M  2021-08-26 22:54
14.0-CURRENT_2021-08-19_045942 -  -  1.09G 2021-08-26 22:41
BE Active Mountpoint Space Created
default-  -  789M  2021-08-26 16:33
n247565-b49ba74deeb-f  -  -  39.6G 2021-08-26 19:50
n247798-f39dd6a9784-a  -  -  22.9M 2021-08-26 22:54
n247798-f39dd6a9784-e  -  -  328M  2021-08-26 22:55
n247798-f39dd6a9784-j  -  -  4.98G 2021-08-26 22:55
n248139-3a57f08b504-b  -  -  1.21G 2021-08-26 22:54
n248269-941650aae97-b  -  -  524M  2021-08-26 22:54
n248269-941650aae97-d  -  -  260M  2021-08-26 22:55
n248269-941650aae97-e  -  -  40.5M 2021-08-26 22:54
n248269-941650aae97-f  -  -  29.3M 2021-08-26 22:54
n248478-f3a3b061216-a  -  -  51.0M 2021-08-26 22:54
n248478-f3a3b061216-b  -  -  56.7M 2021-08-26 22:55
n248478-f3a3b061216-c  -  -  101M  2021-08-26 22:55
n248478-f3a3b061216-d  -  -  310M  2021-08-26 22:55
n248478-f3a3b061216-e  -  -  579M  2021-08-26 22:54
n248685-c9f833abf1d-e  -  -  216M  2021-08-26 22:55
n248685-c9f833abf1d-f  NR /  49.3G 2021-08-26 21:13
root@mowa219-gjp4-8570p-freebsd:~ # uname -KU
1400030 1400030
root@mowa219-gjp4-8570p-freebsd:~ # uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #105 
main-n248685-c9f833abf1d: Fri Aug 13 20:24:43 BST 2021 
root@mowa219-gjp4-zbook-freebsd:/usr

Re: lost high resolution console with lastest snapshot

[Ronald Klop]

Maybe your previous install did not use UEFI?

Ronald.


Van: Toomas Soome via freebsd-current 
Datum: dinsdag, 6 juli 2021 14:12
Aan: Nuno Teixeira 
CC: FreeBSD CURRENT 
Onderwerp: Re: lost high resolution console with lastest snapshot




> On 6. Jul 2021, at 14:49, Nuno Teixeira  wrote:
>
> Hello,
>
> gop get says:
> ---
> EDID 1920x1080
> mode 0
> ---
>
> When I try other modes it sometimes decreases res.
>
> I remember that high res was working until now.
> Maybe a bug?

GOP set/get/list is the only interface with uefi graphics we can use from 
bootloader. From loader, we only can try to use resolutions listed by gop list, 
even if the hardware does support better. This is the firmware limit (check for 
update?). Once operating system is running, X11/DRM drivers can switch to use 
better resolution.

Toomas

>
> Toomas Soome  escreveu no dia terça, 6/07/2021 à(s) 12:11:
>
>>
>>
 On 6. Jul 2021, at 14:07, Nuno Teixeira  wrote:
>>>
>>> I forgot to say that dmesg show vt resolution:
>>>
>>> ---
>>> (...)
>>> FreeBSD clang version 12.0.1 (g...@github.com:llvm/llvm-project.git
>>> llvmorg-12.0.1-rc2-0-ge7dac564cd0e)
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> ==> VT(efifb): resolution 1920x1080
>>> (...)
>>>
>>> But res isn't at 1920x1080
>>
>> from boot menu, press ESC to get OK prompt, enter commands:
>>
>> gop get
>> gop list
>> gop set X — where X is number from gop list output.
>>
>> this way you can check if the resolution does change or not.
>>
>> rgds,
>> toomas
>>
>>>
>>> Nuno Teixeira  escreveu no dia terça, 6/07/2021
>> à(s)
>>> 11:37:
>>>
 Hello,

 I remember having high resolution console at 1920x1080 but due to
>> hardware
 problems I replaced hdd and installed latest snapshot #0
 main-n247671-c5f4772c66d: Thu Jul  1 and now console resolution is very
>> low.

 Did I missed something or I need to configure system so I can have high
 res again?

 Thanks,
 Nuno Teixeira

>>
>>
 

Re: 15s wait for prompt for sudo su - on -current

[Ronald Klop]

What do you have configured as prompt? 
Or shell startup script?
Does it contain a call to git? 



Regards,
Ronald 



Van: tech-lists 
Datum: 13 juni 2021 19:20
Aan: freebsd-current@freebsd.org
Onderwerp: Re: 15s wait for prompt for sudo su - on -current





On Sun, Jun 13, 2021 at 12:48:11PM -0400, Allan Jude wrote:
>
>During the 15 seconds of waiting, press control+t a bunch of times, what
>is the waitchan?

% sudo su -
load: 0.11  cmd: git 79703 [running] 0.81r 0.67u 0.12s 8% 141608k
load: 0.11  cmd: git 79703 [running] 1.42r 1.28u 0.14s 13% 161384k
load: 0.18  cmd: git 79703 [running] 2.06r 1.91u 0.14s 18% 177460k
load: 0.18  cmd: git 79703 [running] 2.69r 2.52u 0.16s 24% 197724k
load: 0.18  cmd: git 79703 [running] 3.92r 3.74u 0.18s 34% 225796k
load: 0.18  cmd: git 79703 [running] 4.55r 4.32u 0.22s 37% 255252k
load: 0.18  cmd: git 79703 [running] 5.23r 4.99u 0.23s 40% 270948k
load: 0.18  cmd: git 79703 [running] 5.79r 5.53u 0.25s 46% 283704k
load: 0.18  cmd: git 79703 [running] 6.37r 6.09u 0.26s 47% 296864k
load: 0.18  cmd: git 79703 [running] 6.98r 6.69u 0.28s 48% 310828k
load: 0.18  cmd: git 79703 [running] 7.54r 7.23u 0.30s 53% 323440k
load: 0.32  cmd: git 79703 [running] 8.13r 7.81u 0.31s 54% 336756k
load: 0.32  cmd: git 79703 [running] 8.66r 8.34u 0.31s 59% 355228k
load: 0.32  cmd: git 79705 [running] 0.05r 0.04u 0.00s 0% 32984k
load: 0.32  cmd: git 79705 [running] 0.65r 0.57u 0.07s 5% 116316k
load: 0.32  cmd: git 79705 [running] 1.23r 1.13u 0.09s 11% 138692k
load: 0.32  cmd: git 79705 [running] 1.85r 1.73u 0.11s 16% 161508k
load: 0.32  cmd: git 79705 [running] 2.43r 2.28u 0.14s 22% 186196k
load: 0.32  cmd: git 79705 [running] 3.06r 2.90u 0.14s 26% 199808k
load: 0.32  cmd: git 79705 [running] 3.71r 3.52u 0.18s 30% 217844k

how weird is that??!

git isn't running:

# ps ax | grep git
79708  1  S+   0:00.00 grep git

--
J.

13.1 from main?

[Ronald Klop]

Hi,

Just wondering a bit. Why wouldn't the FreeBSD project release 13.1 from the 
main branch in about six months or some other time period? While making some 
monthly errata releases in the meantime.
- This saves a lot of back porting of commits.
- It prevents branches with old code like the current 11-branch with an old 
openssl version. Release early.
- Saves some people time in maintaining the branches.
- Saves time in coordinating the releases. Release often.
- Reduces the number of needed RC's. Because the main branch doesn't divert a 
lot of what people are running in production.
- Most people start testing/production use after the release. So this should be 
used as input for the main branch to improve the next release. Currently the 
feedback of 13.0 is put in 14.0 which is 2 years in the future.

Just some thoughts. Which I really like. :-)

Regards,
Ronald.
___
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: Blacklisted certificates

[Ronald Klop]

On 3/31/21 4:19 PM, Jochen Neumeister wrote:


Am 31.03.21 um 14:24 schrieb Ronald Klop:


Van: Jochen Neumeister 
Datum: woensdag, 31 maart 2021 13:26
Aan: Christoph Moench-Tegeder , 
freebsd-current@freebsd.org

Onderwerp: Re: Blacklisted certificates



Am 31.03.21 um 13:02 schrieb Christoph Moench-Tegeder:
> ## Jochen Neumeister (jon...@freebsd.org):
>
>> Why are this certificates blacklisted?
> Various reasons:
> - Symantec (which owned Thawte and VeriSign back in the time) made
>    the news in a bad way:
> 
https://www.theregister.com/2017/09/12/chrome_66_to_reject_symantec_certs/ 


> - some certificates are simply expired
> - some certificates use SHA-1 ("sha1WithRSAEncryption") which is
>    beyond deprecated
> - and basically "whatever Mozilla did", as the certificates are
>    imported from NSS.

how can I ignore the certificates now? So now everyone has this 
problem with an update



Greetings
Jochen

___
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"






Hi,

This is the proper output of installworld. So you don't have to ignore 
anything anymore. It is handled by installworld.




in the next step etcupdate has another problem. I have to delete the 
blacklist certificates manually.


#cd /usr/src && etcupdate
Conflicts remain from previous update, aborting.


Greetings
Jochen






I'd guess you need to run "etcupdate resolve". What is the output of 
"etcupdate status"?


Regards,
Ronald.

___
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: Blacklisted certificates

[Ronald Klop]

Van: Jochen Neumeister 
Datum: woensdag, 31 maart 2021 13:26
Aan: Christoph Moench-Tegeder , freebsd-current@freebsd.org
Onderwerp: Re: Blacklisted certificates



Am 31.03.21 um 13:02 schrieb Christoph Moench-Tegeder:
> ## Jochen Neumeister (jon...@freebsd.org):
>
>> Why are this certificates blacklisted?
> Various reasons:
> - Symantec (which owned Thawte and VeriSign back in the time) made
>the news in a bad way:
>https://www.theregister.com/2017/09/12/chrome_66_to_reject_symantec_certs/
> - some certificates are simply expired
> - some certificates use SHA-1 ("sha1WithRSAEncryption") which is
>beyond deprecated
> - and basically "whatever Mozilla did", as the certificates are
>imported from NSS.

how can I ignore the certificates now? So now everyone has this problem with an 
update


Greetings
Jochen

___
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"





Hi,

This is the proper output of installworld. So you don't have to ignore anything 
anymore. It is handled by installworld.

Ronald.

___
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: libifconfig_sfp.h does not compile for me

[Ronald Klop]

Van: Kurt Jaeger 
Datum: donderdag, 11 maart 2021 10:04
Aan: Ronald Klop 
CC: FreeBSD CURRENT 
Onderwerp: Re: libifconfig_sfp.h does not compile for me


Hi!

> This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h 
includes libifconfig_sfp_tables.h which does not exist.
>
> My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no 
succes.
> The last change in these files is a few days ago, am I the only one with this 
problem?
>
> This is on 14-CURRENT/amd64.

It looks like libifconfig_sfp_tables.h might be created during the
build via the template

https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp_tables.tpl.h

Maybe this fails to build ?

--
p...@opsec.eu+49 171 3101372Now what ?






Hi,

Thanks for the quick answers. I did some more manual cleaning, but the error 
keeps coming back. Although I see the generated file in the obj dir. Now nuked 
the whole /obj dir and doing a clean build.
So I will report back after llvm/clang is build again. Probably next week. :-)

Regards,
Ronald.

___
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"

libifconfig_sfp.h does not compile for me

[Ronald Klop]

Hi,

This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h 
includes libifconfig_sfp_tables.h which does not exist.

My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no 
succes.
The last change in these files is a few days ago, am I the only one with this 
problem?

This is on 14-CURRENT/amd64.

Regards,

Ronald.

___
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: RC1 builds

[Ronald Klop]

See https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093272.html

Regards,
Ronald.


Van: Mitidzi Racerex 
Datum: maandag, 8 maart 2021 11:33
Aan: freebsd-current@freebsd.org
Onderwerp: RC1 builds


Please give a link to RC1 builds.
___
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"




___
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: pkg vs uname troubles after upgrade to 14

[Ronald Klop]

libpkg/pkg_elf.c:const char *abi_files[] = {
libpkg/pkg_elf.c-getenv("ABI_FILE"),
libpkg/pkg_elf.c-_PATH_UNAME,
libpkg/pkg_elf.c-_PATH_BSHELL,
libpkg/pkg_elf.c-};

The detection first checks "/usr/bin/uname" if it exists and ABI_FILE is not 
set.
Yes the base is upgraded properly. It is a BE so if I installed wrongly I would 
not have any base.

But base is compiled by 13. So the ELF note NT_FREEBSD_ABI_TAG of the uname 
binary is 1300133.

I normally compile WITHOUT_CLEAN. What is the shortcut to recompile uname with 
the proper version nr and not having to recompiling clang? Cleaning and 
rebuilding only uname does not help.

Regards,
Ronald.


Van: Brandon Bergren 
Datum: dinsdag, 16 februari 2021 17:02
Aan: FreeBSD Current 
Onderwerp: Re: pkg vs uname troubles after upgrade to 14


IIRC, the detection works by probing /bin/sh, make sure you upgraded your base 
properly.

On Tue, Feb 16, 2021, at 9:55 AM, Ronald Klop wrote:
> Hi,
>
> Upgraded from 13 to 14.
>
> # uname -UK
> 143 143
>
> But elfdump on uname gives:
> note (.note.tag):
> FreeBSD 1300133 (NT_FREEBSD_ABI_TAG)
>
>
> # pkg -o OSVERSION=143 upgrade
> pkg: Warning: Major OS version upgrade detected.  Running "pkg
> bootstrap -f" recommended
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> Updating database digests format: 100%
> Checking for upgrades (1 candidates): 100%
> Processing candidates (1 candidates): 100%
> Checking integrity... done (0 conflicting)
> The following 1 package(s) will be affected (of 0 checked):
>
> Installed packages to be REINSTALLED:
> pkg-1.16.2 (ABI changed: 'freebsd:14:aarch64:64' -> 
'freebsd:13:aarch64:64')
>
> Number of packages to be reinstalled: 1
>
>
> How do I do this properly? Rebuilding name still gives it the ELF note
> of 1300133.
> It does not matter if I pass "-o OSVERSION=143" to pkg or not.
> Found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104, but I
> don't think it was really resolved.
>
> This is on aarch64. And why does pkg not use the version uname is
> reporting by -UK instead of the ELF note?
>
> Regards,
> Ronald.
>
>  
> ___

> 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"
>

--
  Brandon Bergren
  bdra...@freebsd.org
___
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"




___
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"

pkg vs uname troubles after upgrade to 14

[Ronald Klop]

Hi,

Upgraded from 13 to 14.

# uname -UK
143 143

But elfdump on uname gives:
note (.note.tag):
   FreeBSD 1300133 (NT_FREEBSD_ABI_TAG)


# pkg -o OSVERSION=143 upgrade
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" 
recommended
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
   pkg-1.16.2 (ABI changed: 'freebsd:14:aarch64:64' -> 'freebsd:13:aarch64:64')

Number of packages to be reinstalled: 1


How do I do this properly? Rebuilding name still gives it the ELF note of 
1300133.
It does not matter if I pass "-o OSVERSION=143" to pkg or not.
Found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104, but I don't 
think it was really resolved.

This is on aarch64. And why does pkg not use the version uname is reporting by 
-UK instead of the ELF note?

Regards,
Ronald.


___
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"

upgrade contrib/dma mail agent?

[Ronald Klop]

Hi,

In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244630 there is a patch to 
upgrade contrib/dma to a more recent version.
I'm also running with this patch locally for a while now.

Is somebody interested in committing this?

Regards,
Ronald.

___
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: Poudriere failed to build pkg in 13-stable jail under 12-stable

[Ronald Klop]

On Mon, 25 Jan 2021 05:46:43 +0100, Thomas Legg  wrote:


The build of a 13-stable source and kernel were a success under 12-stable
(though with some issues on freeze-ups and hard reboots that I suspect
might be related to the bufdaemon issue and my 0x15 gen AMD cpu).

Created a 13-stable poudriere jail with the knowledge that there may be
issues with builds under a 12-stable r369076 kernel. I didn't expect this
failure on packaging pkg.

> Compressing man pages (compress-man)
===>   Installing ldconfig configuration file
===
===>

===>  Building package for pkg-1.16.2
cp: /wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg/pkg-1.16.2.txz: Function  
not

implemented
*** Error code 1



cp in 13-stable uses the system call copy_file_range which is not in the  
12-stable kernel.
In general running newer code (13) on older kernel (12) is unsupported.  
Version 12 is not forwards compatible.


Regards,
Ronald.





Stop.
make[1]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

Stop.
make: stopped in /usr/ports/ports-mgmt/pkg
=>> Cleaning up wrkdir
===>  Cleaning for pkg-1.16.2
build of ports-mgmt/pkg | pkg-1.16.2 ended at Mon Jan 25 12:16:12 HKT  
2021

build time: 00:02:01
!!! build failure encountered !!!
___
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"

___
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: pkg for 14-current

[Ronald Klop]

Van: Masachika ISHIZUKA 
Datum: woensdag, 27 januari 2021 09:09
Aan: freebsd-current@freebsd.org
Onderwerp: Re: pkg for 14-current


>>> The first package build for 14-CURRENT is visible on the mirrors now
>>> (as of a couple of minutes ago).
>
> I've not updated the index.html pages on the mirrors yet.  (Actually,
> I did update them, but I forgot to commit the change - I'll go and do
> that now.)

  Thank you very much.
  I'm happy to be able to pkg upgrade on 14-current.
--
Masachika ISHIZUKA
___
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"





Is this about http://pkg.freebsd.org/ ?

May I hijack this thread to say that "FreeBSD:11:aarch64 (only quarterly is 
updated)" is not updated anymore.
I don't know about the future plans of this. I don't need FreeBSD:11:aarch64 
myself and am (unfortunately) not involved in the pkg build cluster.

Regards,
Ronald.

___
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: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

[Ronald Klop]

On Wed, 20 Jan 2021 21:21:15 +0100, Neel Chauhan  wrote:


Hi freebsd-current@,

I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while
back.

With 13.0-RELEASE around the corner, I'm thinking about upgrading my
home server, well if I can accelerate any SSL application.

I'm asking because I have a home server on a symmetrical Gigabit
connection (Google Fiber/Webpass), and that server runs a Tor relay. If
you're interested in how Tor works, the EFF has a writeup:
https://www.eff.org/pages/what-tor-relay

But the main point for you all is: more-or-less Tor relays deal with
1000s TLS connections going into and out of the server.

Would In-Kernel TLS help with an application like Tor (or even load
balancers/TLS termination), or is it more for things like web servers
sending static files via sendfile() (e.g. CDN used by Netflix).

My server could also work with Intel's QuickAssist (since it has an
Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here?

I'm asking since I don't know whether to upgrade my home server to 13.x
or leave it at 12.x. Yes, I do know we need a special OpenSSL to use
kTLS.

-Neel



According to the history of the openssl port it has support for KTLS.
https://www.freshports.org/security/openssl
I don't know about the openssl in base.

But I think for Tor to support KTLS it needs to implement some things  
itself. More information about that could be asked at the maintainer of  
the port (https://www.freshports.org/security/tor/) or upstream at the Tor  
project.


Regards,
Ronald.
___
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: Enabling AESNI by default

[Ronald Klop]

Yes! Took me until last month to notice that I needed to load aesni in 
loader.conf instead of rc.conf because swap geli is configured before kld_list.
Years of optimization thrown away.


Regards, 
Ronald.



Van: Allan Jude 
Datum: 31 december 2020 20:51
Aan: FreeBSD Current 
Onderwerp: Enabling AESNI by default




We've had the AESNI module for quite a few years now, and it has not
caused any problems.

I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
you need to load aesni.ko'

Userspace crypto that uses openssl or similar libraries is already
taking advantage of these CPU instructions if they are available, by
excluding this feature from GENERIC we are just causing the "out of the
box" experience to by very very slow for crypto.

For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
device:

with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz

fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
--numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
--group_reporting --fallocate=none --runtime=60 --time_based


stock:
write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)

with aesni.ko loaded:
write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)


Does anyone have a compelling reason to deny our users the 5x speedup?


--
Allan Jude
___
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"





___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Ronald Klop]

Van: bob prohaska 
Datum: 22 december 2020 19:38
Aan: freebsd-...@freebsd.org
CC: FreeBSD Current 
Onderwerp: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend



On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> 
> The FreeBSD project will be moving it's source repo from subversion to git

> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues.
> 

Is there some way to obtain git on a Pi2B running 
13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692
without installing the ports tree? I expected 
to find git in base, but it isn't there. 


Can it be found  under another package name?

Thanks for reading, and any guidance!

bob prohaska

___
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"





what does "pkg install git" do for you? 
NB: I use "pkg install git-lite". Prevents about 1000 dependencies.



Regards,
Ronald
___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

___
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: How to clear the 'remove:' line from 'zpool status'

[Ronald Klop]

On Sat, 05 Dec 2020 07:07:02 +0100, Dustin Marquess   
wrote:



So I stupidly did a 'zpool add' instead of a 'zpool attach'.  Luckily
I was able to 'zpool remove' the device thanks to the remove work done
a while back.

However, now I can't for the life of me get this part of the 'zpool
status' output to go away:

  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:01:06 with 0 errors on Fri Dec  4  
18:18:31 2020

remove: Removal of vdev 1 copied 104K in 0h0m, completed on Fri Dec  4
18:10:08 2020
72 memory used for removed device mappings
config:

I've tried 'zppol clear', 'zpool scrub', and rebooted.  Is there some
way to clear that 'remove' line? It's irritating my OCD :(.

Thanks!
-Dustin



Apply attached diff and rebuild world, Untested. Might have unwanted  
effects.


Regards,
Ronald.

zpool_main.c.diff
Description: Binary data
___
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: rc.d/zpool runs before ada(4) attaches

[Ronald Klop]

Van: Ian Lepore 
Datum: dinsdag, 1 december 2020 16:34
Aan: Ronald Klop , FreeBSD Current 

Onderwerp: Re: rc.d/zpool runs before ada(4) attaches


On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
>  
> Van: Harry Schmalzbauer 

> Datum: dinsdag, 1 december 2020 12:51
> Aan: Ronald Klop , FreeBSD Current <
> freebsd-current@freebsd.org>
> Onderwerp: Re: rc.d/zpool runs before ada(4) attaches
> >
> > Am 01.12.2020 um 10:33 schrieb Ronald Klop:
> > :
> > :
> > :
> > > > One machine fails importing zpool because the correponding
> > > > vdevs >> (ada0-ada2)
> > > > are not available at the time rc.d/zpool runs.
> > > >
> > > >
> > > > Adhoc  I'm not aware of any rc(8) vs. driver awareness.
> > > > Is there any?
> > > >
> > > > Suggestions how to fix else than 'sleep 1'?
> > > >
> > > > Thanks,
> > > >
> > > > -harry
> > > >
> > > > P.S.: ahci(4) is compiled into kernel, machine is a HPE U48
> > > > (Gen 10 >> plus MicroServer), zfsloader loads root_MFS kernel
> > > > module
> > > >
> > >
> > >
> > > There have been some changes to etc/rc.d/zpool in September.
> > > Do you have the latest version? Compare with:
> > >
https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> > > or
> > >
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup
> > >  >
> > >
> > > Otherwise it would be helpful for readers if you could post some
> > > logs > which indicate what is happening.
> > > /var/run/dmesg.boot or the output of "dmesg"
> > > Part of /var/log/messages
> > > Part of /var/log/console.log if it exists.
> > >
> >
> > Thanks, I'm on -current from view days ago.
> > The problem is that cam(4) is still probing devices, when
> > rc.d/zpool runs, since mount_root_from succeeded, because it is a
> > RAM disk, so succeeds independent of any real drive/controller
> > probing.
> > I can imagine of other seldom edgecases hitting the issue too.
> >
> > So my proposed patch, working for me, looks like this:
> > Index: libexec/rc/rc.d/zpool
> > ===
> > --- libexec/rc/rc.d/zpool   (revision 368202)
> > +++ libexec/rc/rc.d/zpool   (working copy)
> > @@ -18,8 +18,16 @@
> >
> >   zpool_start()
> >   {
> > -   local cachefile
> > +local cachefile n=0 camlist=`camcontrol devlist -v`
> >
> > +   # Wait for cam(4) devices attaching, 4 times at max by
> > increasing
> > +   # 1s each (10s max in total)
> > +while [ X"${camlist#*target*lun*probe}" != X"${camlist}"
> > ]; do
> > +   [ $n -lt 4 ] || break
> > +   sleep $((n+=1))
> > +   camlist=`camcontrol devlist -v`
> > +   done
> > +
> >  for cachefile in /etc/zfs/zpool.cache
> > /boot/zfs/zpool.cache; do
> >  if [ -r $cachefile ]; then
> >  zpool import -c $cachefile -a -N && break
> >
> > best,
> > -harry
> >
> >
> >
>
> You can define these in /boot/loader.conf:
> #kern.cam.boot_delay="1" # Delay (in ms) of root mount for CAM
> bus
> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
>
> Maybe that helps.
>
> Ronald.
>

Those settings control waiting before mounting root.  Harry's problem
is that root is mounted quickly, before other drives are ready for zfs.
 
The zpool script waits for 'disks'.  It would be nice if the cam

subsystem had something like a sysctl it set to indicate when initial
probing for disks was done, then there could be an rc.d/camprobe script
with 'PROVIDE: disks' which waits for the probing to complete.

-- Ian

 






Or a devd event "ada-arrived" which calls rc.d/zpool.
It sounds a bit like we need systemd. :-)

Ronald.

___
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: rc.d/zpool runs before ada(4) attaches

[Ronald Klop]

Van: Harry Schmalzbauer 
Datum: dinsdag, 1 december 2020 12:51
Aan: Ronald Klop , FreeBSD Current 

Onderwerp: Re: rc.d/zpool runs before ada(4) attaches


Am 01.12.2020 um 10:33 schrieb Ronald Klop:
:
:
:
>> One machine fails importing zpool because the correponding vdevs >> 
(ada0-ada2)
>> are not available at the time rc.d/zpool runs.
>>
>>
>> Adhoc  I'm not aware of any rc(8) vs. driver awareness.
>> Is there any?
>>
>> Suggestions how to fix else than 'sleep 1'?
>>
>> Thanks,
>>
>> -harry
>>
>> P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 (Gen 10 >> plus 
MicroServer), zfsloader loads root_MFS kernel module
>>
>
>
> There have been some changes to etc/rc.d/zpool in September.
> Do you have the latest version? Compare with:
> https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> or
> 
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup
 >
>
> Otherwise it would be helpful for readers if you could post some logs > which 
indicate what is happening.
> /var/run/dmesg.boot or the output of "dmesg"
> Part of /var/log/messages
> Part of /var/log/console.log if it exists.
>

Thanks, I'm on -current from view days ago.
The problem is that cam(4) is still probing devices, when rc.d/zpool runs, 
since mount_root_from succeeded, because it is a RAM disk, so succeeds 
independent of any real drive/controller probing.
I can imagine of other seldom edgecases hitting the issue too.

So my proposed patch, working for me, looks like this:
Index: libexec/rc/rc.d/zpool
===
--- libexec/rc/rc.d/zpool   (revision 368202)
+++ libexec/rc/rc.d/zpool   (working copy)
@@ -18,8 +18,16 @@

  zpool_start()
  {
-   local cachefile
+local cachefile n=0 camlist=`camcontrol devlist -v`

+   # Wait for cam(4) devices attaching, 4 times at max by increasing
+   # 1s each (10s max in total)
+while [ X"${camlist#*target*lun*probe}" != X"${camlist}" ]; do
+   [ $n -lt 4 ] || break
+   sleep $((n+=1))
+   camlist=`camcontrol devlist -v`
+   done
+
 for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
 if [ -r $cachefile ]; then
 zpool import -c $cachefile -a -N && break

best,
-harry





You can define these in /boot/loader.conf:
#kern.cam.boot_delay="1" # Delay (in ms) of root mount for CAM bus
#kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI

Maybe that helps.

Ronald.

___
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: rc.d/zpool runs before ada(4) attaches

[Ronald Klop]

Van: Harry Schmalzbauer 
Datum: dinsdag, 1 december 2020 09:43
Aan: freebsd-current@freebsd.org
Onderwerp: rc.d/zpool runs before ada(4) attaches


Hello,  I'm playing with HEAD (post r364746, Merge OpenZFS support in to HEAD) 
on some of my non-out-of-box setups.


One machine fails importing zpool because the correponding vdevs (ada0-ada2)
are not available at the time rc.d/zpool runs.


Adhoc  I'm not aware of any rc(8) vs. driver awareness.
Is there any?

Suggestions how to fix else than 'sleep 1'?

Thanks,

-harry

P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 (Gen 10 plus 
MicroServer), zfsloader loads root_MFS kernel module
 



There have been some changes to etc/rc.d/zpool in September.
Do you have the latest version? Compare with:
https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
or
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup

Otherwise it would be helpful for readers if you could post some logs which 
indicate what is happening.
/var/run/dmesg.boot or the output of "dmesg"
Part of /var/log/messages
Part of /var/log/console.log if it exists.

Regards,
Ronald.

___
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: possible usb3-connected hard drive spin down causing lag

[Ronald Klop]

Van: tech-lists 
Datum: vrijdag, 27 november 2020 04:24
Aan: freebsd-current@freebsd.org
Onderwerp: Re: possible usb3-connected hard drive spin down causing lag


Hi,

It seems the issue wasn't with the hardware or the connection.
I use mutt and it's the program that was slowing everything down,
and that was down to me using new mutt with my old config. The whole
pause for 5 seconds thing was due to it scanning gigabytes of email each time 
it woke up. The fix was to review the config and change a couple of settings. 
Now there's no delay (well there is a bit but only because it's scanning the 
folders it's told to for new mail).

But looking at a hardware cause wasn't in vain. On the way to the solution, 
found a few tips through here that sped up the system generally, and learned a 
bit. So now I have a *really quick* raspberry pi4 which is rock-solid stable, 
so thanks :D

--
J.
 



Mind to share these tips, so I can use them on my RPI4? ;-)
___
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: remove df(1) support for mounting filesystems

[Ronald Klop]

haha, this is the weirdest functionality I have seen in times. So long for the 
'programs that do one thing and do it well' philosophy. :-)

axe it!

cheers,
Ronald.

PS: sorry for the twitter-style reply.

Van: Mark Johnston 
Datum: donderdag, 12 november 2020 19:51
Aan: freebsd-current@freebsd.org
Onderwerp: remove df(1) support for mounting filesystems


Hi,

df(1) has the ability to mount character devices in order to collect
usage information.  This functionality has been deprecated for the past
couple of years, since r329092, and is buggy per PR 237368.  I propose
removing it in 13.0: https://reviews.freebsd.org/D27197
___
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"




___
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: compiling with ports llvm11 breaks on mman.h: struct shm_larg epage_conf

[Ronald Klop]

On Sat, 12 Sep 2020 18:28:03 +0200, Dimitry Andric  wrote:


On 12 Sep 2020, at 17:43, Ronald Klop  wrote:


Because I'm tired of hours of compilation of llvm/clang I'm testing  
compiling FreeBSD with llvm11 from a pkg.


Setup a jail with 13-CURRENT. Compilation of the installed version went  
fine.

Today I svn up'd and compiled and compilation broke.

/lib/clang/11.0.0/include -fstack-protector-strong -Wsystem-headers  
-Werror -Wall -[29/1822]
t-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body  
-Wno-string-plus-int -Wno-unused-const-variable  
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality  
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Wno-address-of-packed-member -
Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter   
-Qunused-arguments-I/usr/src/li
b/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86  
-I/usr/src/lib/msun/src -c /usr/

src/lib/libc/sys/shm_open.c -o shm_open.o
/usr/src/lib/libc/sys/shm_open.c:64:28: error: variable has incomplete  
type 'struct shm_larg

epage_conf'
   struct shm_largepage_conf slc;
 ^
/usr/src/lib/libc/sys/shm_open.c:64:9: note: forward declaration of  
'struct shm_largepage_co

nf'
   struct shm_largepage_conf slc;


I can see the difference between /usr/include/sys/mman.h and  
/usr/src/sys/sys/mman.h is exactly about these symbols.

Why is the base compiler using the latter and ports llvm11 the former?

Configuration of my src.conf and make.conf is described in  
https://blog.klop.ws/2020/08/waiting-for-clang-forever-and-ever.html .



Do I miss some directive about system header files?


During what stage is this, and is it an incremental (e.g. -DNO_CLEAN)
build? With this kind of failure, it is usually required to be able to
inspect the full buildworld log, and the exact command line you used to
invoke make. If you can, upload that somewhere so it can be viewed.



It is during the building world stage and happens with and without  
NO_CLEAN.

Full command:
/usr/local/bin/clang11  -O2 -pipe -fno-common   -DNO__SCCSID -DNO__RCSID  
-I/usr/src/lib/libc
/include -I/usr/src/include -I/usr/src/lib/libc/amd64 -DNLS   
-D__DBINTERFACE_PRIVATE -I/usr/
src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6  
-I/usr/obj/usr/src/amd64.amd64/lib/lib
c -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE  
-I/usr/src/lib/libmd -I/usr/src/
contrib/jemalloc/include -DMALLOC_PRODUCTION  
-I/usr/src/contrib/tzcode/stdtime -I/usr/src/li
b/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP  
-DDES_BUILTIN -I/usr/src/li
b/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -g -MD   
-MF.depend.shm_open.o
 -MTshm_open.o -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter  
/usr/local/llvm11
/lib/clang/11.0.0/include -fstack-protector-strong -Wsystem-headers  
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign  
-Wno-empty-body -Wno-string-plus-int -Wno-unused-
const-variable -Wno-tautological-compare -Wno-unused-value  
-Wno-parentheses-equality -Wno-un
used-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Wno-address-of-packed-member -
Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter   
-Qunused-arguments-I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64  
-I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c /usr/

src/lib/libc/sys/shm_open.c -o shm_open.o




That said, it looks like something is messing up your include order,
as during a very early stage in buildword, the sys/sys/ headers are
symlinked to objdir/tmp/legacy/usr/include/sys/. This should include
the mman.h header.

-Dimitry





I just added CROSS_TOOLCHAIN=llvm11 to make.conf and src.conf, but no  
difference. I think I need something with --sysroot, but am not sure if  
this is something I should set or which the build framework should set.


Any advice on this? Or a pointer to the right documentation?


Regards,

Ronald.
___
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"

compiling with ports llvm11 breaks on mman.h: struct shm_larg epage_conf

[Ronald Klop]

Hi,

Because I'm tired of hours of compilation of llvm/clang I'm testing  
compiling FreeBSD with llvm11 from a pkg.


Setup a jail with 13-CURRENT. Compilation of the installed version went  
fine.

Today I svn up'd and compiled and compilation broke.

/lib/clang/11.0.0/include -fstack-protector-strong -Wsystem-headers  
-Werror -Wall -[29/1822]
t-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body  
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare  
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function  
-Wno-enum-conversion -Wno-unused-local-typedef  
-Wno-address-of-packed-member -
Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter   
-Qunused-arguments-I/usr/src/li
b/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86  
-I/usr/src/lib/msun/src -c /usr/

src/lib/libc/sys/shm_open.c -o shm_open.o
/usr/src/lib/libc/sys/shm_open.c:64:28: error: variable has incomplete  
type 'struct shm_larg

epage_conf'
struct shm_largepage_conf slc;
  ^
/usr/src/lib/libc/sys/shm_open.c:64:9: note: forward declaration of  
'struct shm_largepage_co

nf'
struct shm_largepage_conf slc;


I can see the difference between /usr/include/sys/mman.h and  
/usr/src/sys/sys/mman.h is exactly about these symbols.

Why is the base compiler using the latter and ports llvm11 the former?

Configuration of my src.conf and make.conf is described in  
https://blog.klop.ws/2020/08/waiting-for-clang-forever-and-ever.html .



Do I miss some directive about system header files?

Regards,

Ronald.
___
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: should rpctlssd be called rpc.tlssd?

[Ronald Klop]

Van: Rick Macklem 
Datum: dinsdag, 1 september 2020 04:37
Aan: "freebsd-current@FreeBSD.org" 
Onderwerp: should rpctlssd be called rpc.tlssd?


This sounds trivial, but I thought I'd ask, in case anyone
has a preference?

The NFS over TLS code includes two daemons, one for
the client and one for the server.
I have called them rpctlscd and rpctlssd.

There was/is a tradition in Sun RPC of putting a "." in
the names.
So, should I be calling these daemons:
rpc.tlscd and rpc.tlssd?


I don't have an opinion about the rpc* vs rpc.* tradition.
But what I do not understand is why the difference between 2 daemons is only 
reflected in 1 character of their names. The rest of the name is actually not 
really significant in keeping them apart.

Regards and happy hacking,
Ronald.

> 

Thanks, rick
___
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"


___
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: speedtest.net in multi connections mode causes the FreeBSD 13-CURRENT router to crash

[Ronald Klop]

On Fri, 28 Aug 2020 14:02:46 +0200, S.N. Trigub   
wrote:



Hi!

I run FreeBSD 13.0-CURRENT #0 r363772 as router in small office with two  
network interface: sk0 and sk1.
sk0 connected to 2 providers (main and backup) via VLAN and natd, sk1  
connected to office network via VLAN.

I had to use VLAN due to cabling issues.

As soon as the user runs the speedtest.net in browser on any client  
computer in network
FreeBSD router goes into panic mode and automatically reboot during  
multi connection upload test.

In single connections mode of speedtest.net all is fine.

Error is : Fatal trap 12: page fault while in kernel mode.



FreeBSD can also generate a crashdump.
This is configured by dumpdev in /etc/rc.conf (/etc/defaults/rc.conf). The  
default 'AUTO' is to dump to swap if it is not encrypted and the swap size  
is big enough. You can also specify a specific device to dump to.

This dump contains all the information for a dev needed to debug this.

https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

Regards,
Ronald




In my opinion the error is caused by multiple openings of outgoing  
connections on router in a short period of time.
This is not a hardware error. I tested it on three different  
motherboards with different kernel versions and diffenent amount of RAM  
(8GB DDR2 and 16, 24, 32GB DDR3).
Maybe this is somehow due to the use of VLAN, or network card driver  
problem...
I noticed this problem about six months ago when I switched from FreeBSD  
12-Current to FreeBSD 13-Current.
Since then I have been updating the kernel about once a week, but the  
error still present.


I read on the some artictes in Internet that this can happen when tcp  
extensions are enabled. I disabled tcp_extensons in rc.conf, and
set some sysctls params as described in Internet-articles, but it didn't  
affect anything.

The same error sometimes occurs when clients are talking on Skype.

Could you help me? Any idea is appreciated!

Thank you.
Sergei.

My network  
cards:


skc0:  port 0xc100-0xc1ff mem  
0xf7b44000-0xf7b47fff irq 16 at device 1.0 on pci6

skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9)
sk0:  on skc0
sk0: Ethernet address: 00:15:e9:b8:c3:53
miibus1:  on sk0
e1000phy0:  PHY 0 on miibus1
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,  
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto


skc1:  port 0xc000-0xc0ff mem  
0xf7b4-0xf7b43fff irq 17 at device 2.0 on pci6

skc1: DGE-530T Gigabit Ethernet Adapter rev. (0x9)
sk1:  on skc1
sk1: Ethernet address: 00:19:5b:8a:97:a7
miibus2:  on sk1
e1000phy1:  PHY 0 on miibus2
e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,  
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto



 My  
natd.conf:


instance default
interface vlan2
port 8668
use_sockets yes
same_ports yes
#
instance vlan3
interface vlan3
port 8669
use_sockets yes
same_ports yes
#
globalport 8670
#
#

= My  
rc.conf:=


defaultrouter="109.251.97.65"
tcp_extensions="NO"# Set to NO to turn off RFC1323 extensions.
#
ifconfig_sk0="up -rxcsum -txcsum"
ifconfig_sk1="up -rxcsum -txcsum"
ipv6_network_interfaces="none"  # Default is auto
ipv6_activate_all_interfaces="NO"   # this is the default
ip6addrctl_enable="NO"  # New way to disable IPv6 support
ip6addrctl_policy="ipv4_prefer" # Use IPv4 instead of IPv6
cloned_interfaces="vlan2 vlan3 vlan5"
#
# vlan2 – provider 1 as main
# vlan3 -- provider 2 as backup
# vlan5 – office network
#
ifconfig_vlan2="inet 109.251.97.75 netmask 255.255.255.224   vlan 2  
vlandev sk0"
ifconfig_vlan3="inet 95.164.8.37 netmask 255.255.252.0   vlan 3  
vlandev sk0"
ifconfig_vlan5="inet 10.10.10.177  netmask 255.255.255.240 vlan 5  
vlandev sk1"

#
gateway_enable="YES"
#
zfs_enable="YES"  # Set to YES to automatically mount ZFS file systems
natd_enable="YES"# enables NAT
natd_flags="-f /etc/natd.conf"


== My  
sysctl.conf:===


debug.debugger_on_panic=0
kern.coredump=0
kern.corefile=/dev/null
net.inet.ip.fw.one_pass=1
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.tcp.recvspace=1048576
net.inet.tcp.sendspace=524288
net.inet.tcp.recvbuf_max=4194304
net.inet.tcp.sendbuf_inc=65535
net.inet.tcp.msl=5000
net.inet.ip.fw.dyn_buckets=65536
net.inet.ip.fw.dyn_max=65536
net.inet.ip.fw.dyn_ack_lifetime=120
net.inet.ip.fw.dyn_syn_lifetime=10
net.inet.ip.fw.dyn_fin_lifetime=2
net.inet.ip.fw.dyn_short_lifetime=10


= My  
loader.conf:==


zfs_load="YES"
vfs.root.mount

(solved) Re: dma fails to connect (error:1408F10B:SSL routines:ssl3_get_record:wrong version number)

[Ronald Klop]

On Sun, 16 Aug 2020 16:44:51 +0200, Ronald Klop   
wrote:



Hi,

I have uname -UK -> 1300101 1300101 in my laptop. This uses libexec/dma  
as mail agent.
I have 2 jails running uname -U -> 1300101 and 1300104. All dma configs  
are the same.


In all 1300101 versions dma can deliver mail to my smarthost. On 1300104  
I get:


Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: trying remote  
delivery to smtp.greenhost.nl [213.108.110.112] pref 0
Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]:  
SSL_client_method
Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: remote  
delivery deferred: SSL handshake failed fatally: error:1408F10B:SSL  
routines:ssl3_get_record:wrong version number


Any thoughts on this?
bisecting this will take me hours and hours of compilation

Regards,
Ronald.



I found the cause of the error with ngrep. My jail has an underscore in  
the name and the SMTP EHLO command complained about it. But the error  
handling in dma does not handle this error properly if STARTTLS is  
enabled, so communication with the server goes wrong which results in  
STARTTLS getting weird results later on.


I proposed a fix upstream and will rename my jail to not contain an  
underscore in the hostname.

https://github.com/corecode/dma/pull/87

Computers and all the time consuming little bugs. Arrgh.

Ronald.
___
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"

dma fails to connect (error:1408F10B:SSL routines:ssl3_get_record:wrong version number)

[Ronald Klop]

Hi,

I have uname -UK -> 1300101 1300101 in my laptop. This uses libexec/dma as  
mail agent.
I have 2 jails running uname -U -> 1300101 and 1300104. All dma configs  
are the same.


In all 1300101 versions dma can deliver mail to my smarthost. On 1300104 I  
get:


Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: trying remote  
delivery to smtp.greenhost.nl [213.108.110.112] pref 0
Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]:  
SSL_client_method
Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: remote delivery  
deferred: SSL handshake failed fatally: error:1408F10B:SSL  
routines:ssl3_get_record:wrong version number


Any thoughts on this?
bisecting this will take me hours and hours of compilation

Regards,
Ronald.
___
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: vnet/jail crashdump

[Ronald Klop]

On Mon, 03 Aug 2020 20:27:07 +0200, Ernie Luzar  wrote:


Ronald Klop wrote:

Hi,
 After stopping a jail I get a crashdump.
core.txt:  
https://www.klop.ws/core_2eef39c581f90f2f0c4921e43f1998c1/core.txt.0

 Jail.conf:
--
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
 exec.prestart = "ifconfig bridge0 > /dev/null 2> /dev/null || (  
ifconfig bridge0 create && ifconfig bridge0 addm vtnet0 && ifconfig  
bridge0 up)";

 exec.consolelog = "/var/log/jail_${name}_console.log";
 mount.devfs;
path = "/data/jails/$name";
host.hostname = "$name";
mount.fstab = "/data/jails/fstab.$name";
vnet;
allow.mlock;
devfs_ruleset="110";
 freebsd12 {
osrelease = 12.1-RELEASE-p4;
osreldate = 1201000;
vnet.interface = "epair0b";
# make sure the exec.prestart has a "+=" as we de it in the global  
definition

# when checking for the bridge
exec.prestart += "ifconfig epair0 create up";
exec.prestart += "ifconfig bridge0 addm epair0a";
exec.prestart += "ifconfig epair0b link 02:xx:0c";
exec.start = "dhclient epair0b";
exec.start += "/bin/sh /etc/rc";
exec.poststop  = "ifconfig bridge0 deletem epair0a";
exec.poststop += "ifconfig epair0a destroy";
 }
freebsd13 {
vnet.interface = "epair1b";
# make sure the exec.prestart has a "+=" as we de it in the global  
definition

# when checking for the bridge
exec.prestart += "ifconfig epair1 create up";
exec.prestart += "ifconfig bridge0 addm epair1a";
exec.prestart += "ifconfig epair1b link 02:xx:0d";
exec.start = "dhclient epair1b";
exec.start += "/bin/sh /etc/rc";
exec.poststop  = "ifconfig bridge0 deletem epair1a";
exec.poststop += "ifconfig epair1a destroy";
}
--
 What can I do to help debug?




Don't understand why you have these 2 statements

  exec.prestart += "ifconfig epair1b link 02:xx:0d";
  exec.start = "dhclient epair1b";



Using dhcp on a fixed MAC is much faster in my network. This might be  
written in a better way. Please enlighten me. After a lot of twiddling  
with settings this worked.



There is a well known bug with bridge vnet tear down since release 9.0.  
Their is a rewrite of if_bridge going on right now to fix the problem  
and increase the performance of if_bridge. As of today this fix is not  
in 12.2 stable or 13.0 current.



Ah ok, so it is a known issue.


There also looks like a bug in jail(8) when you have both vnet jails and  
non-vnet jails being started on the same host at the same time. In most  
cases the host just loses internet access until all the jails are  
stopped. Some times you will get a system crash.



Ok. Not my use case, but good to know.



This jail.conf def seems to work around the bridge tear down problem

#  vnet jail using the bridge/epair method on 12.1
v0jail1 {
host.hostname   = "v0jail1";
path= "/usr/jails/v0jail1";
mount.fstab = "/usr/local/etc/fstab/v0jail1";
exec.consolelog = "/var/log/v0jail1.console.log";
mount.devfs;
devfs_ruleset   = "4";
vnet= "new";
vnet.interface  = "epair55b";
exec.prestart   = "ifconfig epair55  create up";
exec.prestart  += "ifconfig bridge0 addm epair55a";
exec.prestart  += "ifconfig epair55a descr vnet-v0jail1";
exec.prestart  += "ifconfig bridge0 inet 10.0.48.2 netmask 255.255.255.0  
alias";

exec.start  = "/bin/sh /etc/rc";
exec.start += "ifconfig epair55b inet 10.0.48.1 netmask  
255.255.255.0";

exec.start += "route add default 10.0.48.2";
exec.prestop= "ifconfig epair55b -vnet v0jail1";
exec.stop   = "/bin/sh /etc/rc.shutdown";
exec.poststop   = "ifconfig bridge0 deletem epair55a";
exec.poststop  += "sleep 2";
exec.poststop  += "ifconfig epair55a destroy";
exec.poststop  += "ifconfig bridge0 inet 10.0.48.2 -alias";
}

Remember that your host firewall processes all traffic in & out of the  
host including any vnet jail traffic. Yes a vnet jail has its own stack  
and can have its own firewall, but the host firewall still has the last  
say. The host must NAT any private ip addresses used by the vnet jails.


jail.conf jail definitions are based on hard codded ip addresses. You  
can not use the host dhcp to assign local lan private ip addresses to a  
jail.


You may find this helpful

https://forums.freebsd.org/threads/vnet-jail-with-public-internet-access-using-the-bridge-epair-method.76071/



Thanks for all the info.

Ronald.
___
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"

vnet/jail crashdump

[Ronald Klop]

Hi,

After stopping a jail I get a crashdump.
core.txt:  
https://www.klop.ws/core_2eef39c581f90f2f0c4921e43f1998c1/core.txt.0


Jail.conf:
--
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;

exec.prestart = "ifconfig bridge0 > /dev/null 2> /dev/null || ( ifconfig  
bridge0 create && ifconfig bridge0 addm vtnet0 && ifconfig bridge0 up)";


exec.consolelog = "/var/log/jail_${name}_console.log";

mount.devfs;
path = "/data/jails/$name";
host.hostname = "$name";
mount.fstab = "/data/jails/fstab.$name";
vnet;
allow.mlock;
devfs_ruleset="110";

freebsd12 {
osrelease = 12.1-RELEASE-p4;
osreldate = 1201000;
vnet.interface = "epair0b";
	# make sure the exec.prestart has a "+=" as we de it in the global  
definition

# when checking for the bridge
exec.prestart += "ifconfig epair0 create up";
exec.prestart += "ifconfig bridge0 addm epair0a";
exec.prestart += "ifconfig epair0b link 02:xx:0c";
exec.start = "dhclient epair0b";
exec.start += "/bin/sh /etc/rc";
exec.poststop  = "ifconfig bridge0 deletem epair0a";
exec.poststop += "ifconfig epair0a destroy";

}
freebsd13 {
vnet.interface = "epair1b";
	# make sure the exec.prestart has a "+=" as we de it in the global  
definition

# when checking for the bridge
exec.prestart += "ifconfig epair1 create up";
exec.prestart += "ifconfig bridge0 addm epair1a";
exec.prestart += "ifconfig epair1b link 02:xx:0d";
exec.start = "dhclient epair1b";
exec.start += "/bin/sh /etc/rc";
exec.poststop  = "ifconfig bridge0 deletem epair1a";
exec.poststop += "ifconfig epair1a destroy";
}
--

What can I do to help debug?

Regards,
Ronald.
___
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: Recovering after a crash during installworld

[Ronald Klop]

Delete /usr/src and make a new svn checkout.


Regards,
Ronald.


Van: bob prohaska 
Datum: 4 juni 2020 21:24
Aan: freebsd-current@freebsd.org
CC: bob prohaska 
Onderwerp: Recovering after a crash during installworld




A Raspberry Pi3B running -current near r360134 crashed during installworld.
Installkernel completed in single-user mode, but it looks like something
got corrupted in files related to svnlite:

root@www:/usr/src # svnlite up .
svn: E235000: In file 
'/usr/src/contrib/subversion/subversion/libsvn_wc/wc_db_wcroot.c' line 311: 
assertion failed (format >= 1)
Abort (core dumped)
root@www:/usr/src # svnlite cleanup .
svn: E235000: In file 
'/usr/src/contrib/subversion/subversion/libsvn_wc/wc_db_wcroot.c' line 311: 
assertion failed (format >= 1)
Abort (core dumped)

The machine comes up multi-user without problems, but attempts to update
or simply rebuild the system run afoul of the svnlite errors.

Is there a practical way to recover?

Thanks for reading,

bob prohaska
 
___

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"





___
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"