Re: Alt+Fn isn't functional. Has this been removed?

[Michael Gmelin]

> On 30. Mar 2024, at 07:30, Chris  wrote:
> 
> On 2024-03-29 23:06, Michael Schuster wrote:
>> Two ideas:
>> - does CTL-ALT-Fn work?
> Thanks. But no, I tried that.
> 
>> - perhaps the number of predefined ttys was overwritten/set to 0 somewhere?
> I'm only aware of /etc/ttys, and they're all available (uncommented) and
> ps(1) indicates getty(8) is running on all the normally assigned ttyv(n)'s.
> 
> Thanks for the reply!
> 
> --Chris

In case you have a keymap defined on rc.conf, try commenting that out, reboot 
amd see if it makes a difference (as a debugging measure). 

Cheers
Michael


>> HTH
>> Michael
>>> On Sat, Mar 30, 2024, 03:03 Chris  wrote:
>>> I just poured the dist files onto an earlier 15 (after removing
>>> the earlier version). After booting into the new install, I no longer
>>> had any other tty's other than ttyv0. Alt+Fn has no affect, I'm only
>>> getting ttyv0. getty(8) is running, and a ps waux | grep getty shows
>>> they're all up. Only things I saved from the older install were the
>>> user/group databases, rc.conf,pf.conf,jail.conf, and wpa_supplicant.conf.
>>> What do I need to do to further isolate this problem?
>>> Thanks.
>>> System info:
>>> FreeBSD fbsd15 15.0-CURRENT FreeBSD 15.0-CURRENT #0
>>> main-n268793-220ee18f1964:
>>> Thu Mar 14 02:58:39 UTC 2024
>>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>>> amd64
>>> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU)
>>> IdeaPad 3 17IAU7
>>> Id Refs AddressSize Name
>>>  1   95 0x8020  1d527c0 kernel
>>>  21 0x81f54000287e8 fusefs.ko
>>>  31 0x82d8f000   1e3228 i915kms.ko
>>>  42 0x82f7300085090 drm.ko
>>>  51 0x82ff9000 22b8 iic.ko
>>>  62 0x82ffc000 40e9 linuxkpi_video.ko
>>>  73 0x83001000 7358 dmabuf.ko
>>>  83 0x83009000 3378 lindebugfs.ko
>>>  91 0x8300d000 c338 ttm.ko
>>> 101 0x8301a000 5760 cuse.ko
>>> 111 0x8302 3390 acpi_wmi.ko
>>> 121 0x83024000 4250 ichsmb.ko
>>> 131 0x83029000 2178 smbus.ko
>>> 141 0x8302c00091260 if_iwlwifi.ko
>>> 151 0x830be000 5f90 ig4.ko
>>> 161 0x830c4000 4d20 ng_ubt.ko
>>> 173 0x830c9000 bbb8 netgraph.ko
>>> 182 0x830d5000 a250 ng_hci.ko
>>> 192 0x830e 2670 ng_bluetooth.ko
>>> 201 0x830e3000 3218 iichid.ko
>>> 215 0x830e7000 3380 hidbus.ko
>>> 221 0x830eb000 21e8 hms.ko
>>> 231 0x830ee000 40a8 hidmap.ko
>>> 241 0x830f3000 3355 hmt.ko
>>> 251 0x830f7000 22cc hconf.ko
>>> 261 0x830fa000 2260 pflog.ko
>>> 271 0x830fd00056540 pf.ko
>>> 281 0x83154000 3560 fdescfs.ko
> 

Re: Proposal: Disable compression of newsyslog by default

[Michael Gmelin]

> On 23. Dec 2023, at 16:10, Enji Cooper  wrote:
> 
> 
>> On Dec 22, 2023, at 23:18, Xin Li  wrote:
>> 
>> Hi,
>> 
>> Inspired by D42961, I propose that we move forward with disabling the 
>> compression by default in newsyslog, as implemented in 
>> https://reviews.freebsd.org/D43169
>> 
>> Historically, newsyslog has compressed rotated log files to save disk space. 
>> This approach was valuable in the early days where storage space was 
>> limited.  However, the landscape has changed significantly.  Modern file 
>> systems, such as ZFS, now offer native compression capabilities. 
>> Additionally, the widespread availability of larger hard drives has 
>> diminished the necessity for additional compression.  Notably, the need to 
>> decompress log files for pattern searches poses a significant inconvenience, 
>> further questioning the utility of this legacy feature.
>> 
>> In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is 
>> eligible for compression rather than directly enforcing it. It allows for a 
>> more flexible approach, wherein the actual compression method can be set to 
>> "none" or specified as one among bzip2, gzip, xz, or zstd.
>> 
>> Therefore I would propose that we change the default compression setting to 
>> "none" in FreeBSD 15.0.  This change reflects our adaptation to the evolving 
>> technological environment and user needs.  It also aligns with the broader 
>> initiative to modernize our systems while maintaining flexibility and 
>> efficiency.
>> 
>> I look forward to your thoughts and feedback on this proposal.
> 
> This impacts embedded systems or jails which use UFS as the default /var/log 
> backed device. There are quite a few larger consumers of FreeBSD out there 
> that still use UFS instead of ZFS.
> 
> Adding this instead into bsdinstall and the documentation as a suggested knob 
> seems like a good way to go.
> 
> Just something to keep in mind when making this change.

I would not change the default behavior (POLA violation), but adding an easy to 
change knob to disable compression sounds like a reasonable approach.

-m

Re: something magic about the size of a ports tree

[Michael Gmelin]

> On 3. Oct 2023, at 18:27, Matthias Apitz  wrote:
> 
> El día martes, octubre 03, 2023 a las 06:14:23p. m. +0200, Olivier Certner 
> escribió:
> 
>> Hi Matthias,
>> 
>> Some ZFS dataset with zstd compression on jet, and no compression on 
>> c720-1400094?
>> 
> 
> Yes, on jet it is ZFS:
> 
> root@jet:/usr/local/poudriere/ports # mount | grep ports2023
> poudriere/poudriere/ports/ports20230806 on 
> /usr/local/poudriere/ports/ports20230806 (zfs, local, noatime, nfsv4acls)
> 
> on c720-1400094 it is only plain UFS.
> 

Try

du -hA file

Also, to experience the difference, try:

dd if=/dev/zero of=tempfile bs=1m count=10

and compare the results of ls, du -h, du -hA on the different filesystems.

   zfs get all | grep compr

can also be quite enlightening.

Cheers


>matthias
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> 

Re: changes to ps -d?

[Michael Gmelin]

> 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

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

ctive
> > > in each case?
> > >  
> > >> What the host is not, is zfs-on-root. It boots from ssd (ada0).
> > >> The vdevs are on a sas disk array.
> > >>  
> > >>> So either your bootable partitions must not have  
> > com.klarasystems:vdev_zaps_v2  
> > >>> in your BEs or you must have a new user boot. I think you can
> > >>> just  
> > install  
> > >>> the one from 14, but haven't tried it.  
> > >>
> > >> Can you briefly explain how I'd install the one from 14 please?  
> > >
> > >
> > > I do not use bhyve so I do not even know if the
> > > context is using the efi loader from a msdosfs
> > > vs. not. For efi loaders, copying from one msdosfs
> > > with a sufficient vintage to the one with the wrong
> > > vintage (replacing) is sufficient.  
> >
> > bhyve in freebsd is traditionally using /boot/userboot.so, I
> > believe.  
> 
> 
> Yes. We use the *HOSTS* (running FreeBSD 13) /boot/userboot.so to
> boot the FreeBSD 14
> image. Since we're not using the boot loader from the target image to
> load it for bhyve,
> the loader we're using has to understand the ZFS dataset that it's
> booting off of. FreeBSD
> 13's userboot.so doesn't support all the bells and whistles that the
> ZFS folks have added
> to 14.
> 
> So, either you have to turn off those features (which I got no clue
> how to do in the
> normal installer), or you have to update userboot.so to the FreeBSD 14
> version (which
> I think had a good chance of actually running on FreeBSD 13 since it
> has no 'system'
> references, which are confined to bhyveload).
> 
> Warner
> 
> 
> > >
> > > # find /boot/efi/EFI/ -print
> > > /boot/efi/EFI/
> > > /boot/efi/EFI/FREEBSD
> > > /boot/efi/EFI/FREEBSD/loader.efi
> > > /boot/efi/EFI/BOOT
> > > /boot/efi/EFI/BOOT/bootaa64.efi
> > >
> > > There may well be only:
> > >
> > > EFI/BOOT/bootaa64.efi
> > >
> > > for all I know.
> > >
> > > From an amd64 context:
> > >
> > > # find /boot/efi/EFI/ -print
> > > /boot/efi/EFI/
> > > /boot/efi/EFI/FREEBSD
> > > /boot/efi/EFI/FREEBSD/loader.efi
> > > /boot/efi/EFI/BOOT
> > > /boot/efi/EFI/BOOT/bootx64.efi
> > >
> > > There may well be only:
> > >
> > > EFI/BOOT/bootx64.efi
> > >
> > > for all I know.
> > >
> > > (I set things up to have the EFI capitalization
> > > so that referencing efi/ vs. EFI/ in my context
> > > is unique for the mount point. vs. the msdosfs
> > > directory.)
> > >
> > > ===
> > > Mark Millard
> > > marklmi at yahoo.com
> > >
> > >  
> >
> >
> >  



-- 
Michael Gmelin

Re: 14.0-CURRENT boots fine but keyboard does not work

[Michael Gmelin]

> On 4. Sep 2023, at 19:34, Matthias Apitz  wrote:
> 
> El día lunes, septiembre 04, 2023 a las 07:29:41p. m. +0200, Michael Gmelin 
> escribió:
> 
>> 
>> 
>>>> On 4. Sep 2023, at 19:23, Matthias Apitz  wrote:
>>> 
>>> 
>>> Added Alexander Motin  to To: as the origin of the CI;
>>> 
>>> Neither hw.atkbd.hz=1 nor hw.atkbd.hz=10 makes the keyboard working on
>>> my beloved Acer C720. Should I file a new PR?
>>> 
>> 
>> Filing a PR makes sense, could you please Cc me on it?
>> 
>> Do you know which version of FreeBSD was the last that worked for you?
> 
> I'm actually using (and typing this on it) r368166. Will file a PR
> tomorrow. Thanks
> 

This could also be related:

https://cgit.freebsd.org/src/commit/?id=319d2bf407b3762da6f1c67ffe8dce2fee587aaf

You could try to undo that patch and build a new kernel.

Best
Michael



>matthias
> 
>>>> El día lunes, septiembre 04, 2023 a las 06:55:52p. m. +0200, Michael 
>>>> Gmelin escribió:
>>>> 
>>>> 
>>>> 
>>>> On Mon, 4 Sep 2023 18:43:11 +0200
>>>> Matthias Apitz  wrote:
>>>> 
>>>>> I have a 14.0-CURRENT compiled from sources of head from August 4,
>>>>> which boots fine from a produced USB key, but the keyboard does not
>>>>> work on an Acer C720 (amd64), on other laptops the keyboard is fine.
>>>>> 
>>>>> The keyboard works during the boot menu (for example to enable verbose
>>>>> boot messages) but not on the login: prompt of the booted system.
>>>>> 
>>>>> I've enabled SSH access into the C720 (if someone need more
>>>>> information) and I'm attaching /var/log/messages of the booted system.
>>>> 
>>>> Hi Matthias,
>>>> 
>>>> The C720 required special patches for the keyboard to work, which I
>>>> originally added here:
>>>> https://cgit.freebsd.org/src/commit/?id=6c176113bbdd598231ec47d161d4c3714997169b
>>>> 
>>>> I assume that something in that area changed recently.
>>>> 
>>>> Without digging into it, this looks like a possible cause:
>>>> 
>>>> https://cgit.freebsd.org/src/commit/sys/dev/atkbdc/atkbd.c?id=ce881170088c4c98c036fe561f8ee8413c2e2585
>>>> 
>>>> atkbd: Disable periodic polling by default.
>>>> It is one of the few remaining Giant-locked callouts.  It would be
>>>> good to remove it, not mentioning that polling itself is not good.
>>>> 
>>>> If this cause keyboard/mouse freezes on some hardware, please set
>>>> loader tunable hw.atkbd.hz=1 as workaround and report the issue.
>>>> 
>>>> So you could try to set hw.atkbd.hz=1 (or hw.atkbd.hz=10) in
>>>> /boot/loader.conf, then reboot and see if it helps.
>>>> 
>>>> Best
>>>> Michael
>>>> 
>>>> -- 
>>>> Michael Gmelin
>>>> 
>>> 
>>> -- 
>>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
>>> Public GnuPG key: http://www.unixarea.de/key.pub
>> 
>> 
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub

Re: 14.0-CURRENT boots fine but keyboard does not work

[Michael Gmelin]

> On 4. Sep 2023, at 19:23, Matthias Apitz  wrote:
> 
> 
> Added Alexander Motin  to To: as the origin of the CI;
> 
> Neither hw.atkbd.hz=1 nor hw.atkbd.hz=10 makes the keyboard working on
> my beloved Acer C720. Should I file a new PR?
> 

Filing a PR makes sense, could you please Cc me on it?

Do you know which version of FreeBSD was the last that worked for you?

Cheers


> 
> 
>> El día lunes, septiembre 04, 2023 a las 06:55:52p. m. +0200, Michael Gmelin 
>> escribió:
>> 
>> 
>> 
>> On Mon, 4 Sep 2023 18:43:11 +0200
>> Matthias Apitz  wrote:
>> 
>>> I have a 14.0-CURRENT compiled from sources of head from August 4,
>>> which boots fine from a produced USB key, but the keyboard does not
>>> work on an Acer C720 (amd64), on other laptops the keyboard is fine.
>>> 
>>> The keyboard works during the boot menu (for example to enable verbose
>>> boot messages) but not on the login: prompt of the booted system.
>>> 
>>> I've enabled SSH access into the C720 (if someone need more
>>> information) and I'm attaching /var/log/messages of the booted system.
>> 
>> Hi Matthias,
>> 
>> The C720 required special patches for the keyboard to work, which I
>> originally added here:
>> https://cgit.freebsd.org/src/commit/?id=6c176113bbdd598231ec47d161d4c3714997169b
>> 
>> I assume that something in that area changed recently.
>> 
>> Without digging into it, this looks like a possible cause:
>> 
>>  
>> https://cgit.freebsd.org/src/commit/sys/dev/atkbdc/atkbd.c?id=ce881170088c4c98c036fe561f8ee8413c2e2585
>> 
>>  atkbd: Disable periodic polling by default.
>>  It is one of the few remaining Giant-locked callouts.  It would be
>>  good to remove it, not mentioning that polling itself is not good.
>> 
>>  If this cause keyboard/mouse freezes on some hardware, please set
>>  loader tunable hw.atkbd.hz=1 as workaround and report the issue.
>> 
>> So you could try to set hw.atkbd.hz=1 (or hw.atkbd.hz=10) in
>> /boot/loader.conf, then reboot and see if it helps.
>> 
>> Best
>> Michael
>> 
>> -- 
>> Michael Gmelin
>> 
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub

Re: 14.0-CURRENT boots fine but keyboard does not work

[Michael Gmelin]

On Mon, 4 Sep 2023 18:43:11 +0200
Matthias Apitz  wrote:

> I have a 14.0-CURRENT compiled from sources of head from August 4,
> which boots fine from a produced USB key, but the keyboard does not
> work on an Acer C720 (amd64), on other laptops the keyboard is fine.
> 
> The keyboard works during the boot menu (for example to enable verbose
> boot messages) but not on the login: prompt of the booted system.
> 
> I've enabled SSH access into the C720 (if someone need more
> information) and I'm attaching /var/log/messages of the booted system.

Hi Matthias,

The C720 required special patches for the keyboard to work, which I
originally added here:
https://cgit.freebsd.org/src/commit/?id=6c176113bbdd598231ec47d161d4c3714997169b

I assume that something in that area changed recently.

Without digging into it, this looks like a possible cause:

  
https://cgit.freebsd.org/src/commit/sys/dev/atkbdc/atkbd.c?id=ce881170088c4c98c036fe561f8ee8413c2e2585

  atkbd: Disable periodic polling by default.
  It is one of the few remaining Giant-locked callouts.  It would be
  good to remove it, not mentioning that polling itself is not good.

  If this cause keyboard/mouse freezes on some hardware, please set
  loader tunable hw.atkbd.hz=1 as workaround and report the issue.

So you could try to set hw.atkbd.hz=1 (or hw.atkbd.hz=10) in
/boot/loader.conf, then reboot and see if it helps.

Best
Michael

-- 
Michael Gmelin

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

[Michael Gmelin]

On Sat, 2 Sep 2023 09:53:38 +0100
Graham Perrin  wrote:

> Some inspections are extraordinarily time-consuming. Others complete 
> very quickly, as they should.
> 
> One recent inspection took more than half an hour.
> 
> Anyone else?
> 

Does `git clone https://git.freebsd.org/ports.git` work for you?
(currently it's not working from where I am). Maybe related.

Best
Michael


-- 
Michael Gmelin

Re: make buildworld puts legacy tools into the /usr/obj/... tree

[Michael Gmelin]

On 6. Aug 2023, at 18:12, Warner Losh  wrote:On Sun, Aug 6, 2023 at 10:05 AM Matthias Apitz  wrote:El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribió:

> On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz  wrote:
> 
> >
> > I did, based of a git clone of head, a clean compile of world and kernel
> > with
> >
> > # cd /usr
> > # rm -rf obj
> > # mkdir obj
> > # cd src
> > # make -j8 buildworld
> > # make -j8 buildkernel
> > ...
> > I installed the result and the system runs fine. For some test I wanted
> > to do another installation to some DESTDIR with
> >
> > # make installworld DESTDIR=/home/...
> >
> > This failed with:
> >
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> >
> > Investigating the problem it turned out that the 'make buildworld' puts
> > a lot of legacy binaries in to some directory:
> >
> > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > total 36976
> > -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [
> > lrwxr-xr-x  1 root wheel      54 Aug  5 13:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compile
> > -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk
> > -r-xr-xr-x  1 root wheel    9576 Nov 30  2020 basename
> > -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake
> > -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 bunzip2
> > ...
> > They are all from the system before updating it (from Nov 30 2020) and
> > of course are missing shared libs when they get called in the actual
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> >         libdialog.so.8 => not found (0)
> >         ^^
> >         libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)
> >         libc.so.7 => /lib/libc.so.7 (0xf283e729000)
> >         libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)
> >         [vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> >         libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> >         libc.so.7 => /lib/libc.so.7 (0x1797fec89000)
> >         libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)
> >         libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)
> >         libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)
> >         [vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?
> > Or what I have done wrong or overlooked?
> >
> 
> So, the build process builds tools that are used to make and install
> FreeBSD.
> That's what legacy is about: providing a compatible way to do all this. We
> setup env vars, etc, so that these tools pull their libraries from legacy
> as well
> so that we have a consistent set of binaries to run on while the rest of
> the world
> is being replaced. I'm surprised to see this failing, since it's what
> nanobsd does
> all the time, and I build new systems with nanobsd every week based on
> recent
> current trees.
> 
> Is there a libdalog.so.8 in your tmp/legacy tree at all?

No, there is not:

root@jet:~ # find /usr/obj.broken -name libdalog.so.8
root@jet:~ # 

The problem, for sure, is not when you build every day, but in my case
the last build (and the system used for building) was 2 years old. And note:
I started with an empty new /usr/obj.So what's the vintage of the host you are building with? And what sources areyou building...Also of note: we switched to no-clean builds by default which is way faster, butalso exposes issues like this...
Thanks, this is valuable information (starts adapting idempotent playbooks).-m

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

On Thu, 8 Jun 2023 11:32:19 -0600
Warner Losh  wrote:

> On Thu, Jun 8, 2023, 11:18 AM Michael Gmelin 
> wrote:
> 
> > >
> > > Tried today's snaphot, same problem.
> > >
> > >   # reboot
> > >   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 done
> > >   All buffers synced.
> > >   Uptime: 4m14s
> > >   Consoles: userboot
> > >
> > >   FreeBSD/amd64 User boot lua, Revision 1.2
> > >   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> > >   ERROR: cannot open /boot/lua/loader.lua: no such file or
> > > directory.
> > >
> > >
> > >   Type '?' for a list of commands, 'help' for more detailed help.
> > >   OK
> > >
> > >
> > > That's after installing CURRENT in a fresh vm managed by vm-bhyve
> > > using bsdinstall's automatic ZFS option.
> > >  
> >
> > Thinking about this, it's possible that vm-bhyve is using the zfs
> > boot loader from the host machine.
> >
> > Please consider this noise, unless you hear from me again.
> >  
> 
> Yes. It does. This can be an unfortunate design choice at times.
> 

For completeness sake, this is how I boot 14.0 on 13.2 using
sysutils/vm-bhyve:

  ISO=FreeBSD-14.0-CURRENT-amd64-20230608-653738e895ba-263444-bootonly.iso
  export ISO

  cd /mountpoint/for/pool/vm

  vm iso https://download.freebsd.org/snapshots/ISO-IMAGES/14.0/$ISO
  mkdir .loaders
  tar --strip-components 1 -C .loaders -xf .iso/$ISO boot/userboot.so
  mv .loaders/userboot.so .loaders/userboot14.so

  vm create test14
  sysrc -f test14/test14.conf memory=1G
  sysrc -f test14/test14.conf \
bhyveload_loader="$(realpath .loaders/userboot14.so)"

OS installation is done the usual way (using tmux instead of cu in this
example):

  pkg install -y tmux
  sysrc -f .config/system.conf console=tmux
  vm install test14 $ISO
  tmux attach -t test14


Best
Michael

-- 
Michael Gmelin

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

On Thu, 8 Jun 2023 19:06:23 +0200
Michael Gmelin  wrote:

> On Thu, 8 Jun 2023 16:20:12 +
> Glen Barber  wrote:
> 
> > On Thu, Jun 08, 2023 at 06:11:15PM +0200, Michael Gmelin wrote:  
> > > Hi,
> > > 
> > > I didn't dig into this yet.
> > > 
> > > After installing the current 14-snapshot (June 1st) in a
> > > bhyve-vm, I get this on boot:
> > > 
> > >   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> > > 
> > > (booting stops at this point)
> > > 
> > > Seems like the boot loader is missing this recently added feature.
> > > 
> > 
> > Can you try today's snapshot?  They are propagated to most mirrors
> > now.
> >   
> 
> Tried today's snaphot, same problem.
> 
>   # reboot
>   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 done
>   All buffers synced.
>   Uptime: 4m14s
>   Consoles: userboot  
> 
>   FreeBSD/amd64 User boot lua, Revision 1.2
>   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
>   ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> 
> 
>   Type '?' for a list of commands, 'help' for more detailed help.
>   OK 
> 
> 
> That's after installing CURRENT in a fresh vm managed by vm-bhyve
> using bsdinstall's automatic ZFS option.
> 

Thinking about this, it's possible that vm-bhyve is using the zfs boot
loader from the host machine.

Please consider this noise, unless you hear from me again.

Best
Michael

-- 
Michael Gmelin

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

On Thu, 8 Jun 2023 16:20:12 +
Glen Barber  wrote:

> On Thu, Jun 08, 2023 at 06:11:15PM +0200, Michael Gmelin wrote:
> > Hi,
> > 
> > I didn't dig into this yet.
> > 
> > After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
> > get this on boot:
> > 
> >   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> > 
> > (booting stops at this point)
> > 
> > Seems like the boot loader is missing this recently added feature.
> >   
> 
> Can you try today's snapshot?  They are propagated to most mirrors
> now.
> 

Tried today's snaphot, same problem.

  # reboot
  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 done
  All buffers synced.
  Uptime: 4m14s
  Consoles: userboot  

  FreeBSD/amd64 User boot lua, Revision 1.2
  ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
  ERROR: cannot open /boot/lua/loader.lua: no such file or directory.


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


That's after installing CURRENT in a fresh vm managed by vm-bhyve using
bsdinstall's automatic ZFS option.

Best
Michael

-- 
Michael Gmelin

CURRRENT snapshot won't boot due missing ZFS feature

[Michael Gmelin]

Hi,

I didn't dig into this yet.

After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
get this on boot:

  ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2

(booting stops at this point)

Seems like the boot loader is missing this recently added feature.

Best
Michael

-- 
Michael Gmelin

Re: Reducing SIGINFO verbosity

[Michael Gmelin]

On Thu, 23 Jun 2022 11:15:55 -0600
Warner Losh  wrote:

> On Sun, Jun 19, 2022 at 6:06 AM Michael Gmelin 
> wrote:
> 
> >
> >
> > On Fri, 21 May 2021 08:36:49 -0600
> > Warner Losh  wrote:
> >  
> > > On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> > > wrote:
> > >  
> > > > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:  
> > > > > No, I don’t think there’s any reason to default it
> > > > > differently on stable  
> > > > vs  
> > > > > current. I think it’s useful (and I prefer the more verbose
> > > > > form, which isn’t the default).  
> > > >
> > > > I agree that there's no reason for the default to be different,
> > > > but I would say that it is much easier for someone who knows
> > > > that there is a default to be changed to change it, than it is
> > > > for someone who does not. Therefore, if the information is not
> > > > useful to someone who does not know how to get rid of it, then
> > > > it should default to not being displayed, IMHO.
> > > >  
> > >
> > > I plan on changing the default for non-INVARIANT kernels back to
> > > the old behavior.
> > >
> > > INVARIANT kernels will keep this behavior because it's a debugging
> > > kernel and this is one more thing to help debugging problems.
> > >  
> >
> > Did this ever happen? I just installed a fresh 13.1-RELEASE
> > production system (non-INVARIANT kernel) and it seems like SIGINFO
> > still outputs kernel stack information.
> >  
> 
> https://reviews.freebsd.org/D35576 for those who wish to weigh in.
> 
> Warner
> 
> 

Hi Warner,

I just installed 13.2-RELEASE, seems like this was never MFCd (it is in
main, but not in stable/13 or releng/13.2). TBH, I could've checked
myself back then (it's so easy to forget to MFC).

Cheers
Michael

p.s. Learned about it by hitting ctrl-t to check if freebsd-update on my
slow test machine is actually alive :D

-- 
Michael Gmelin

Re: Tooling Integration and Developer Experience

[Michael Gmelin]

> On 31. Jan 2023, at 22:44, Kurt Jaeger  wrote:
> 
> Hi!
> 
 This can be as easy as moving everything into Phabricator.
>>> There's the issue that Phabricator itself is no longer supported
>>> upstream:
> [...]
>>> https://we.phorge.it/
> 
>> Should be no harder than regular update. They even have a HOWTO
>> https://we.phorge.it/w/installation_and_setup/update_from_phabricator/
> 
> So, as a step 0 we would need a phorge port...
>> 1. Upgrade to Phorge
>> 2. Setup Maniphest for bugs and tasks
>> 3. Migrate bugs into Maniphest
>> 4. Enable Harbormaster (Build/CI) - this requires coordination with
>> whoever is working on pre-commit CI.
> [...]
>> Infra operations are hard, and I have experience with it. I'd be happy to
>> help.
> 
> Do you think you can provide a phorge port ?
> 

I created the phabricator port in 2014 and have been maintaining it since then. 
I’m also subscribed to phorge, so technically I could also maintain a phorge 
port (I also have many years of experience in maintaining and using phabricator 
instances, also fixing bugs and adding some local features).

So far I haven’t created a port for phorge, as progress on it seemed very slow 
(and many of the changes were also merged into phab) and therefore there was 
little incentive to migrate any of the instances I maintain.

AFAIK FreeBSD’s phabricator instance is not based on the port and uses custom 
patches anyway (I can’t remember having a single communication with 
phabricator-admin regarding the port), therefore having a phorge port most 
likely isn’t a pre-condition for the project to use it.

Best 

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

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

On Sun, 28 Aug 2022 03:21:24 -0700
Cy Schubert  wrote:

> In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>,
> Michael Gmelin w
> rites:
> > 
> >
> >  
> > > On 28. Aug 2022, at 10:42, free...@oldach.net wrote:
> > >=20
> > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > (CEST):  
> > >> As stated before in this thread, replacing /var/run with tmpfs
> > >> is not a supported configuration.  
> > >=20
> > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > creates a t=  
> > mpfs backed /var, populates it through mtree, and makes a proper
> > /var/run av= ailable.  
> > >=20
> > > However it doesn't (yet) create /var/run/clamav of course.
> > >=20
> > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > walks thro=  
> > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > found as need= ed. All that the security/clamav port would need to
> > do then is to drop an ap= propriate small mtree file as
> > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > the same logic as dropping service scripts as /usr/local/=
> > etc/rc.d/clamav-*.
> >
> > =46rom a user's perspective, it would be preferable to have this
> > happen at s= ervice start though, as (unlike in the setup
> > described) reboots don't happen= that frequently, but files in
> > /var/run might get deleted manually. Maybe so= me rc framework
> > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > which, if set, is applied in the default start_precmd. Besides
> > being mo= re resilient, this would also have the advantage that all
> > required file syst= ems should be available at that point and the
> > separation between system and p = orts would be more clear. Another
> > advantage would be that directories are on= ly created for services
> > that are actually enabled/started.  
> 
> Unfortunately this requires all ports to include an mtree file.
> Relying on port maintainers who are human to ensure that these files
> are created and updated when ports are created and maintained will
> result in more human error. I've learned over my long career to rely
> more on automation than human beings. Automation [should] never fail
> and when it does it does temporarily until the bug is found and
> fixed. Human beings inconsistently fail.
> 
> If it were an auto-discovery script that created an mtree file as
> part of the packaging process, it would be another matter. But this
> optional solution path should be discussed on ports@, not here.
> 
> 

I don't have much skin in the game, but I created a little proof of
concept to allow further discussion (which is not ports-specific, as it
works for all service scripts):

https://reviews.freebsd.org/D36385

This basically allows both system admins and port maintainers to
create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
always relative to the service script called) which are automatically
applied on service start. It's non-intrusive and doesn't require any
sweeping changes to existing ports/services.

In this specific case, the requester could create
/usr/local/etc/mtree/clamav-clamd with the required content (or
persuade the port maintainer to include that file).

You could of course add some construct to the ports framework that
picks up certain directories from the package list automatically and
places them into an mtree file as part of the build or installation
process. But that would be an additional feature on top of this change.

This is meant to inspire more discussions, I'm not trying to force
anything in. ;)

Cheers
Michael

-- 
Michael Gmelin

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 28. Aug 2022, at 10:42, free...@oldach.net wrote:
> 
> Cy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):
>> As stated before in this thread, replacing /var/run with tmpfs is not a
>> supported configuration.
> 
> Not supported? What is the purpose of /etc/rc.d/var then? That creates a 
> tmpfs backed /var, populates it through mtree, and makes a proper /var/run 
> available.
> 
> However it doesn't (yet) create /var/run/clamav of course.
> 
> It would be fairly easy to extend /etc/rc.d/var by a logic that walks through 
> /usr/local/etc/mtree/* and runs mtree on each of the files found as needed. 
> All that the security/clamav port would need to do then is to drop an 
> appropriate small mtree file as /usr/local/etc/mtree/clamav. From a port's 
> perspective that is the same logic as dropping service scripts as 
> /usr/local/etc/rc.d/clamav-*.

From a user's perspective, it would be preferable to have this happen at 
service start though, as (unlike in the setup described) reboots don't happen 
that frequently, but files in /var/run might get deleted manually. Maybe some 
rc framework based solution would make sense, e.g., a variable `mtree_files`, 
which, if set, is applied in the default start_precmd. Besides being more 
resilient, this would also have the advantage that all required file systems 
should be available at that point and the separation between system and ports 
would be more clear. Another advantage would be that directories are only 
created for services that are actually enabled/started.

Cheers
Michael

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 27. Aug 2022, at 15:18, free...@oldach.net wrote:
> 
> Michael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST):
>> (you're removing /var/run, which shouldn't be removed
> 
> Not quite. It's actually not uncommon to boot with an empty /var. Please see 
> /etc/rc.d/var and related.

That’s a good point.

> The request that ports/packages should consider this case is not exactly 
> unreasonable IMO.
> 

If I was the maintainer, I would simply add the code to create the directory 
for robustness sake (I for one deleted subdirs in /var/run more than once and 
would expect a port to fix this on restart, also to make sure correct 
permissions are applied). But since it doesn’t seem like this is going to 
happen, adding a custom rc file would be a viable short term workaround for the 
requester.

I like the idea of having something like tmpfiles.d, it would also help port 
maintainers (could also be done as a port).

Cheers

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 27. Aug 2022, at 12:54, FreeBSD User  wrote:
> 
> Am Sat, 27 Aug 2022 11:21:40 +0200
> Michael Gmelin  schrieb:
> 
>>>> On 27. Aug 2022, at 08:31, FreeBSD User  wrote:
>>> 
>>> Hello,
>>> 
>>> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
>>> 
>>> Port security/clamav is without doubt for many of FreeBSD users an 
>>> important piece of
>>> security software so I assume a widespread usage.
>>> 
>>> It is also a not uncommon use case to use NanoBSD or any kind of 
>>> low-memory-footprint
>>> installation schemes in which /var/run - amongst other system folders - are 
>>> created at boot
>>> time as TMPFS and highly volatile.
>>> 
>>> In our case, the boxes running a small security appliance based upon 
>>> FreeBSD is rebooted
>>> every 24 hours and so /var/run is vanishing.
>>> 
>>> To make the long story short:
>>> 
>>> The solution for this problem would be a check for existence and take 
>>> action addendum in
>>> precmd() routine of the rc-script as sketched in Bug 259699.
>>> The maintainer rejects such a workaround by arguing this would violate POLA 
>>> (see comment 4
>>> in PR 259699 [2]. The maintainer's argument regaring to mtree's files are 
>>> sound to me.
>>> 
>>> The question is: how can this issue be solved?
>>> 
>>> It is really hard to always chenge our local repository and patch whenever 
>>> clamav has been
>>> patched and modified for what reason ever.
>>> 
>>> Tahanks for reading,
>>> 
>> 
>> Why don’t you simply add an rc script to your appliance that creates the 
>> missing
>> directory/directories on boot before clamav is started?
>> 
>> Best
>> Michael
>> 
>> 
>> 
> 
> Why not fixing this on a more general basis?

It‘s a reasonable way forward, given the limitations you described (you’re 
removing /var/run, which shouldn’t be removed and the port maintainer not 
willing to add code to compensate for this). This would fix it for you for your 
specific needs in a reliable way, you would never have to patch the port again 
and also won’t use other people‘s time to find a general solution to your very 
specific problem. It’s a sustainable quick fix to your problem at hand. You can 
always come up with something grand later, but this would actually work right 
away.

Cheers

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[Michael Gmelin]

> On 27. Aug 2022, at 08:31, FreeBSD User  wrote:
> 
> Hello,
> 
> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> 
> Port security/clamav is without doubt for many of FreeBSD users an important 
> piece of security
> software so I assume a widespread usage.
> 
> It is also a not uncommon use case to use NanoBSD or any kind of 
> low-memory-footprint
> installation schemes in which /var/run - amongst other system folders - are 
> created at boot
> time as TMPFS and highly volatile.
> 
> In our case, the boxes running a small security appliance based upon FreeBSD 
> is rebooted every
> 24 hours and so /var/run is vanishing.
> 
> To make the long story short:
> 
> The solution for this problem would be a check for existence and take action 
> addendum in
> precmd() routine of the rc-script as sketched in Bug 259699.
> The maintainer rejects such a workaround by arguing this would violate POLA 
> (see comment 4 in
> PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound 
> to me.
> 
> The question is: how can this issue be solved?
> 
> It is really hard to always chenge our local repository and patch whenever 
> clamav has been
> patched and modified for what reason ever.
> 
> Tahanks for reading,
> 

Why don’t you simply add an rc script to your appliance that creates the 
missing directory/directories on boot before clamav is started?

Best
Michael

Re: main-n257625-587649902329-dirty?

[Michael Gmelin]

> On 26. Aug 2022, at 18:55, Nuno Teixeira  wrote:
> 
> 
> Hello to all,
> 
> Today I updated and uname -a shows main-n257625-587649902329-dirty.
> Why is showing -dirty?
> 

This means that the git workdir it was built on was dirty, see 
https://remarkablemark.org/blog/2017/10/12/check-git-dirty/

Cheers
Michael

Re: ZFS: cannot import zroot: I/O error

[Michael Gmelin]

> On 15. Aug 2022, at 18:22, Toomas Soome  wrote:
> 
> 
> 
>> On 15. Aug 2022, at 18:01, FreeBSD User  wrote:
>> 
>> Hello,
>> 
>> I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox 
>> 4.1.24/26 (do not know
>> exactly). The host is a special system based on Linux und VirtualBox and I 
>> have no chances to
>> configure the VBox.
>> 
>> Somehow the VBox crashed and hung up the complete computer, so I had to cold 
>> start it after
>> approx. 30 minutes of waiting. After that, rhe virtual drive and its ZFS 
>> filesystem was
>> wrecked, shwing a stream of 
>> 
>> zio_read error: 5
>> ZFS: i/o error - all block copies unavailable
>> 
>> After a quick search I found some advices howto try fixing, last an longest 
>> one was 
>> 
>> zpool import -fFX -N -R /alternate/path zroot
>> 
>> which took approx 20 minutes - with no success.
>> 
>> There are some valuable data on the partition, which are all backed up, but 
>> it would take its
>> time to restore everything, so I'd like to ask whether there is any cance to 
>> "repair" the
>> mysterious damage.
>> 
>> I'm able to boot off from an USB flash drive …
>> 
> 
> This happens when vbox is telling zfs that data is written on disk, but is 
> actually still in caches… So yea, the standard answer could be “restore from 
> backup”, but it also may help to use ability to revert TXG (it does drop 
> data!).  See also 
> https://gist.github.com/mkhon/34d979c78077a20648456272d7f2cc15
> 

While it might not help the requester with the problem at hand, this situation 
can be prevented (or at least made less likely) by disabling "IgnoreFlush" - 
depending on the virtual device emulated this could be something like:

VBoxManage setextradata VM-name   
"VBoxInternal/Devices/ahci/0/LUN#[0]/Config/IgnoreFlush" 0

or

VBoxManage setextradata VM-name 
"VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/IgnoreFlush" 0

See also: https://www.virtualbox.org/manual/ch12.html#ts_ide-sata-flush

It’s highly recommended for ZFS in case your VM isn’t a throwaway CI thing.

Best
Michael

Re: pkg: Newer FreeBSD version for package... but why?

[Michael Gmelin]

On Wed, 13 Jul 2022 10:29:06 +0300
Andriy Gapon  wrote:

> # uname -U
> 1400063
> 
> # uname -K
> 1400063
> 
> # pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching packagesite.pkg: 100%5 MiB   4.8MB/s00:01
> Processing entries:   0%
> Newer FreeBSD version for package zyre:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400063
> - running kernel: 1400051
> Ignore the mismatch and continue? [y/N]:
> 
> Does anyone know why this would happen?
> Where does pkg get its notion of the running kernel version?
> 

If I'm reading the sources correctly, it's determining the OS version
by looking at the elf headers of various files in this order:

getenv("ABI_FILE")
/usr/bin/uname
/bin/sh

So I would assume that `file /usr/bin/uname` shows 1400051 on your
system.

You can point it to checking another file by setting ABI_FILE[0] in the
environment or ignore the check by setting IGNORE_OSVERSION (like
advised). The "running kernel:" label seems a bit misleading.

Cheers
Michael

-- 
Michael Gmelin

Re: Accessibility in the FreeBSD installer and console

[Michael Gmelin]

> On 9. Jul 2022, at 03:22, Klaus Küchemann  wrote:
> 
> 
>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>> 
>> Hi,
>> 
>> The only argument I've heard from some non-sighted friends about not using 
>> FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the 
>> start if I press this and this key. …….
> 
> Hi,
> 
> I would like to shortly introduce myself.
> I am indispensable  for all your friends and everybody else
> and yes, I can speak (and I can even hear)-
> I am the de facto standard for everything audio for Apple users and I even 
> can 
> make users of other OSes very very happy.
> 
>> 
>> Am 08.07.2022 um 12:53 schrieb Hans Petter Selasky :
>> Hi,
>> Here is the complete patch for Voice-Over in the FreeBSD console:
>> 
>> https://reviews.freebsd.org/D35754
>> 
>> You need to install espeak from pkg and then install the 
>> /etc/devd/accessibility.conf file and then run sysctl 
>> kern.vt.accessibility.enable=1 after booting the new kernel.
>> 
>> It is freaking awesome!
>> 
>> There might be some bugs, but it worked fine for me!
>> 
>> —HPS
> 
> Congratulations ! 
> 
> But while reading the docs of your system`s bluetooth drivers I became a bit 
> afraid 
> that I won’t be fully supported , I hope this is unfounded.
> 
> It’s not only that I’m a shiny white culty thing ..
> your friends can leave me in their ears and can simultaneously hear the 
> surroundings AND the Audio output.
> That’s why I’m indispensable…
> 
> Will you ensure that at least one bt-chip will support me in your system and 
> will you 
> care for the corresponding drivers?
> 
> If yes I would be happy to meet you in your VT-console ,
> 
> And when you later even support vice versa: 
> -SpeechToText- ,
> It’s possible that we become friends for life .
> 
> 
> Best Regards,
> yours 
> 
> AirPodsPro  :-) 

But why would you ever leave your family that was designed from the ground up 
to match you and any need you could potentially have? And why would you not 
share any word your "owner" (the person who spent money on you, so they could 
use you) says with your creator and all its connected systems and entities, so 
that they could be fully analyzed and monetized?

-m

p.s. seriously, if you want the full Apple experience, you really should stay 
within their ecosystem. Trying to compete with that (with all its questionable 
implications in terms of digital sovereignty) is pointless, especially if you 
are neither broke nor care too much about privacy. If these things mean nothing 
to you, just buy the off the shelf solution and save the time that tinkering 
with free alternatives (that will never be as smooth as "the real thing") would 
require and spend it on things that mean something to you (friends, family, 
charity).

Re: Accessibility in the FreeBSD installer and console

[Michael Gmelin]

> On 8. Jul 2022, at 14:48, Hans Petter Selasky  wrote:
> 
> On 7/8/22 14:34, David Chisnall wrote:
> Snipsnap
> Hi,
> 
> I've updated my patch a little bit, so please re-fetch it.
> 
> I tried:
> 
> action  "echo -- $text | rtprio 8 
> /usr/local/bin/flite_cmu_us_slt"
> 
> And it doesn't sound as good as espeak :-(
> 
> Do we have more of these in ports which are know to be good?
> 

A very long time ago I used festival, which seems to exist as a package (pkg 
install festival festvox-voiceyouneed).

It’s quite old though (I assume that "flite" is the light version of it), back 
then it sounded ok, but we were easy to impress ;)

Cheers

Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums

[Michael Gmelin]

On Mon, 27 Jun 2022 16:18:58 +
Ivan Quitschal  wrote:

> > Hi,
> >
> >Can you dump "kldstat" at the different times?  
> 
> >I guess it may be just be that the wrong module is loaded first, so
> >it grabs the device, because there are no other drivers loaded, even
> >though ums is a generic driver.  
> 
> >Try loading all relevant drivers in /boot/loader.conf . Then the
> >attach order shouldn't matter.  
> 
> >--HPS  
> 
> 
> Hi Michael 
> 
> Yes , hw.usb.usbhid.enable="1" is in loader.conf , not sysctl 
> 
> Hi Warner
> 
> When ums.ko is up, the second attach is always taken by "ums" first
> no matter what. First time you boot tho, it takes the correct one
> (hms)
> 
> Hi Hans
> 
> Looks like this below is the only order I could make it work even tho
>  uhid and usbhid get loaded regardless what I put on loader.conf
> 
> usbhid_load="NO" <-- still loaded anyway
> uhid_load="NO" <-- still loaded anyway
> ums_load="NO" <- this one is not loaded
> ic_load="YES"
> iichid_load="YES"
> hidbus_load="YES"
> hsctrl_load="YES"
> hidmap_load="YES"
> hcons_load="YES"
> hkbd_load="YES"
> hms_load="YES"
> hmt_load="YES"
> hconf_load="YES"
> 
> hw.usb.usbhid.enable="1"
> 
> with the order below , after 5 reboots and lots of kvm switches , it
> always ended up on the right iichid device. Seems to be working now
> 
> but like I said, its random, let see after some more reboots if this
> rule is still valid

I don't know if it makes any difference in your case, but I had best
results loading these drivers through rc.conf, e.g.:

  sysrc kld_list+="hidraw hkbd"

Cheers
Michael

-- 
Michael Gmelin

Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums

[Michael Gmelin]

On Mon, 27 Jun 2022 15:19:28 +
Ivan Quitschal  wrote:

> Hi all
> 
> Not sure if I found a problem here but here we go.
> 
> Since I have a KVM usb switch here for keyboard/mouse sometimes I
> toggle it between my windows and freebsd. I am using iichid here to
> have my multimedia keys working on keyboard and all
> 
> hw.usb.usbhid.enable="1"
> 
> Im also using Wulf's moused
> https://github.com/wulf7/moused
> so far so good. Problem is:
> 
> when I switch to windows , everything is detached correctly (hms,
> hkbd etc), but when I switch back, sometimes the keyboard and mouse
> are wrongly attached to "ums" device , not hms. (sometimes it goes to
> the correct one). Shouldn't ums/uhid modules be deactivated once
> hw.usb.usbhid.enable is set to 1 ?
> 
> The workaround I did here was to manually kldunload both uhid.ko and
> ums.ko within rc.local during boot. This way I can detache attach the
> kbd/mouse back as much as I want and it always end up in hms/hkbd
> devices
> 
> Is this how its supposed to function? Randomly choosing between ums
> or hms?

Did you set hw.usb.usbhid.enable="1" in /boot/loader.conf, or by using
the sysctl? If you don't do it yet, I'd recommend the former.

Cheers
Michael

> 
> Thanks
> 
> --tzk
> 



-- 
Michael Gmelin

Re: Posting netiquette: HTML, attachments etc.

[Michael Gmelin]

> On 26. Jun 2022, at 20:19, Walter Parker  wrote:
> 
> 
> So, utf-8 is good, posting to multiple lists is bad (but ok when you do it),

I didn’t insinuate that it’s good for me to post to three lists at a time 
either, but how would you decide which one to leave out when responding to a 
post you received on multiple lists? My original response reduced the number of 
lists involved, but I was quoted on all three lists again, so I also responded 
on all of them.

> what about the original post? He was asking about HTML. UTF-8 != HTML. UTF is 
> a character encoding format. It is supported by most email clients and does 
> not require HTML for support.
> 

At some point in this email exchange he was suggesting to remove any kind of 
special characters from email and documentation and my original response (he 
quoted) was partially about this.

If it’s just about HTML: I would love to eliminate HTML email, but most email 
clients create it without the user having a chance to intervene. An example is 
iOS Mail, which creates html as soon as you copy and paste almost anything into 
it. AFAIK it still manages to create a useful plain text alternative (unlike 
BBOS 10, if anyone remembers), which makes it better than other email clients - 
so filtering away html in this case would be fine. But there is no option that 
says “send plaintext email”.

I also agree that the original exchange that sparked this debate was quite 
terrible in terms of email formatting (it looked like outlook, no quoting, top 
posting like exchanging written letters, using various font types and sizes). 
So if we could eliminate these kind of emails, I would be happy.

Cheers
Michael 

p.s. I’m pretty sure top posting is also against netiquette - unless *you* do 
it of course ;)

> 
> Walter
> 
>> On Sun, Jun 26, 2022 at 2:56 AM Michael Gmelin  wrote:
>> 
>> 
>>>> On 26. Jun 2022, at 09:37, grarpamp  wrote:
>>>> 
>>> 
>>>> 
>>>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc
>>>> 
>>>> FreeBSD Handbook: Appendix C: updates and corrections
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264754
>>>> 
>>>> I'm glad that HTML is supported.
>>> 
>>> No, people should not be sending HTML emails to lists.
>>> Consult history of email netiquettes to discover the many why's.
>>> 
>>>> Also, I want support for things such as PNG.
>>> 
>>> Attachments are not necessarily against such netiquettes,
>>> but rightly tend to be administratively size limited.
>>> 
>>>> What is the possibility of getting the/a "netiquette" link in
>>>> the FreeBSD Mailinglist footer that is already appended to all
>>>> the messages?
>>> 
>>> There is no such footer appended to the lists, because they're bloat.
>>> Their aims usually better done at first via signup, in quarterly, and
>>> via the occaisional involuntary and accepted friendly cluebat.
>>> 
>>> 
>>>> we are dealing with real people working with the email
>>>> clients available to them in 2022
>>> 
>>> Same arguments was made in 1982 1992 2002 etc, and the netiquette
>>> won validity for good reasons and is still taught trained and disciplined.
>> 
>> Trying to stop people from using UTF-8 is futile. Also, quoting various 
>> arguments from different people without context is bad style - I gave very 
>> specific examples, including the fact that a lot of email is written on 
>> mobile devices where people don’t have control over many aspects of how 
>> things are sent and I argued which parts of netiquette could/should still be 
>> followed given the realities of today and where we need to relax if we want 
>> to have communication happen on our mailing lists.
>> 
>> My answer here is an example of that - there is no reasonable way to follow 
>> any line length limits on a phone and it also automatically chooses the 
>> typographically correct UTF-8 characters, even though I would prefer to use 
>> ASCII - but there is no way I’ll change every single "‘" to "'" manually or 
>> disable the features that make typing on such a device an acceptable 
>> experience. Just won’t happen.
>> 
>> If your email client and/or your desktop can’t handle UTF-8, it’s time to 
>> fix your setup.
>> 
>> -m
>> 
>> p.s. Is it really necessary to have this discussion on multiple lists?
>> 
> 
> 
> -- 
> The greatest dangers to liberty lurk in insidious encroachment by men of 
> zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: Posting netiquette: HTML, attachments etc.

[Michael Gmelin]

> On 26. Jun 2022, at 09:37, grarpamp  wrote:
> 
> 
>> 
>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc
>> 
>> FreeBSD Handbook: Appendix C: updates and corrections
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264754
>> 
>> I'm glad that HTML is supported.
> 
> No, people should not be sending HTML emails to lists.
> Consult history of email netiquettes to discover the many why's.
> 
>> Also, I want support for things such as PNG.
> 
> Attachments are not necessarily against such netiquettes,
> but rightly tend to be administratively size limited.
> 
>> What is the possibility of getting the/a "netiquette" link in
>> the FreeBSD Mailinglist footer that is already appended to all
>> the messages?
> 
> There is no such footer appended to the lists, because they're bloat.
> Their aims usually better done at first via signup, in quarterly, and
> via the occaisional involuntary and accepted friendly cluebat.
> 
> 
>> we are dealing with real people working with the email
>> clients available to them in 2022
> 
> Same arguments was made in 1982 1992 2002 etc, and the netiquette
> won validity for good reasons and is still taught trained and disciplined.

Trying to stop people from using UTF-8 is futile. Also, quoting various 
arguments from different people without context is bad style - I gave very 
specific examples, including the fact that a lot of email is written on mobile 
devices where people don’t have control over many aspects of how things are 
sent and I argued which parts of netiquette could/should still be followed 
given the realities of today and where we need to relax if we want to have 
communication happen on our mailing lists.

My answer here is an example of that - there is no reasonable way to follow any 
line length limits on a phone and it also automatically chooses the 
typographically correct UTF-8 characters, even though I would prefer to use 
ASCII - but there is no way I’ll change every single "‘" to "'" manually or 
disable the features that make typing on such a device an acceptable 
experience. Just won’t happen.

If your email client and/or your desktop can’t handle UTF-8, it’s time to fix 
your setup.

-m

p.s. Is it really necessary to have this discussion on multiple lists?

Re: Reducing SIGINFO verbosity

[Michael Gmelin]

On Fri, 21 May 2021 08:36:49 -0600
Warner Losh  wrote:

> On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> wrote:
> 
> > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:  
> > > No, I don’t think there’s any reason to default it differently on
> > > stable  
> > vs  
> > > current. I think it’s useful (and I prefer the more verbose form,
> > > which isn’t the default).  
> >
> > I agree that there's no reason for the default to be different, but
> > I would say that it is much easier for someone who knows that there
> > is a default to be changed to change it, than it is for someone who
> > does not. Therefore, if the information is not useful to someone
> > who does not know how to get rid of it, then it should default to
> > not being displayed, IMHO.
> >  
> 
> I plan on changing the default for non-INVARIANT kernels back to
> the old behavior.
> 
> INVARIANT kernels will keep this behavior because it's a debugging
> kernel and this is one more thing to help debugging problems.
> 

Did this ever happen? I just installed a fresh 13.1-RELEASE production
system (non-INVARIANT kernel) and it seems like SIGINFO still outputs
kernel stack information.

Cheers
Michael

-- 
Michael Gmelin

Re: SAS/SATA controllers: 8 port that support 8TB Drives

[Michael Gmelin]

> On 18. Jun 2022, at 15:10, Larry Rosenman  wrote:
> 
> 
> On 06/18/2022 3:54 am, Michael Gmelin wrote:
> 
> [SNIP]
> 
>  
> Subvendor is Fujitsu Siemens - so I guess this is integrated into a system by 
> them.
>  
> Seems like flashing the 2108 to an IT firmware isn't an option (based on what 
> I found online). You could check if there are firmware updates available 
> though. How did you configure the drives in the megaraid utility (ctrl-h 
> after boot)? Did you create a RAID-0 for each disk? And what capacity is 
> shown in there?
>  
> Based on [0], 2108 based controllers don't support 4kn. IT mode would help 
> (true passthrough), but as written above, I don't think it's an option for 
> this model.
>  
> -m
>  
> [0] https://bitdeals.tech/blogs/news/4kn-lsi-compatibility-list
> 
> 
> 
> as I said earlier in the thread, I've bought 2 of these:
> https://www.ebay.com/itm/194910024856
>  
> which if I'm reading that chart right should work with the 4Kn drives. 
>  

That certainly sounds promising.

Best
Michael
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: SAS/SATA controllers: 8 port that support 8TB Drives

[Michael Gmelin]

> On 18. Jun 2022, at 01:31, Larry Rosenman  wrote:
> On 06/17/2022 6:20 pm, Michael Gmelin wrote:
>>>> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
>>> On 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>>>> 
>>>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to something 
>>>>>>>>> that will
>>>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>>>>>>>> support 8TB drives.
>>>>>>>>> What's the communities recommendation?
>>>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, as I 
>>>>>>>>> have 16 slots.
>>>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>>>>>>> is directly related to capacity.  According to my observations it may
>>>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>>>> Seagate HDDs in our products, so about that instability I only heard
>>>>>>>> from forums and TrueNAS community user reports.
>>>>>>> This is a mfi(4) set of controllers, and a ST8Nm0045 8TB (CMR) 
>>>>>>> drive.
>>>>>>> Is this a bad combo?
>>>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>>>> mfi0 Physical Drives:
>>>>>>> 0 (  932G) UNCONFIGURED GOOD  
>>>>>>> SATA E1:S3
>>>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due 
>>>>>> to problems with hot-plug, disk identification, etc. and so have limited 
>>>>>> experience with them.  But I know some of LSI RAIDs can be reflashed 
>>>>>> into equivalent HBAs, so if they share the hardware, I can speculate 
>>>>>> that they may share some issues.
>>>>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
>>>>> problem than what we heard for HBAs.  It looks like a kind of problems 
>>>>> that should not happen to HBAs, since they should not care about disk 
>>>>> capacity.
>>>> What does `smartctl -a ` report (especially sector sizes)?
>>>> -m
>>>>> --
>>>>> Alexander Motin
>>> It's not even making a mfid* node (it is a 4Kn disk)
>> Ok, that’s sad (and explains the wrong size calculation as 4096/512=8).
>> Is this in HBA mode? (Like Alexander suggested, re-/crossflashing
>> using an IT firmware might be an option). What controller / firmware
>> image version is it?
>> -m
>>> --
>>> Larry Rosenman http://www.lerctr.org/~ler
>>> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
>>> US Mail: 570

Re: SAS/SATA controllers: 8 port that support 8TB Drives

[Michael Gmelin]

> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
> On 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>> 
>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to something 
>>>>>>> that will
>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>>>>>> support 8TB drives.
>>>>>>> What's the communities recommendation?
>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, as I 
>>>>>>> have 16 slots.
>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>>>>> is directly related to capacity.  According to my observations it may
>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>> Seagate HDDs in our products, so about that instability I only heard
>>>>>> from forums and TrueNAS community user reports.
>>>>> This is a mfi(4) set of controllers, and a ST8Nm0045 8TB (CMR) drive.
>>>>> Is this a bad combo?
>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>> mfi0 Physical Drives:
>>>>>  0 (  932G) UNCONFIGURED GOOD  
>>>>> SATA E1:S3
>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due to 
>>>> problems with hot-plug, disk identification, etc. and so have limited 
>>>> experience with them.  But I know some of LSI RAIDs can be reflashed into 
>>>> equivalent HBAs, so if they share the hardware, I can speculate that they 
>>>> may share some issues.
>>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
>>> problem than what we heard for HBAs.  It looks like a kind of problems that 
>>> should not happen to HBAs, since they should not care about disk capacity.
>> What does `smartctl -a ` report (especially sector sizes)?
>> -m
>>> --
>>> Alexander Motin
> It's not even making a mfid* node (it is a 4Kn disk)

Ok, that’s sad (and explains the wrong size calculation as 4096/512=8).

Is this in HBA mode? (Like Alexander suggested, re-/crossflashing using an IT 
firmware might be an option). What controller / firmware image version is it?

-m


> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

Re: git question: How do I push a cherry-pick of someone else's commit?

[Michael Gmelin]

What is the error message?

Did you try “git push -f”

> On 9. Jun 2022, at 21:33, Rick Macklem  wrote:
> 
> I just tried to MFC a commit done to fix my commit by imp@
> and it won't let be push the cherry-pick.
> 
> What's the trick to doing this?
> Or do I need to get Warner to do it?
> If so, it's 393b7606f9c1 in main, that needs to go into stable/13.
> 
> rick
> ps: The stable/13 build will be broken until this gets resolved.
>  I'll revert the MFC if it isn't fixed soon.
> 

Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory"

[Michael Gmelin]

On Thu, 28 Apr 2022 12:31:06 +0200
Stefan Esser  wrote:

> Am 28.04.22 um 09:11 schrieb Baptiste Daroussin> It is 2 things, it
> is a port problem of maintainers who do not check for
> > upgradability of their packages, and it can also been seen as
> > something pkg can deal with, but a complicated case, so I don't
> > know yet how.
> > 
> > The main issue is a file in vX which becomes a directory in vX+1
> > which goes in the way pkg does extract files to be as atomic as
> > possible.  
> 
> This case could be caught and dealt with by removing the file or by
> moving it out of the way (to a temporary name to allow it to be
> recovered if the subsequent steps fail or to be deleted if they
> succeed).
> 
> Further special conditions may apply - but since there is no way a
> file and directory can exist under the same name (on FreeBSD, at
> least), it is safe to assume that the file will not be kept when the
> package is installed.

The opposite case seems more interesting/problematic.

-m

-- 
Michael Gmelin

Re: recover deleted file

[Michael Gmelin]

> On 17. Apr 2022, at 06:20, Peter Jeremy  wrote:
> 
> On 2022-Apr-17 01:13:02 +0300, Sami Halabi  wrote:
>> I understand its hard to undelete since no one designed UFS/ZFS to do so..
>> that why I asked in later replies to see if someone would step in and
>> implement such a "feature" and I suggested some directions/thoughts.
> 
> As you point out, neither UFS nor ZFS were designed to support an
> "undelete" function: Once an inode has no references (open files
> or directory entries), the inode and all associated data blocks are
> returned to the free list and could be used by a subsequent allocation.
> 
> What semantics would you like UFS or ZFS to implement instead?  Is it
> just that the inode and associated data blocks should stay in limbo
> for some period?  If, what controls the period?  What if a file is
> truncated to 0 or overwritten before being unlinked?  How much would
> you be willing to pay for "undelete" functionality?
> 
>> As soren@ suggested in later reply it maybe would be easier to implement
>> custom rm script that moves files to "Recycle bin" directory (and empty it
>> after some period)
> 
> Alternatively, you could alias "rm" to "rm -i".
> 
>> but as a programmer I know that perfection is needed :)
>> so It might start as a simple task and end in many what-if's
>> (unfortunattly I did my last C programming in late 2003!).
> 
> This doesn't need to be C.  You could do this in your scripting
> language of choice.  Or you could offer to pay someone to do this
> for you.
> 
>> What amzes me is that this "feature" was asked too much in the last decade
>> or two and no one ever implemented it, maybe it's not needed in daily
>> usage, but in disasters it would be super userful, save admins many time
>> and nerves..
> 
> I went rummaging back through my mail archives and it actually doesn't
> seem to come up that often.  You seem to be about the 3rd person this
> century on the lists I read.  I did find a discussion in zfs-discuss
> from May/June 2006 about supporting undelete but it seems that no
> agreement on the desired behaviour was achieved.
> 
>> For now I did some backup tools locally and used chflags to mark them
>> undeletable so I wouldn't do that mistake again,
> 
> You could also consider snapshots - both UFS and ZFS support snapshots.
> 
> If the information is very critical (you mentioned legal consequences)
> then you might like to consider real-time replication of the MySQL redo
> logs to another systems - though that won't necessarily protect you
> from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;

It will, if you keep the binary logs/replication logs around. Combined with 
regular zfs snapshots (on the replicant‘s side) you can do a robust and 
relatively speedy point in time recovery that prevents data loss (ideally, 
access to the main db and the replicant is segregated). Saved me more than once.

Best
Michael

Re: recover deleted file

[Michael Gmelin]

> On 16. Apr 2022, at 14:32, Sami Halabi  wrote:
> 
> 
> how to do step 3 /?

E.g., grep for something you know (like a phrase, unique name etc) from the 
file, then dump N times the expected file size from that position into another 
file, open the result in a “robust” text editor and stitch things together.

If your lost file is something binary (or even worse, encrypted), things get a 
lot more complicated of course. There might be tooling for this I’m not aware 
of, the few times this happened to me, lost files where C++ sources that were 
relatively easy to extract manually.

Best
Michael

> 
>> On Sat, Apr 16, 2022 at 2:59 PM Michael Gmelin  wrote:
>> Depends on the kind of file.
>> 
>> You can always:
>> 1. reboot the system into single user mode, mount the fs readonly (important 
>> to not overwrite data you want to recover)
>> 2. dd the partition and into a file
>> 3. find the content of the deleted file in the dump
>> 
>> I was able to recover a complete codebase i deleted accidentally that way a 
>> long time ago.
>> 
>> Good luck
>> Michael
>> 
>>>> On 16. Apr 2022, at 13:52, Sami Halabi  wrote:
>>>> 
>>> 
>>> well.. thats the trivial answer.. the problem is backups is a day before... 
>>> if i can undelete it would save me loss of 1 day offset..
>>> 
>>> anyone?
>>> 
>>>> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz  wrote:
>>>> El día sábado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribió:
>>>> 
>>>> > Hi,
>>>> > is there anyway easy to restore deleted file by accident in UFS
>>>> 
>>>> Yes, restore it from a backup media.
>>>> 
>>>> matthias
>>>> 
>>>> 
>>>> -- 
>>>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ 
>>>> +49-176-38902045
>>>> Public GnuPG key: http://www.unixarea.de/key.pub
>>>> 
>>>> Peace instead of NATO!  Мир вместо НАТО!  Frieden statt NATO! ¡Paz en vez 
>>>> de OTAN!
>>>> 
>>> 
>>> 
>>> -- 
>>> Sami Halabi
>>> Information Systems Engineer
>>> NMS Projects Expert, FreeBSD SysAdmin Expert
>>> Asterisk Expert
> 
> 
> -- 
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert, FreeBSD SysAdmin Expert
> Asterisk Expert

Re: recover deleted file

[Michael Gmelin]

Depends on the kind of file.

You can always:
1. reboot the system into single user mode, mount the fs readonly (important to 
not overwrite data you want to recover)
2. dd the partition and into a file
3. find the content of the deleted file in the dump

I was able to recover a complete codebase i deleted accidentally that way a 
long time ago.

Good luck
Michael

> On 16. Apr 2022, at 13:52, Sami Halabi  wrote:
> 
> 
> well.. thats the trivial answer.. the problem is backups is a day before... 
> if i can undelete it would save me loss of 1 day offset..
> 
> anyone?
> 
>> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz  wrote:
>> El día sábado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribió:
>> 
>> > Hi,
>> > is there anyway easy to restore deleted file by accident in UFS
>> 
>> Yes, restore it from a backup media.
>> 
>> matthias
>> 
>> 
>> -- 
>> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
>> Public GnuPG key: http://www.unixarea.de/key.pub
>> 
>> Peace instead of NATO!  Мир вместо НАТО!  Frieden statt NATO! ¡Paz en vez de 
>> OTAN!
>> 
> 
> 
> -- 
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert, FreeBSD SysAdmin Expert
> Asterisk Expert

Re: Deprecating ISA sound cards

[Michael Gmelin]

> On 20. Mar 2022, at 15:45, David Chisnall  wrote:
> 
> On 19 Mar 2022, at 21:24, Chris  wrote:
>> 
>>> On 2022-03-18 09:08, Ed Maste wrote:
>>> ISA sound cards have been obsolete for more than a decade, and it is
>>> (past) time to retire their drivers. This includes the following
>>> drivers/devices:
>>> snd_ad1816  Analog Devices AD1816 SoundPort
>>> snd_ess Ensoniq ESS
>>> snd_guscGravis UltraSound
>>> snd_mss Microsoft Sound System
>>> snd_sbc Creative Sound Blaster
>>> I have a review open to add deprecation notices:
>>> https://reviews.freebsd.org/D34604
>>> I expect to commit this in the near future, then MFC to stable
>>> branches and remove these drivers from main. Please follow up if
>>> there's a reason we should postpone the removal of any of these
>>> drivers.
>> This only hurts from a nostalgic perspective. Those GUS cards were 
>> incredible!
>> I have a board running freebsd that has 2 GUS cards in it running
> 
> Exactly my reaction.  You can tell you’re old when drivers are removed from 
> the tree for mainstream hardware that you never owned but wished that you 
> could afford.
> 

I’ll never give away my GUS classic/GF1 with full 1MB onboard RAM(!). It was 
too much fun to program and tracker/demo support was superb. Plus, red PCBs 
felt really 1337 back then.

That said (and assuming it still works), it's unlikely I would use it with 
anything else but DOS these days.

Cheers
Michael

Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[Michael Gmelin]

On Mon, 28 Feb 2022 16:15:45 +0100
FreeBSD User  wrote:

> Hello folks,
> 
> we run at least two poudriere build systems on recent CURRENT boxes
> and one of these poudriere build systems is working within a jail -
> setup via FreeBSD's /etc/jail.conf and by misusing the port ezjail
> for copying/deploying our self-compiled jail binary. The poudriere
> jail uses ZFS and is, to make it short, working like a charme.
> 
> Now we try to setup another poudriere, but this time the base is
> XigmaNAS 12.3.0.4/9009, which is based upon 12.X-RELENG, utilizing
> "bastille". Bastille is up to date (in terms od the XigmaNAS plugin).
> 
> Following the setup we used on the native CURRENT "jailed poudriere"
> builder and also following this reference (for those who want to
> check on this)
> 
> https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
> 
> which seems quite recent and with the exception, that we use "vnet"
> on all of our systems for jails and so does XigmaNAS.
> 
> Starting a building process via poudriere ends up with
> 
> 
> # poudriere bulk -p head -z default -j 123-amd64 -f
> /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating
> the reference jail... done [00:00:01] Mounting system devices for
> 123-amd64-head-default [00:00:01] Warning: Using packages from
> previously failed, or uncommitted, build:
> /mnt/poudriere/data/packages/123-amd64-head-default/.building
> [00:00:01] Mounting ports from: /mnt/poudriere/ports/head [00:00:01]
> Mounting packages from:
> /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01]
> Mounting distfiles from: /mnt/poudriere/ports/distfiles [00:00:01]
> Copying /var/db/ports from:
> /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02]
> Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
> /etc/resolv.conf ->
> /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf
> [00:00:02] Starting jail 123-amd64-head-default jail: jail_set:
> Operation not permitted [00:00:02] Cleaning up [00:00:02] Unmounting
> file systems
> 
> poudriere jail -l:
> 
> # poudriere jail -l
> JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> 123-amd64 12.3-RELEASE amd64
> url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
> url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> 14:11:32 /mnt/poudriere/jails/130-amd64
> 
> The jail.conf for this specific jail is as follows:
> 
> [...]
> pulverfass-001 {
> devfs_ruleset = 13;
> enforce_statfs = 1;
> exec.clean;
> exec.consolelog =
> /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start
> = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown';
> host.hostname = X;
> mount.devfs;
> mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> securelevel = 0;
> 
> vnet;
> vnet.interface = e0b_bastille4;
> exec.prestart += "jib addm bastille4 igb0";
> exec.prestart += "ifconfig e0a_bastille4 description \"vnet host
> interface for Bastille jail pulverfass-001\""; exec.poststop += "jib
> destroy bastille4";
> 
> allow.mount;
> allow.mount.fdescfs;
> allow.mount.devfs;
> allow.mount.tmpfs;
> allow.mount.nullfs;
> allow.mount.procfs;
> allow.mount.linsysfs;
> allow.mount.linprocfs;
> allow.mount.zfs;
> 
> allow.chflags;
> allow.raw_sockets;
> allow.socket_af;
> allow.sysvipc;
> 
> linux = new;
> 
> exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> exec.start += "/sbin/zfs mount -a";
> exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
> 
> }
> [...]
> 
> Tracking the execution of the build process by issuing
> 
> poudriere -x bulk ...
> 
> and examin the resulting trace doesn' tgive me any hint, the error
> reported above immediately occurs when the jail is about to be
> started:
> 
> + set -u +x
> + jail -c persist 'name=123-amd64-head-default'
> 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref'
> 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1'
> 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation
> not permitted
> + exit_handler
> [...]
> 
> Searching the net revealed some issues with setting IP4 and IP6 in
> poudriere, but those findings are dated back to 2017 and 2014 and I
> guess this is solved right now.
> 
> The difference between our manually jail.conf driven setup and the
> XigmaNAS/bastille based one is, bastille uses jib/netgraph 

Re: Problems compiling kernel

[Michael Gmelin]

This should have been resolved today in 
https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415

-m

> On 30. Dec 2021, at 20:17, tue...@freebsd.org wrote:
> Dear all,
> 
> on a system updated yesterday I get
> 
> tuexen@head:~/freebsd-src % git branch
> * main
> tuexen@head:~/freebsd-src % git pull
> Already up to date.
> tuexen@head:~/freebsd-src % uname -a
> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: 
> Thu Dec 30 11:33:16 CET 2021 
> root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP  amd64
> tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP
> ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc"
> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: 
> warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status
> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: 
> Unable to determine compiler type for CC=cc.  Consider setting COMPILER_TYPE.
> 
> make: stopped in /usr/home/tuexen/freebsd-src
> tuexen@head:~/freebsd-src % 
> 
> any idea what I did wrong and how to fix it?
> 
> Thanks for any hints.
> 
> Best regards
> Michael

Re: 14-current: unable to boot after upgrade (installworld)

[Michael Gmelin]

> On 10. Dec 2021, at 16:57, Chris  wrote:
> 
> On 2021-12-09 05:36, Sergey V. Dyatko wrote:
>> Hi,
>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
>> 14-current from git,it looked like this:
>> 1) git pull https://git.freebsd.org/src.git /usr/src
>> 2) cd /usr/src ; make buildworld; make kernel
> Not sure you didn't actually do this. But it appears that you omitted a:
> make install kernel
> here.

`make kernel` does buildkernel and installkernel.

-m


>> 3) shutdown -r now
>> after that I _successfully_ booted into 14-current and continued with
>> etcupdate -p
>> make installworld
>> etcupdate -B
>> shutdown -r now
>> but after that server doesn't come back. After I conneted to this server via
>> IPMI ip-kvm I saw following (sorry for external link):
>> https://i.imgur.com/jH6MHd2.png
>> Well. There was a migration to zol between r368473 and current 'main' branch 
>> so
>> I decided to install fresh 14-current from snapshot
>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid
>> possible problems
>> and again, after make kernel and reboot OS runs, but after installworld I 
>> ended up
>> in the same situation
>> thoughts ?
>> --
>> wbr, Sergey

Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al

[Michael Gmelin]

On Tue, 14 Sep 2021 09:02:46 +
Gary Jennejohn  wrote:

> On Mon, 13 Sep 2021 21:30:02 -0400
> Michael Butler via freebsd-current 
> wrote:
> 
> > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to
> > recognize any configured timezone when WITH_DETECT_TZ_CHANGES is
> > not set.
> > 
> > For example ..
> >   
> > imb@vm01:/home/imb> date
> > Tue Sep 14 01:25:57  2021
> > 
> > Every other daemon also thinks it's running in UTC+0 :-(
> > 
> > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in
> > /etc/src.conf, the output is (for me) .. 
> > imb@vm01:/usr/src/lib/libc> date
> > Mon Sep 13 21:28:29 EDT 2021
> >   
> 
> Same here.  After instaling the new world this morning I was suddenly
> in UTC instead of CEST (2 hours difference).
> 
> Thanks for the fix :-)

Before reading your message, I (ironically) wanted to tell you about
your email's date header containing the wrong timezone ^_^

-m

-- 
Michael Gmelin

Should we include ttyu* to devfs_ruleset 3 (devfsrules_unhide_login)?

[Michael Gmelin]

Hi,

There are many TTY devices in devfsrules_unhide_login=3, but ttyu*
(serial lines) are not part of it.

As a result, certain things won't work as expected when connecting over
a serial console, one example being connecting to a local bhyve vm over
serial console (e.g., `vm console myvm' when using vm-bhyve).

The example that brought this to my attention is using ssh within a
jail that's running inside of a VM, while being connected to that VM
over serial console.

So the setup is:
- FreeBSD 13 host
- bhyve vm running FreeBSD 13 on top
- Jail using mount.devfs running within the bhyve vm, using the default
  devfs_ruleset inside of the bhyve vm (which in turn loads
  devfsrules_jail=4, which includes devfsrules_unhide_login=3).

Now, ssh within that jail won't work, as /dev/tty can't be accessed.

Example (while being connected to the vm over a serial line):

# jail -c path=/ mount.devfs ip4=inherit command=ssh localhost
Host key verification failed.
jail: ssh localhost: failed

Now, adding in an extra rule to ruleset 3:

# devfs rule -s 3 add 3250 path "ttyu*" unhide

Things work as expected:

# jail -c path=/ mount.devfs ip4=inherit command=ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be
established... Are you sure you want to continue connecting
(yes/no)?

Now the question is, would it make sense to add ttyu* (or at least
ttyu0) to [devfsrules_unhide_login=3] in /etc/defaults/devfs.rules, or
are there any (security) reasons why this might be a bad idea?

Best,
Michael

-- 
Michael Gmelin

Re: awk behaviour?

[Michael Gmelin]

On Wed, 28 Jul 2021 16:02:30 -0400
Ed Maste  wrote:

> On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
>  wrote:
> >
> > What prompted the question was my (obviously poor) attempt to debug
> > and resolve this failure when attempting to build a release for
> > i386 on an amd64 ..  
> 
> This will be due to my 4e224e4be7c3. I'm not sure exactly what's
> happening yet, but I can provoke this behaviour if `${PKG_CMD}
> --version` outputs something other than a single line with the version
> number.
> 

Could it be, that the pkg binary isn't installed in $LOCALBASE/sbin/pkg,
(whatever LOCALBASE is at that point)? This would make pkg --version
shows its bootstrap message: 

  The package management tool is not yet installed on your system.
  Do you want to fetch and install it now? [y/N]: 

which could explain the behavior.

Just speculating...

-m

-- 
Michael Gmelin

Re: awk behaviour?

[Michael Gmelin]

On Wed, 28 Jul 2021 13:29:20 -0400
Michael Butler via freebsd-current  wrote:

> I tripped over this while trying to build a local release ..
> 
> imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 +
> $$2 * 100 + $$3}'
> 10001
> 
> imb@toshi:/home/imb> pkg --version  
> 1.17.1
> 
> Is this expected?

Yes, as you're using $$ instead of $.

With single dollar sign you'll get the expected value of:

11701

With double dollar you reference the content of the field, so in case
of 1.17.1:

$$1 * 1 + $$2 * 100 + $$3

is equal to

$1 * 1 + $17 + $1

Which is:
1 + 0 + 1

Which equals

10001

-m


> 
>   imb



-- 
Michael Gmelin

Re: EFI boot partition overwritten

[Michael Gmelin]

> On 16. Jul 2021, at 19:38, Warner Losh  wrote:
> 
> On Fri, Jul 16, 2021 at 6:14 AM Thomas Laus  wrote:
> 
>> Group:
>> 
>> This is an issue for more than just CURRENT.  The 'usr/src/UPDATING'
>> file has the instructions for updating the ZFS bootblocks but not the
>> EFI partition.  I recently upgraded a RELEASE-12.2 to RELEASE-13.0.  The
>> freebsd-update procedure did not upgrade the ZFS bootblocks.  I forgot
>> that this PC was UEFI only and overwrote the first partition with the
>> gptzfsboot code.  That made my system un-bootable.  I found the recovery
>> procedure on one of the FreeBSD forums and was able to reformat the EFI
>> MSDOS partition, create the proper directory structure, and copy the
>> loader.efi file to the correct location and filename using the Live
>> Filesystem running on the installation CD.
>> 
>> I searched the man pages and the UPDATING file for instructions but came
>> up empty and had to resort to finding the answer on one of the forums.
>> The filenames have changed since FreeBSD first supported EFI and some of
>> the forum instructions are out of date.  My problem must be fairly
>> common and the recovery procedure should be in a man page with a
>> footnote or man reference somewhere on the install media.
>> 
>> Since CURRENT receives more updates to the EFI boot loader than the
>> release versions, there should be instructions in the CURRENT
>> 'usr/src/UPDATING' file on how to update the EFI bootcode.
>> 
> 
> There should be. Yes. Last time I went hunting for a place to shoe-horn it
> in, I got distracted by something else.
> 
> The instructions are relatively straight forward. I'm writing them here for
> your benefit, and also in case someone wants to send me a diff/pull request
> to include them. Or better yet, put this in the handbook and we can
> reference
> a location from there.
> 
> WARNING: This is a quick run-through of how to do this if you need to.
> The example commands given might not be exactly right for all installations
> as differing numbers of partitions will change the '-i' parameters.
> 
> Frist, you need a partition that's of the right type. For GPT that type is
> `efi`
> as shown in `gpart show ` eg
> # gpart show ada0
> =>40  2000409184  ada0  GPT  (954G)
>  401600- free -  (800K)
>1640  1992292792 2  freebsd-ufs  (950G)
>  1992294432 700 3  freebsd-swap  (3.3G)
>  1999294432 1114792 4  efi  (544M)
> 
> If you don't have one, you'll need to create one. In the above exmaple,
> I had installed the system with a tiny partition for booting with legacy
> BIOS, but then moved to booting with UEFI. I did this by turning off
> swapping and doing the following:
> # gpart resize -i 3 -s 700 ada0
> I then created a new efi partition:
> # gpart add -t efi ada0
> and I let it autosize.
> 
> Next, I needed a FAT32 filesystem on that device. FAT16 usually will
> work and often FAT12, but there are known examples of system integrators
> that omit support for these last two (more the latter than the former since
> it's viewed as a floppy only thing, and who uses floppies).  I just used
> newfs_msdos and mounted it:
> # newfs_msdos -F 32 /dev/ada0p4
> # mount -t msdos /dev/ada0p4 /boot/efi
> 
> Next, you need to put a bootloader on the system. Unless you have
> special needs, loader.efi is that loader.
> # mkdir -p /boot/efi/efi/boot
> # cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
> 
> If you are using efibootmgr to set a location to boot from, generally people
> create a freebsd directory (we've registered /efi/freebsd with the proper
> folks
> to avoid conflicts):
> # mkdir -p /boot/efi/efi/freebsd
> # cp /boot/loader.efi /boot/efi/efi/freebsd
> # efibootmgr -c -a -k /boot/kernel/kernel -l
> /boot/efi/efi/freebsd/loader.efi -L "FreeBSD Boot"
> though some vendors impose limits on how many boot envs you can create
> and some do not allow any at all.
> 

It would be cool to also update the loader.efi man page to be a bit more useful 
(this is what 'zpool upgrade' refers to/will refer to in the future).

-m

> Warner

Re: PATH: /usr/local before or after /usr ?

[Michael Gmelin]

On Fri, 16 Jul 2021 09:01:49 -0600
Alan Somers  wrote:

> FreeBSD has always placed /usr/local/X after /usr/X in the default
> PATH. AFAICT that convention began with SVN revision 37 "Initial
> import of 386BSD 0.1 othersrc/etc".  Why is that?  It would make
> sense to me that /usr/local/X should come first.  That way programs
> installed from ports can override FreeBSD's defaults.

I think that is exactly what you don't want to happen by default
(imagine all the ways the system could fall apart in a really hard to
support ways if individual standard tools from base are overridden -
especially as many users might not even notice, as it might be a
side-effect of installing some dependency of something they need).

Users are always free to tweak PATH for their purposes of course, but
running the UNIX tools that came with the OS by default makes a lot
of sense to me.

-m

>  Is there a
> good reason for this convention, or is it just inertia?
> -Alan



-- 
Michael Gmelin

Re: 14-CURRENT: www/nextcloud: php occ/web access : Segmentation fault

[Michael Gmelin]

On Wed, 30 Jun 2021 20:05:43 +0200
"O. Hartmann"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Mon, 28 Jun 2021 23:34:44 +0200
> Michael Gmelin  schrieb:
> 
> > > On 28. Jun 2021, at 22:41, O. Hartmann 
> > > wrote:
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > 
> > > Hello,
> > > 
> > > we ran into serious trouble here with an www/nextcloud
> > > installation on a recent 14-CURRENT (FreeBSD 14.0-CURRENT #23
> > > main-n247612-e6dd0e2e8d4: Mon Jun 28 18:08:20 CEST 2021 amd64).
> > > Ports tree is up to date and ports are built via traditional
> > > "make". Port www/nextcloud, all mod_ ports and even every php-*
> > > port (php74 is installed and default) has been recompiled within
> > > the last two weeks via "portmaster -f".
> > > 
> > > The phenomenon occured back a couple of weeks, when access from
> > > the web via cjromoum and/or firefox reported out of the sudden
> > > "Secure Connection Failed". I checked the Apache 2.4 server's
> > > certificate (self signed,never had been an issue so far), but
> > > there seems no issue to exist. It got very strange when I tried
> > > to perfom an upgrade and/or check via
> > > 
> > > cd /usr/local/www/nextcloud
> > > su -m -c "/usr/local/bin/php ./occ upgrade"
> > > 
> > > Whenever I access occ, I receive an @"Segmentation fault".
> > > The I checked the server's error log and I found for each access
> > > of the nextcloud instance an entry like
> > > 
> > > [Tue Jun 01 06:04:40.667026 2021] [core:notice] [pid 81123:tid
> > > 34374492160] AH00052: child pid 24598 exit signal Segmentation
> > > fault (11)
> > > 
> > > Well, I'm out of ideas, it seems nextcloud, php or apache ar all
> > > in combination do have a serious problem hard to come by with
> > > 14-CURRENT (another instance running on 12.2-RELENG doesn't have
> > > any issues).
> > > 
> > > Can someone hint me to what to do track this nasty error?
> > > 
> > > Thanks in advance,
> > > 
> > 
> > Do you have a minimal setup to reproduce? Could you try building
> > all ports against OpenSSL from ports?
> > 
> > -m
> > 
> > 
> >   
> > > oh
> > > 
> > > - -- 
> > > O. Hartmann
> > > 
> > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> > > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs.
> > > 4 BDSG). -BEGIN PGP SIGNATURE-
> > > 
> > > iHUEARYKAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYNozlwAKCRA4N1ZZPba5
> > > Rx2nAPwNf9014LCwIKdjN1lxdiESP0daa97tqvFsZiOM8OgpmAD+M6pmqlCVG6TE
> > > HyuCprAwjwvP9zxov3BDaVmJRI3ZpAw=
> > > =z4d+
> > > -END PGP SIGNATURE-
> > 
> >   
> 
> I had already filed a PR regarding this probleme, here is the link:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256844
> 
> Building all ports against OpenSSL from ports would exceed the
> capabilities of my hosts, the box in question is under load and an
> older Ivy-Bridge XEON with limited speed, so that would take days. I
> hoped the problem could be isolated otherwise ...

I found this issue on the nextcloud issue tracker:
https://github.com/nextcloud/server/issues/25761

Based on that, you should enable apcu for php CLI by adding this
to your php.ini:

  apc.enable_cli=1

which should fix `occ upgrade'.

No idea if it works, but it sounds similar enough to give it a shot.

Cheers
Michael

p.s. see also https://www.php.net/manual/en/apcu.configuration.php


> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4
> BDSG). -BEGIN PGP SIGNATURE-
> 
> iHUEARYKAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYNyykgAKCRA4N1ZZPba5
> R68PAPwIioYhbPZ4DXLbJXKsWuAYUr9oZRgwMiTqhpqqwBIwCgEAwmcxE/ZpQ3Og
> 0mXO2DBqBNv+RAFQ7U/3qSnOlKeAdgQ=
> =0VYB
> -END PGP SIGNATURE-



-- 
Michael Gmelin

Re: 14-CURRENT: www/nextcloud: php occ/web access : Segmentation fault

[Michael Gmelin]

> On 28. Jun 2021, at 22:41, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 
> Hello,
> 
> we ran into serious trouble here with an www/nextcloud installation on a 
> recent 14-CURRENT
> (FreeBSD 14.0-CURRENT #23 main-n247612-e6dd0e2e8d4: Mon Jun 28 18:08:20 CEST 
> 2021 amd64).
> Ports tree is up to date and ports are built via traditional "make". Port 
> www/nextcloud, all
> mod_ ports and even every php-* port (php74 is installed and default) has 
> been recompiled
> within the last two weeks via "portmaster -f".
> 
> The phenomenon occured back a couple of weeks, when access from the web via 
> cjromoum and/or
> firefox reported out of the sudden "Secure Connection Failed". I checked the 
> Apache
> 2.4 server's certificate (self signed,never had been an issue so far), but 
> there seems no
> issue to exist.
> It got very strange when I tried to perfom an upgrade and/or check via
> 
> cd /usr/local/www/nextcloud
> su -m -c "/usr/local/bin/php ./occ upgrade"
> 
> Whenever I access occ, I receive an @"Segmentation fault".
> The I checked the server's error log and I found for each access of the 
> nextcloud instance an
> entry like
> 
> [Tue Jun 01 06:04:40.667026 2021] [core:notice] [pid 81123:tid 34374492160] 
> AH00052: child pid
> 24598 exit signal Segmentation fault (11)
> 
> Well, I'm out of ideas, it seems nextcloud, php or apache ar all in 
> combination do have a
> serious problem hard to come by with 14-CURRENT (another instance running on 
> 12.2-RELENG
> doesn't have any issues).
> 
> Can someone hint me to what to do track this nasty error?
> 
> Thanks in advance,
> 

Do you have a minimal setup to reproduce? Could you try building all ports 
against OpenSSL from ports?

-m



> oh
> 
> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYKAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYNozlwAKCRA4N1ZZPba5
> Rx2nAPwNf9014LCwIKdjN1lxdiESP0daa97tqvFsZiOM8OgpmAD+M6pmqlCVG6TE
> HyuCprAwjwvP9zxov3BDaVmJRI3ZpAw=
> =z4d+
> -END PGP SIGNATURE-

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

[Michael Gmelin]

> On 13. Jun 2021, at 20:50, Ronald Klop  wrote:
> 
> What do you have configured as prompt? Or shell startup script?
> Does it contain a call to git? 
> 

I agree that this smells like a prompt that calls "git status" or something 
similar (when on the FreeBSD source tree on an rpi, 15 seconds feels about 
right for performing such a call).

-m

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

Re: Files in /etc containing empty VCSId header

[Michael Gmelin]

> On 11. Jun 2021, at 00:42, Cameron Katri via freebsd-current 
>  wrote:
> 
> On 6/10/21 6:26 PM, Kevin Oberman wrote:
>> I have never seen it return anything from /usr/src.
> 
> It seems to return stuff from /usr/src for me
> > whereis cc
> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz 
> /usr/src/contrib/netbsd-tests/usr.bin/cc
> 
> Although I question the validity of that response. But other times it works 
> fine.
> 

Again, (among other ways) it does so using locate, see 
https://lists.freebsd.org/archives/freebsd-current/2021-June/000193.html

-m


> > whereis whereis
> whereis: /usr/bin/whereis /usr/share/man/man1/whereis.1.gz 
> /usr/src/usr.bin/whereis
> 
>>> whereis cc
>> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
>>> whereis postfix
>> postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
>> /usr/ports/mail/postfix
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> - Cameron Katri

Re: Files in /etc containing empty VCSId header

[Michael Gmelin]

> On 11. Jun 2021, at 00:28, Kevin Oberman  wrote:
> 
> On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:
> 
>> 
>> 
>>>> On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
>>> 
>>> On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
>>>>> On Tue, 8 Jun 2021 09:41:34 +
>>>>> Mark Linimon  wrote:
>>>>> 
>>>>>> On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
>>>>>>> Sometimes it's a real interesting exercise to figure out where
>>>>>>> a
>>>>>>> file on your runtime system comes from in the source world.
>>>> 
>>>> There is a command for that which does or use to do a pretty
>>>> decent job of it called whereis(1).
>>>> 
>>> 
>>> revolution > whereis ntp.conf
>>> ntp.conf:
>>> revolution > whereis netif
>>> netif:
>> 
>> That line might make it to a shirt one day:
>> 
>>> revolution > whereis services
>> 
>> ;)
>> Michael
>> 
> Just to clarify for those not willing or able to RTFM, it only works for
> executables, not conf files or libraries. It reports the location of the
> executable, the man page and the port location, if it is a port. For those
> who did RTFM, it is wrong. It claims that it reports on the location of the
> source, but that is not the case as far as I know. I have never seen it
> return anything from /usr/src.

I have, just earlier today. Like I wrote somewhere else in this thread, it does 
so by using locate (it’s debatable how useful this really is though).

-m


>> whereis cc
> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
>> whereis postfix
> postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
> /usr/ports/mail/postfix
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: Files in /etc containing empty VCSId header

[Michael Gmelin]

On Wed, 09 Jun 2021 08:23:20 -0600
Ian Lepore  wrote:

> On Wed, 2021-06-09 at 18:54 +1000, Peter Jeremy via freebsd-current
> wrote:
> > On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:  
> > > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:  
> > > > There is a command for that which does or use to do a pretty
> > > > decent job of it called whereis(1).  
> > 
> > Thanks.  That looks useful.
> >   
> > > revolution > whereis ntp.conf
> > > ntp.conf:
> > > revolution > whereis netif
> > > netif:
> > > revolution > whereis services
> > > services:
> > > 
> > > So how does that help me locate the origin of these files in the
> > > source
> > > tree?  
> > 
> > It works for me™:
> > server% whereis ntp.conf
> > ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
> > server% whereis netif   
> > netif: /usr/src/libexec/rc/rc.d/netif
> > server% whereis services
> > services: /usr/src/contrib/unbound/services
> > 
> > Is your source tree somewhere other than /usr/src?
> >   
> 
> My /usr/src is a symlink to the actual source tree on a different
> filesystem (but it is the source tree the running system was built
> from).  It seems odd that that would make whereis(1) not work.
> 

whereis(1) falls back to using "locate" if it can't find the sources
directly, so e.g., in case of `whereis -s ls', it will get through the
results of `locate '*'/ls` and see if they match "^/usr/src" (or
whatever you gave as source dir using -S).

Therefore if

  locate '*'/ntp.conf | grep "^/usr/src"

gives you a result, then `whereis -s ntp.conf' will too.

See also
https://cgit.freebsd.org/src/tree/usr.bin/whereis/whereis.c#n607

Michael

(re-sent, as the previous mail bounced from the list)

-- 
Michael Gmelin

Re: OpenZFS Encryption: Docs, and re Metadata Leaks

[Michael Gmelin]

> On 9. Jun 2021, at 04:17, grarpamp  wrote:
> 
> On 4/17/20, Ryan Moeller  wrote:
>> 
 On Apr 17, 2020, at 4:56 PM, Pete Wright  wrote:
>>> 
>>> On 4/17/20 11:35 AM, Ryan Moeller wrote:
 OpenZFS brings many exciting features to FreeBSD, including:
 * native encryption
>>> Is there a good doc reference on available for using this?  I believe this
>>> is zfs filesystem level encryption and not a replacement for our existing
>>> full-disk-encryption scheme that currently works?
>> 

I found this to be a useful starting point:

https://blog.heckel.io/2017/01/08/zfs-encryption-openzfs-zfs-on-linux/#What-s-encrypted

-m


>> I’m not aware of a good current doc for this. If anyone finds/writes
>> something, please post it!
>> There are some old resources you can find with a quick search that do a
>> pretty good job of covering the basic ideas, but I think the exact syntax of
>> commands may be slightly changed in the final implementation.
>> 
>> The encryption is performed at a filesystem level (per-dataset).
> 
> 
> You could find some initial doc and video about zfs encryption
> on openzfs.org and youtube, and in some commit logs.
> Therein was mentioned...
> 
> People are needed to volunteer to expand documentation on the
> zfs crypto subject further in some document committed to openzfs
> repo since users and orgs will want to know it when considering use.
> Volunteers are also sought by openzfs to review the crypto itself.
> 
> Maybe there was already some central place made with further
> current documentation about the zfs encryption topics since then?
> 
> https://www.youtube.com/watch?v=frnLiXclAMo openzfs encryption
> https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view
> https://www.youtube.com/watch?v=kFuo5bDj8C0 openzfs encryption cloud
> https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view
> 
> It's dataset level, so GELI or GBDE etc are needed for full coverage,
> perhaps even those two may not have yet received much or formal
> review either, so there is always good volunteer opportunity there
> to start with review of a potentially simpler cryptosystem like those.
> 
> zfs list, dataset snapshot names properties etc not covered.
> 
> zfs history not covered, many sensitive strings will end up in
> there, including cutpaste password typos into commandline,
> usernames, timestamps, etc...
> and no tool exist to scrub overwrite history extents with random data,
> and no option exists to turn keeping of
> 'user initiated events' or 'long format' off,
> and ultimately no option exists to tell zpool create to
> disable history keeping from the very start entirely.
> So maybe users have to zero disks and pools along
> with it just to scrub that.
> 
> zfs also exposes these variety of path and device names,
> timestamps, etc in cleartext on disk structures in various
> places, including configuration cachefile...
> Some of those could could be NULLed or dummied
> with new zpool create options for more security
> restricted use cases.
> 
> There are other meta things and tools left exposed
> such as potentially any plaintext meta in send/recv.
> 
> Another big metadata leak for environments and users that
> ship, sell, embed, clone, distribute, fileshare, and backup,
> their raw disks pools and usbs around to untrusted third parties...
> is that zfs also puts hostnames and UUID type of unique
> static meta and identifying things in cleartext on disk.
> zfs thus needs options to allow users to set and use a NULL,
> or generic dummy default, or random string, or chosen,
> "hostname" for those from the very first zpool create command.
> 
> Most applications users use, including zfs, can today
> consider ways in which metadata leaks could be removed
> entirely, or at least optioned out for use under
> high security restricted environments modes.
> That could even involve considering trading off some
> extra features not actually required for a basic mode
> of functionality of the app.
> 
> 
> 
> (cc's for fyi inclusion about leaks, and as lists still haven't
> been configured to support discreet bcc for that purpose,
> which would also maintain nice headers for thread following.
> Gmail breaks threads. zfsonlinux topicbox peole can't subscribe
> without javabloatbroken website, so someone could forward
> this there. Drop non-relevant cc's from further replies.
> Parent thread from freebsd current and stable lists was
> Subject: OpenZFS port updated)

Re: Files in /etc containing empty VCSId header

[Michael Gmelin]

> On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> 
> On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
>>> On Tue, 8 Jun 2021 09:41:34 +
>>> Mark Linimon  wrote:
>>> 
 On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> Sometimes it's a real interesting exercise to figure out where
> a
> file on your runtime system comes from in the source world.  
>> 
>> There is a command for that which does or use to do a pretty
>> decent job of it called whereis(1).
>> 
> 
> revolution > whereis ntp.conf
> ntp.conf:
> revolution > whereis netif
> netif:

That line might make it to a shirt one day:

> revolution > whereis services

;)
Michael

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

[Michael Gmelin]

On Thu, 3 Jun 2021 15:09:06 +0200
Michael Gmelin  wrote:

> On Tue, 1 Jun 2021 13:47:47 +0200
> Michael Gmelin  wrote:
> 
> > Hi,
> > 
> > Since upgrading servers from 12.2 to 13.0, I get
> > 
> >   Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe
> > 
> > consistently, usually after about 11 idle minutes, that's with and
> > without pf enabled. Client (11.4 in a VM) wasn't altered.
> > 
> > Verbose logging (client and server side) doesn't show anything
> > special when the connection breaks. In the past, QoS problems
> > caused these disconnects, but I didn't see anything apparent
> > changing between 12.2 and 13 in this respect.
> > 
> > I did a test on a newly commissioned server to rule out other
> > factors (so, same client connections, some routes, same
> > everything). On 12.2 before the update: Connection stays open for
> > hours. After the update (same server): connections breaks
> > consistently after < 15 minutes (this is with unaltered
> > configurations, no *AliveInterval configured on either side of the
> > connection). 
> 
> I did a little bit more testing and realized that the problem goes
> away when I disable "Proportional Rate Reduction per RFC 6937" on the
> server side:
> 
>   sysctl net.inet.tcp.do_prr=0
> 
> Keeping it on and enabling net.inet.tcp.do_prr_conservative doesn't
> fix the problem.
> 
> This seems to be specific to Parallels. After some more digging, I
> realized that Parallels Desktop's NAT daemon (prl_naptd) handles
> keep-alive between the VM and the external server on its own. There is
> no direct communication between the client and the server. This means:
> 
> - The NAT daemon starts sending keep-alive packages right away (not
>   after the VM's net.inet.tcp.keepidle), every 75 seconds.
> - Keep-alive packages originating in the VM never reach the server.
> - Keep-alive originating on the server never reaches the VM.
> - Client and server basically do keep-alive with the nat daemon, not
>   with each other.
> 
> It also seems like Parallels is filtering the tos field (so it's
> always 0x00), but that's unrelated.
> 
> I configured a bhyve VM running FreeBSD 11.4 on a separate laptop on
> the same network for comparison and is has no such issues.
> 
> Looking at TCP dump output on the server, this is what a keep-alive
> package sent by Parallels looks like:
> 
>   10:14:42.449681 IP (tos 0x0, ttl 64, id 15689, offset 0, flags
> [none], proto TCP (6), length 40)
> 192.168.1.1.58222 > 192.168.1.2.22: Flags [.], cksum x (correct),
> seq 2534, ack 3851, win 4096, length 0
> 
> While those originating from the bhyve VM (after lowering
> net.inet.tcp.keepidle) look like this:
> 
>   12:18:43.105460 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF],
> proto TCP (6), length 52)
> 192.168.1.3.57555 > 192.168.1.2.22: Flags [.], cksum x
> (correct), seq 1780337696, ack 45831723, win 1026, options
> [nop,nop,TS val 3003646737 ecr 3331923346], length 0
> 
> Like written above, once net.inet.tcp.do_prr is disabled, keepalive
> seems to be working just fine. Otherwise, Parallel's NAT daemon kills
> the connection, as its keep-alive requests are not answered (well,
> that's what I think is happening):
> 
>   10:19:43.614803 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
> proto TCP (6), length 40)
> 192.168.1.1.58222 > 192.168.1.2.22: Flags [R.], cksum x (correct),
> seq 2535, ack 3851, win 4096, length 0
> 
> The easiest way to work around the problem Client side is to configure
> ServerAliveInterval in ~/.ssh/config in the Client VM.
> 
> I'm curious though if this is basically a Parallels problem that has
> only been exposed by PRR being more correct (which is what I suspect),
> or if this is actually a FreeBSD problem.
> 

So, PRR probably was a red herring and the real reason that's happening
is that FreeBSD (since version 13[0]) by default discards packets
without timestamps for connections that formally had negotiated to have
them. This new behavior seems to be in line with RFC 7323, section
3.2[1]:

"Once TSopt has been successfully negotiated, that is both  and
 contain TSopt, the TSopt MUST be sent in every non-
segment for the duration of the connection, and SHOULD be sent in an
 segment (see Section 5.2 for details)."

As it turns out, macOS does exactly this - send keep-alive packets
without a timestamp for connections that were negotiated to have them.

Under normal circumstances - ssh from macOS to a server running FreeBSD
13 - this won't be noticed, since macOS uses the same default settings
as FreeBSD (2 hours idle time, 75 seconds intervals), so 

Re: What happen to mailing list archives?

[Michael Gmelin]

On Mon, 7 Jun 2021 22:35:20 +0200
Baptiste Daroussin  wrote:

> On Mon, Jun 07, 2021 at 12:30:46AM -0700, Mark Millard wrote:
> > On 2021-Jun-6, at 13:25, Mark Millard  wrote:
> >   
> > > Baptiste Daroussin  wrote on
> > > Date: Sun, 6 Jun 2021 10:53:49 +0200 :
> > >   
> > >> What has happended:
> > >> plan A: we migrated everything off mailman/pipermail seamlessly
> > >> with redirection and so on. We patched the new archiver to
> > >> produce the same file names has pipermail
> > >> 
> > >> Plan A worked fine up to a limit, there was plenty of hand
> > >> edition in the past, we we decided to move to plan B which is
> > >> what is happening now.
> > >> 
> > >> Plan B: We keep a frozen version of the archives up to the
> > >> migration date under the pipermail directory and have the new
> > >> archives created in the archives directory.
> > >> 
> > >> All the pipermail archives have been restored as they were. The
> > >> new archives receives in their index a new link to point people
> > >> to the pipermails archive if looking for older archives.
> > >> 
> > >> this has been done a couple of hours ago (before Steve emails)
> > >> during a window, of ~ 10 hours, the mailing lists which slow
> > >> traffic aka the one which didn't received any email since the
> > >> migration ended up with an empty "archives" directory (aka a
> > >> 404), a file with explanation and redirection to pipermail has
> > >> been installed there.
> > >> 
> > >> Some work is still needed for the mailing lists which has been
> > >> transformed as readonly, this will be done in the next couple of
> > >> days  
> > > 
> > > It is too bad that a reference to a "no examples yet"
> > > month, such as, (at the time I write this):
> > > 
> > > https://lists.freebsd.org/archives/freebsd-toolchain/2021-June/date.html
> > > 
> > > does not show at least (Date view specific example):
> > > 
> > >   • Other periods:[ Previous, Date view ] [ List of Folders
> > > ]
> > >   • Other: [ Actives mailing lists ] [ Archives from
> > > mailman's time ]
> > > 
> > > when there are prior months available in
> > > https://lists.freebsd.org/archives/ or show at least just:
> > > 
> > >   • Other: [ Actives mailing lists ] [ Archives from
> > > mailman's time ]
> > > 
> > > when no prior months are available there.
> > >   
> > 
> > Looks like there are missing months.
> > 
> > Using freebsd-hackers as an example:
> > 
> > https://lists.freebsd.org/archives/freebsd-hackers/index.html
> > shows the oldest month being "May 2021".
> > 
> > But . . .
> > 
> > https://lists.freebsd.org/pipermail/freebsd-hackers/
> > shows the most recent month being "September 2020".
> > 
> > So: 2020-Oct through 2021-Apr are completely missing.
> > 
> > Then, going for more detail for 2020-Sep and 2021-May . . .
> > 
> > https://lists.freebsd.org/archives/freebsd-hackers/2021-May/date.html
> > shows "Starting Tue May 18 2021 - 21:07:44 UTC".
> > 
> > https://lists.freebsd.org/pipermail/freebsd-hackers/2020-September/date.html
> > shows "Ending: Tue Sep 15 14:12:20 UTC 2020".
> > 
> > So there are about 2 more half-months missing.
> > 
> > Some other lists have other date ranges, some similar,
> > some not.  
> 
> This missing month are being populated right now

Will historic links still work though (so that old references work and
current google results are ok)?

Just stumbled over this one:
https://lists.freebsd.org/archives/freebsd-jail/2017-March/003360.html

Cheers
Michael

> 
> Best regards,
> Bapt



-- 
Michael Gmelin

Re: What happen to mailing list archives?

[Michael Gmelin]

> On 6. Jun 2021, at 01:44, Warner Losh  wrote:
> 
> 
> 
> 
>> On Sat, Jun 5, 2021, 5:29 PM Steve Kargl  
>> wrote:
>> On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote:
>> > 
>> > p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click 
>> > FreeBSD-net and then "Archives from mailman’s time", you get to a list 
>> > that brings you to https://lists.freebsd.org/pipermail/freebsd-net/. So 
>> > the old archives are still reachable that way. (I still find the 
>> > docs.FreeBSD.org/mail page to be confusing).
>> > 
>> > 
>> 
>> There isn't an "Archives from mailman's time" link on freebsd-numerics.
>> 
>> Hundreds of emails from me are now gone or sufficiently hidden that
>> I cannot find them.  More importantly, Bruce Evans often replied
>> with reviews of libm patch's I sent the list.  Those reviews and
>> his detailed analysis of the libm code are now gone or sufficiently
>> hidded that I cannot find them.
> 
> 
> 
> Bapt was working on this stuff today. He said something about the archive 
> regenerating with the new software on IRC.. 
> 

In the meantime, maybe this helps:

https://lists.freebsd.org/pipermail/freebsd-numerics/


> Warner 

Re: What happen to mailing list archives?

[Michael Gmelin]

> On 6. Jun 2021, at 01:00, Michael Gmelin  wrote:
> 
> 
> 
> 
>>> On 6. Jun 2021, at 00:53, Steve Kargl  
>>> wrote:
>>> 
>> It seems someone has tried to migrate the mailing list archives
>> from mailman to some new fangle code.  This has broken the archives
>> for at least freebsd-numerics@, freebsd-office@, freebsd-net@
>> 
>> As a comparison, simply go to
>> 
>> https://lists.freebsd.org/mailman/listinfo
>> 
>> and follow the links to freebsd-numerics and freebsd-toolchain.
>> 
>> Can this be fixed?
>> 
> 
> New archives are here:
> https://lists.freebsd.org/archives/
> 
> e.g., https://lists.freebsd.org/archives/freebsd-net/2021-June/index.html
> 
> As we still have mailman archives and https://docs.freebsd.org/mail/, merging 
> or cross linking would certainly be useful.
> 
> Michael
> 

p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click FreeBSD-net 
and then "Archives from mailman’s time", you get to a list that brings you to 
https://lists.freebsd.org/pipermail/freebsd-net/. So the old archives are still 
reachable that way. (I still find the docs.FreeBSD.org/mail page to be 
confusing).




> 
>> -- 
>> Steve

Re: What happen to mailing list archives?

[Michael Gmelin]

> On 6. Jun 2021, at 00:53, Steve Kargl  
> wrote:
> 
> It seems someone has tried to migrate the mailing list archives
> from mailman to some new fangle code.  This has broken the archives
> for at least freebsd-numerics@, freebsd-office@, freebsd-net@
> 
> As a comparison, simply go to
> 
> https://lists.freebsd.org/mailman/listinfo
> 
> and follow the links to freebsd-numerics and freebsd-toolchain.
> 
> Can this be fixed?
> 

New archives are here:
https://lists.freebsd.org/archives/

e.g., https://lists.freebsd.org/archives/freebsd-net/2021-June/index.html

As we still have mailman archives and https://docs.freebsd.org/mail/, merging 
or cross linking would certainly be useful.

Michael


> -- 
> Steve

Re: zpool upgrade and bootcode on 13-RELEASE

[Michael Gmelin]

On Fri, 28 May 2021 20:50:52 +0200
Michael Gmelin  wrote:

> On Fri, 28 May 2021 20:37:14 +0200
> Mathieu Arnold  wrote:
> 
> > On Wed, May 19, 2021 at 07:32:43PM +0200, Michael Gmelin wrote:  
> > > 
> > > 
> > > On Wed, 19 May 2021 19:09:06 +0200
> > > Kurt Jaeger  wrote:
> > > 
> > > > Hi!
> > > > 
> > > > > Does this mean, re-installing the bootcode isn't necessary
> > > > > anymore
> > > > > - or has the warning been removed by accident/as a side effect
> > > > > of merging with OpenZFS?  
> > > > 
> > > > On the contrary, because of the switch from FreeBSD ZFS to
> > > > OpenZFS, the bootcodes needs to be updated! It's unfortunate
> > > > that no message is displayed 8-(
> > > > 
> > > 
> > > That's too bad - maybe it would make sense to mention this in the
> > > release errata?
> > > 
> > > > The problem is, finding out which bootcode needs to go where
> > > > etc. 
> > > 
> > > For the machines in question it was a straightforward legacy
> > > layout, so that was easy enough (they came back up just fine -
> > > *phew*).
> > > 
> > > Do you think there is any chance to get the warning back in there?
> > > Maybe in a more generic way, like:
> > > 
> > >   In case you're booting from , please make sure to
> > > update the bootcode according to your partition layout. See `man
> > > zfsboot' for details.
> > > 
> > > Fun fact: That man page already exists (I had no idea), but could
> > > use some love - e.g., add the EFI examples you gave.
> > 
> > I have had a look at that man page, it gives ten different commands,
> > without saying which you need to use, if they are all needed, or
> > not, or when you actually have to used them.
> > 
> > Fun fact is that I absolutely never ever used any of them.  All I
> > ever did was run:
> > 
> >   gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
> > 
> > because `zpool upgrade` told me to.  It would probably be great to
> > have that command in that man page.
> >   
> 
> Hi Mathieu,
> 
> I opened a pull request upstream. It already has been reviewed and
> accepted, but is yet to be merged:
> https://github.com/openzfs/zfs/pull/12104
> 
> The bootcode warning is now only shown for pools that have bootfs set
> (which should be fine on most "normal" installations) and reads like
> this:
> 
>   Pool 'testpool8' has the bootfs property set, you might need to
> update the boot code. See gptzfsboot(8) and loader.efi(8) for details.
> 
> I figured that these are the most relevant man pages for current
> systems. It would make sense to update these man pages to be more
> helpful (latest, when this change lands in FreeBSD, but earlier
> obviously won't hurt).

The pull request has been merged upstream:
https://github.com/openzfs/zfs/commit/65d9212aeeb531e9f987bb41a1ee11b526d2cdad

I'll continue tracking the issue (backporting it to 13?) at our end:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256024

Best
Michael

-- 
Michael Gmelin

Re: ssh connections break with "Fssh_packet_write_wait" on 13

[Michael Gmelin]

On Tue, 1 Jun 2021 13:47:47 +0200
Michael Gmelin  wrote:

> Hi,
> 
> Since upgrading servers from 12.2 to 13.0, I get
> 
>   Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe
> 
> consistently, usually after about 11 idle minutes, that's with and
> without pf enabled. Client (11.4 in a VM) wasn't altered.
> 
> Verbose logging (client and server side) doesn't show anything special
> when the connection breaks. In the past, QoS problems caused these
> disconnects, but I didn't see anything apparent changing between 12.2
> and 13 in this respect.
> 
> I did a test on a newly commissioned server to rule out other factors
> (so, same client connections, some routes, same everything). On 12.2
> before the update: Connection stays open for hours. After the update
> (same server): connections breaks consistently after < 15 minutes
> (this is with unaltered configurations, no *AliveInterval configured
> on either side of the connection).
> 

I did a little bit more testing and realized that the problem goes away
when I disable "Proportional Rate Reduction per RFC 6937" on the server
side:

  sysctl net.inet.tcp.do_prr=0

Keeping it on and enabling net.inet.tcp.do_prr_conservative doesn't fix
the problem.

This seems to be specific to Parallels. After some more digging, I
realized that Parallels Desktop's NAT daemon (prl_naptd) handles
keep-alive between the VM and the external server on its own. There is
no direct communication between the client and the server. This means:

- The NAT daemon starts sending keep-alive packages right away (not
  after the VM's net.inet.tcp.keepidle), every 75 seconds.
- Keep-alive packages originating in the VM never reach the server.
- Keep-alive originating on the server never reaches the VM.
- Client and server basically do keep-alive with the nat daemon, not
  with each other.

It also seems like Parallels is filtering the tos field (so it's always
0x00), but that's unrelated.

I configured a bhyve VM running FreeBSD 11.4 on a separate laptop on
the same network for comparison and is has no such issues.

Looking at TCP dump output on the server, this is what a keep-alive
package sent by Parallels looks like:

  10:14:42.449681 IP (tos 0x0, ttl 64, id 15689, offset 0, flags [none],
proto TCP (6), length 40)
192.168.1.1.58222 > 192.168.1.2.22: Flags [.], cksum x (correct),
seq 2534, ack 3851, win 4096, length 0

While those originating from the bhyve VM (after lowering
net.inet.tcp.keepidle) look like this:

  12:18:43.105460 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF],
proto TCP (6), length 52)
192.168.1.3.57555 > 192.168.1.2.22: Flags [.], cksum x
(correct), seq 1780337696, ack 45831723, win 1026, options
[nop,nop,TS val 3003646737 ecr 3331923346], length 0

Like written above, once net.inet.tcp.do_prr is disabled, keepalive
seems to be working just fine. Otherwise, Parallel's NAT daemon kills
the connection, as its keep-alive requests are not answered (well,
that's what I think is happening):

  10:19:43.614803 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto TCP (6), length 40)
192.168.1.1.58222 > 192.168.1.2.22: Flags [R.], cksum x (correct),
seq 2535, ack 3851, win 4096, length 0

The easiest way to work around the problem Client side is to configure
ServerAliveInterval in ~/.ssh/config in the Client VM.

I'm curious though if this is basically a Parallels problem that has
only been exposed by PRR being more correct (which is what I suspect),
or if this is actually a FreeBSD problem.

Michael

-- 
Michael Gmelin

ssh connections break with "Fssh_packet_write_wait" on 13

[Michael Gmelin]

Hi,

Since upgrading servers from 12.2 to 13.0, I get

  Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe

consistently, usually after about 11 idle minutes, that's with and
without pf enabled. Client (11.4 in a VM) wasn't altered.

Verbose logging (client and server side) doesn't show anything special
when the connection breaks. In the past, QoS problems caused these
disconnects, but I didn't see anything apparent changing between 12.2
and 13 in this respect.

I did a test on a newly commissioned server to rule out other factors
(so, same client connections, some routes, same everything). On 12.2
before the update: Connection stays open for hours. After the update
(same server): connections breaks consistently after < 15 minutes (this
is with unaltered configurations, no *AliveInterval configured on
either side of the connection).

Thanks
Michael

-- 
Michael Gmelin

Re: zpool upgrade and bootcode on 13-RELEASE

[Michael Gmelin]

On Fri, 28 May 2021 20:37:14 +0200
Mathieu Arnold  wrote:

> On Wed, May 19, 2021 at 07:32:43PM +0200, Michael Gmelin wrote:
> > 
> > 
> > On Wed, 19 May 2021 19:09:06 +0200
> > Kurt Jaeger  wrote:
> >   
> > > Hi!
> > >   
> > > > Does this mean, re-installing the bootcode isn't necessary
> > > > anymore
> > > > - or has the warning been removed by accident/as a side effect
> > > > of merging with OpenZFS?
> > > 
> > > On the contrary, because of the switch from FreeBSD ZFS to
> > > OpenZFS, the bootcodes needs to be updated! It's unfortunate
> > > that no message is displayed 8-(
> > >   
> > 
> > That's too bad - maybe it would make sense to mention this in the
> > release errata?
> >   
> > > The problem is, finding out which bootcode needs to go where etc.
> > >  
> > 
> > For the machines in question it was a straightforward legacy
> > layout, so that was easy enough (they came back up just fine -
> > *phew*).
> > 
> > Do you think there is any chance to get the warning back in there?
> > Maybe in a more generic way, like:
> > 
> >   In case you're booting from , please make sure to update
> >   the bootcode according to your partition layout. See `man zfsboot'
> >   for details.
> > 
> > Fun fact: That man page already exists (I had no idea), but could
> > use some love - e.g., add the EFI examples you gave.  
> 
> I have had a look at that man page, it gives ten different commands,
> without saying which you need to use, if they are all needed, or not,
> or when you actually have to used them.
> 
> Fun fact is that I absolutely never ever used any of them.  All I ever
> did was run:
> 
>   gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
> 
> because `zpool upgrade` told me to.  It would probably be great to
> have that command in that man page.
> 

Hi Mathieu,

I opened a pull request upstream. It already has been reviewed and
accepted, but is yet to be merged:
https://github.com/openzfs/zfs/pull/12104

The bootcode warning is now only shown for pools that have bootfs set
(which should be fine on most "normal" installations) and reads like
this:

  Pool 'testpool8' has the bootfs property set, you might need to update
  the boot code. See gptzfsboot(8) and loader.efi(8) for details.

I figured that these are the most relevant man pages for current
systems. It would make sense to update these man pages to be more
helpful (latest, when this change lands in FreeBSD, but earlier
obviously won't hurt).

Best
Michael

-- 
Michael Gmelin

Re: Patch for patch, but not foreach :-)

[Michael Gmelin]

What about using "."? Or "/" (which would match the muscle memory of "search" 
in less/more/vi/some browsers)?

-m

> On 7. May 2021, at 23:05, Maxim Sobolev  wrote:
> 
> Replace '*' with ^T perhaps and catch SIGINFO? 樂
> 
> -Max
> 
>> On Fri., May 7, 2021, 10:11 a.m. Shawn Webb, 
>> wrote:
>> 
>>> On Fri, May 07, 2021 at 03:49:00PM +0200, Hans Petter Selasky wrote:
>>> Time has come that I make a patch for the most central patching tool in
>>> FreeBSD, patch :-)
>>> 
>>> https://reviews.freebsd.org/D30160
>> 
>> As stupid as it sounds, '*' is a valid filename.
>> 
>> --
>> Shawn Webb
>> Cofounder / Security Engineer
>> HardenedBSD
>> 
>> 
>> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>> 
> ___
> 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: git magic in contrib/bc

[Michael Gmelin]

On Wed, 28 Apr 2021 21:45:03 +0200
Michael Gmelin  wrote:

> > On 28. Apr 2021, at 21:37, Stefan Esser  wrote:
> > 
> > Am 28.04.21 um 20:44 schrieb Michael Gmelin:  
> >> 
> >>   
> >>> On Wed, 28 Apr 2021 20:00:38 +0300
> >>> Yuri Pankov  wrote:
> >>> 
> >>> Not sure if it's just me, but I'm seeing a bit of git weirdness in
> >>> contrib/bc:  
> >> 
> >> I'm seeing the same here, also when doing:
> >> 
> >>  rm .git/index
> >>  git reset
> >>  git status
> >> 
> >> after this, `git diff' also shows what changed in those files
> >> (basically every line). It's all whitespace characters, as `git
> >> diff -w' is empty.
> >> 
> >> Turns out EOLs changed, I suspect this is due to the eol overrides
> >> in contrib/bc/.gitattributes. If I comment those out, "git diff"
> >> is silent again.  
> > 
> > Yes, the new file .gitattributes has recently been committed by me
> > as part of an upgrade.
> > 
> > I do assume that the files affected are only for the Windows build
> > that has been added in version 4.0.0.
> > 
> > I do not know how to fix this problem (and whether this is just a
> > nuisance or an actual problem).
> >   
> 
> https://git-scm.com/docs/gitattributes says:
> “ eol
> This attribute sets a specific line-ending style to be used in the
> working directory. It enables end-of-line conversion without any
> content checks, effectively setting the text attribute. Note that
> setting this attribute on paths which are in the index with CRLF line
> endings may make the paths to be considered dirty. Adding the path to
> the index again will normalize the line endings in the index.”
> 
> Without completely understanding the problem, I would suggest to try
> the following:
> 
>rm .git/index
>git reset
>git commit -a
>git push
> 

It is enough to

  touch contrib/bc/*

to trigger the same behavior:

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
modified:   bc.vcxproj
modified:   bc.vcxproj.filters
modified:   bcl.vcxproj
modified:   bcl.vcxproj.filters


> (this should re-add the files to the index using the correct
> attributes)
> 
> Best,
> Michael
> 
> > The upstream repository is https://git.yzena.com/gavin/bc and I have
> > performed a "diff -r" of the distfile of the math/gh-bc port against
> > the files in vendor/bc in our repository (before the commit to that
> > repository) and thus any change that we locally apply will need to
> > be upstreamed.
> > 

These files won't differ from what is checked into our repo - the
problem seems only to be with the index, due to the order in which they
were checked in.

I simply recommitted[0] what is in the workdir after touching the files
(the new modification time made "git status" consider them, they were
always different after checkout than what's in .git/index).

This fixes the issue we perceived (checkout, copy, touch etc. won't
show the paths to be dirty anymore), while the diff to gavin/bc stays
clean:

  $ diff -r contrib/bc ~/gavin/bc
  Only in /home/user/gavin/bc: .git

I think this is the correct way to address the problem (having it
around was definitely more than a nuisance, as it would pop up as a
change every time the index is refreshed).

Cheers,
Michael

[0]https://cgit.freebsd.org/src/commit/?id=a0358e3d5184950b4316f105eb292cbafdea208b

-- 
Michael Gmelin
___
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: git magic in contrib/bc

[Michael Gmelin]

> On 28. Apr 2021, at 21:37, Stefan Esser  wrote:
> 
> Am 28.04.21 um 20:44 schrieb Michael Gmelin:
>> 
>> 
>>> On Wed, 28 Apr 2021 20:00:38 +0300
>>> Yuri Pankov  wrote:
>>> 
>>> Not sure if it's just me, but I'm seeing a bit of git weirdness in
>>> contrib/bc:
>> 
>> I'm seeing the same here, also when doing:
>> 
>>  rm .git/index
>>  git reset
>>  git status
>> 
>> after this, `git diff' also shows what changed in those files (basically
>> every line). It's all whitespace characters, as `git diff -w' is empty.
>> 
>> Turns out EOLs changed, I suspect this is due to the eol overrides in
>> contrib/bc/.gitattributes. If I comment those out, "git diff" is silent
>> again.
> 
> Yes, the new file .gitattributes has recently been committed by me
> as part of an upgrade.
> 
> I do assume that the files affected are only for the Windows build
> that has been added in version 4.0.0.
> 
> I do not know how to fix this problem (and whether this is just a
> nuisance or an actual problem).
> 

https://git-scm.com/docs/gitattributes says:
“ eol
This attribute sets a specific line-ending style to be used in the working 
directory. It enables end-of-line conversion without any content checks, 
effectively setting the text attribute. Note that setting this attribute on 
paths which are in the index with CRLF line endings may make the paths to be 
considered dirty. Adding the path to the index again will normalize the line 
endings in the index.”

Without completely understanding the problem, I would suggest to try the 
following:

   rm .git/index
   git reset
   git commit -a
   git push

(this should re-add the files to the index using the correct attributes)

Best,
Michael

> The upstream repository is https://git.yzena.com/gavin/bc and I have
> performed a "diff -r" of the distfile of the math/gh-bc port against
> the files in vendor/bc in our repository (before the commit to that
> repository) and thus any change that we locally apply will need to
> be upstreamed.
> 
> Regards, STefan
> 
___
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: git magic in contrib/bc

[Michael Gmelin]

On Wed, 28 Apr 2021 20:00:38 +0300
Yuri Pankov  wrote:

> Not sure if it's just me, but I'm seeing a bit of git weirdness in
> contrib/bc:

I'm seeing the same here, also when doing:

  rm .git/index
  git reset
  git status

after this, `git diff' also shows what changed in those files (basically
every line). It's all whitespace characters, as `git diff -w' is empty.

Turns out EOLs changed, I suspect this is due to the eol overrides in
contrib/bc/.gitattributes. If I comment those out, "git diff" is silent
again.

Cheers,
Michael

> 
> $ cd freebsd-src
> $ git status
> On branch main
> Your branch is up to date with 'origin/main'.
> 
> nothing to commit, working tree clean
> $ cd ..
> $ cp -a freebsd-src freebsd-src-copy
> $ cd freebsd-src-copy
> $ git status
> On branch main
> Your branch is up to date with 'origin/main'.
> 
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git restore ..." to discard changes in working
> directory) modified:   contrib/bc/bc.vcxproj
> modified:   contrib/bc/bc.vcxproj.filters
> modified:   contrib/bc/bcl.vcxproj
> modified:   contrib/bc/bcl.vcxproj.filters
> 
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> I can't figure what exactly changed in these files, diff (normal
> command, not git diff) does not show any differences, they are not
> symlinks.
> 
> This happens with clean clones from git.freebsd.org,
> gitrepo.freebsd.org, and github; it did not happen previously (not
> sure when it started though) -- I was usually just copying the whole
> tree into ~/ws/.
> 
> Any hints?
> ___
> 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"



-- 
Michael Gmelin
___
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: choosing different sound input and output devices

[Michael Gmelin]

On Wed, 21 Apr 2021 13:42:11 +0200
Marek Zarychta  wrote:

> Dear subscribers,
> 
> I tried to deploy the Chromium browser run on FreeBSD CURRENT to work 
> with Microsoft Teams and it almost works fine except for audio
> settings. To use USB microphone I have changed sysctl
> hw.snd.default_unit and was able to use my microphone, but it broke
> the playback. Is it possible to use different audio input and output
> devices ? Any clues, especially with regard to www/chromium will be
> appreciated.
> 
> Perhaps the list I am posting this question on was not carefully
> chosen, but haven't found any sound/audio specific mailing lists.
> 

Just out of curiosity: Going to chrome://settings/content/microphone
won't allow you to select the input device to use? (it seems like having
the select box in there is platform specific).

Best,
Michael

-- 
Michael Gmelin
___
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: sys/sys/param.h: 'main' instead of 'Master'?

[Michael Gmelin]

> On 16. Apr 2021, at 19:29, Rodney W. Grimes  
> wrote:
> 
> 
>> 
>> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling  wrote:
>>> 
>>> While viewing sys/sys/param.h I noticed that the comment of the
>>> definition of __FreeBSD_version is probably out of date.
>>> 
>>> Since the switch to Git, doesn't it have to be 'main' instead of 'master'?
>>> 
>> 
>> This isn't based on a branch name, though I guess if one were going to
>> touch it anyways then "Authoritative" would be a better descriptor.
> 
> As well as "Origin".

(Single) Source of Truth, maybe?

-m

> 
>> 
>>> #cd /usr/src
>>> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff
>>> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200
>>> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200
>>> @@ -60,7 +60,7 @@
>>>  * in the range 5 to 9.
>>>  */
>>> #undef __FreeBSD_version
>>> -#define __FreeBSD_version 147  /* Master, propagated to newvers */
>>> +#define __FreeBSD_version 147  /* main, propagated to newvers */
>>> 
>>> /*
>>>  * __FreeBSD_kernel__ indicates that this system uses the kernel of
>>> FreeBSD,
>>> 
>>> ___
>>> 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"
>> 
> 
> -- 
> Rod Grimes rgri...@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"

Re: linking to git revisions in bugzilla

[Michael Gmelin]

On Mon, 12 Apr 2021 15:00:58 +1000
Kubilay Kocak  wrote:

> On 12/04/2021 9:02 am, Yuri Pankov wrote:
> > While filing a bug, I noticed that the help only mentions svn
> > revision numbers, and "Preview" tab had no output

The Preview tab isn't updating in general when filing a new bug. This
is due to a problem with bugzilla. I described this in more detail here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250699#c3

I suggested a workaround in there as well, something like changing
'onclick="show_comment_preview()"' to
'onclick="show_comment_preview(1)".'.

I don't know who has the access permissions and time to fix the problem
or at least implement a temporary workaround.

Best,
Michael

> when I tried
> > putting "base ", so I'm wondering how do you link
> > to git revisions?  
> 
> We'll (bugmeister) be adding parsing support for it (along with a few 
> other related auto-linking things)
> 
> I'd encourage people to use " " (repo =
> src|doc|ports) where short hash is at least 8 chars in the meantime.
> Once parsing is added all previous references will be linked.
> ___
> 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"



-- 
Michael Gmelin
___
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

[Michael Gmelin]

On Wed, 31 Mar 2021 13:02:21 +0200
Christoph Moench-Tegeder  wrote:

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

The hashing algorithm (SHA-1) doesn't matter in case of trusted root
CAs though, as they're self-signed anyway - you trust the certificate
and not the signature in this case. Therefore, keeping them in for
compatibility reasons can make sense to prevent people from having to
maintain their own local trusted CA cert lists.

Probably doesn't matter so much in this specific case, but I remember
when security/ca_root_nss removed MD5 self-signed root CAs and the
world of pain I was in as a result of that decision, as legitimate
certificates that worked in all major browsers would be
suddenly considered insecure by my servers.

-m

> - and basically "whatever Mozilla did", as the certificates are
>   imported from NSS.
> 
> Regards,
> Christoph
> 



-- 
Michael Gmelin
___
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: Scrub incredibly slow with 13.0-RC3 (as well as RC1 & 2)

[Michael Gmelin]

On Fri, 26 Mar 2021 10:37:47 +0100
Mathieu Chouquet-Stringer  wrote:

> On Thu, Mar 25, 2021 at 08:55:12AM +, Matt Churchyard wrote:
> > Just an a aside, I did post a message a few weeks ago with a similar
> > problem on 13 (as well as snapshot issues). Scrub seemed ok for a
> > short while, but then ground to a halt. It would take 10+ minutes to
> > go 0.01%, with everything appearing fairly idle. I finally gave up
> > and stopped it after about 20 hours. Moving to 12.2 and rebuilding
> > the pool, the system scrubbed the same data in an hour, and I've
> > just scrubbed the same system after a month of use with about 4
> > times the data in 3 hours 20. As far as I'm aware, both should be
> > using effectively the same "new" scrub code.
> >
> > Will be interesting if you find a cause as I didn't get any response
> > to what for me was a complete showstopper for moving to 13.  
> 
> Bear with me, I'm slowly resilvering now... But same thing, it's not
> even maxing out my slow drives... Looks like it'll take 2 days...
> 
> I did some flame graphs using dtrace. The first one is just the output
> of that:
> dtrace -x stackframes=100 -n 'profile-99 /arg0/ { @[stack()] =
> count(); } tick-60s { exit(0); }'
> 
> Clearly my machine is not busy at all.
> And the second is the output of pretty much the same thing except I'm
> only capturing pid 31 which is the one busy.
> dtrace -x stackframes=100 -n 'profile-99 /arg0 && pid == 31/ {
> @[stack()] = count(); } tick-60s { exit(0); }'
> 
> One striking thing is how many times hpet_get_timecount is present...

Does tuning of

- vfs.zfs.scrub_delay
- vfs.zfs.resilver_min_time_ms
- vfs.zfs.resilver_delay

make a difference?

Best,
Michael

-- 
Michael Gmelin
___
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: 13.0 RC4 might be delayed

[Michael Gmelin]

> On 26. Mar 2021, at 04:30, Scott Long  wrote:
> 
> Hi everyone,
> 
> Speaking on behalf of Core, i wanted to let you know that 13.0 RC4 might be 
> delayed.  Glen has an emergency to attend to, and might be unavailable or 
> slow to respond for a few more days.

Fingers crossed, whatever it may be.

Best,
Michael


___
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: freebsd 13 ryzen micro stutter

[Michael Gmelin]

On Mon, 22 Mar 2021 23:50:52 -0400
monochrome  wrote:

> After about 8 months of struggling to narrow this down I did another 
> search and saw this:
> 
> https://www.reddit.com/r/freebsd/comments/lc8fwo/freebsd_13_vega_64_micro_stutter_in_x/
> 
> I haven't seen this come up here so I thought I would bring it up.
> 
> My story started sometime before around August last year when synergy 
> started getting really annoying with stuttering. Pretty sure it
> wasn't like that when I first started tracking 13-current in around
> May 2020 (I was on 12 with scfb for a long time before that with no
> issues), but since then I have tried to eliminate as many variables
> as possible. First I switched to barrier instead of synergy. Shortly
> after that I realized it was happening all the time and not just a
> network problem, I started using foobillard to verify during tests. I
> tried different RAM combinations, different network cards, a variety
> of RAM timings, stripping rc.conf etc, powerd settings, also scfb,
> with no effect. It is observable with ping -f, a dot or two appears
> every time it glitches. It seemed much better with RC2, but now with
> RC3 it seems to be back with a vengeance, and since its my main
> workstation and barrier/synergy server host for several machines, it
> is unbearable to use. Both Win10 and devuan3 on the same machine are
> smooth with no issues. Any feedback or info would be appreciated.
> 
> Hardware:
> ASRock B450M Pro4
> Ryzen 2400G, no OC
> 32M DDR4-2933
> Onboard Vega GPU, drm-fbsd13-kmod
> ___

Without knowing much about the issue at hand, just a few ideas:

Sysctls I would look at:
- raising *.cx_lowest
- different kern.eventtimer.timer

Try running with powerd disabled.

Try disabling acpi_thermal (debug.acpi.disabled="thermal") as stated in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234455#c9

Certainly someone else has better ideas though.

Best,
Michael

-- 
Michael Gmelin
___
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: Waiting for bufdaemon

[Michael Gmelin]

On Sat, 06 Mar 2021 08:33:23 +0900 (JST)
Yasuhiro Kimura  wrote:

> From: Konstantin Belousov 
> Subject: Re: Waiting for bufdaemon
> Date: Fri, 5 Mar 2021 22:43:58 +0200
> 
> > My belief is that this commit helps more users than it hurts.
> > Namely, the VMWare and KVM users, which are majority, use fast
> > timecounter, comparing to the more niche hypervisors like
> > VirtualBox.
> > 
> > For you, a simple but manual workaround, setting the timecounter to
> > ACPI (?) or might be HPET, with a loader tunable, should do it.  
> 
> Then please let me know the name of it.
> 
> I have experienced same situation several time. That is, I faced a
> problem and asked for it on ML. Then I was told to try some tunable.
> So I thought there may be tunable that can be used as workaround in
> this case. But for those who isn't familiar with kernel internal, it
> it quite hard to find it without knowing its name. If all tunable were
> listed with brief explanation in one document, then I saw it and could
> pick up possible candidates. But actually they are documented
> separately among many man pages. So the first difficulty is to find
> man page in which possible tunable may be explained. If the problem is
> releted to some device, it is most hopeful to check its man page. But
> in this case, even after reading the commit message, I had no idea
> which man page to check.
> 

see `man 4 timecounters':

https://www.freebsd.org/cgi/man.cgi?query=timecounters

-m

-- 
Michael Gmelin
___
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: Failure of release build with release.sh on 14-CURRENT amd64

[Michael Gmelin]

> On 4. Feb 2021, at 10:47, Yasuhiro Kimura  wrote:
> 
> It's a bit off topic from the first question, but please let me ask
> another one.
> 
> When everything is default, devel/git and textproc/docproj are
> installed in chroot environment after building userland and installing
> it to chroot has completed. While the former is installed by using
> official package, the latter is installed by using ports tree checked
> out in chroot.
> 
> Then is there any reason doing so? Why aren't both of them installed
> by using offical package nor by using ports tree?

I would assume that this is because

- textproc/docproj is the FreeBSD Documentation Project and therefore you 
always want to have the latest version, especially when working with CURRENT 
(so it’s part of our development effort).
- git is a third party tool maintained outside of the project (we won’t change 
it as part of developing FreeBSD)

Cheers,
Michael


> 
> ---
> Yasuhiro Kimura
> ___
> 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: Problem with X Server when updating to 38bfc6dee33

[Michael Gmelin]

> On 3. Feb 2021, at 13:50, Thomas Laus  wrote:
> 
> On 2/2/21 8:16 AM, David Wolfskill wrote:
>> You might want to see if this ports/UPDATING entry:
>> 
>> 20200320:
>>  AFFECTS: users of x11/libxkbcommon
>>  AUTHOR: zeis...@freebsd.org
>> 
>>  The libxkbcommon library (x11/libxkbcommon), used to handle keyboards
>>  in some applications, most notably kde and wayland, have been switched
>>  to use evdev rules by default on FreeBSD 12 and later.  Some keys, most
>>  notably arrow keys, may not work in applications using libxkbcommon if
>>  you are using xf86-input-keyboard rather than xf86-input-libinput.
>>  If you have trouble with the keyboard keys, and if /var/log/Xorg.*.log
>>  shows that the "kbd" or "keyboard" driver is being used, you need to
>>  switch to legacy rules by setting the environment variable
>>  XKB_DEFAULT_RULES to xorg.
>>  This switch is made to match the default configuration on FreeBSD 12.1 and
>>  later, the default configuration on FreeBSD 11.3 still uses the legacy
>>  rules.
>> 
> It did not apply.  I am using xf86-input-libinput-0.30.0_1 on both of
> the problem computers.  Everything worked until I performed the 'pkg
> bootstrap -f' after my last build world update.  Until then I was able
> to start X with a working keyboard and mouse.  When my packages were
> updated after the the ABI change, the mouse and keyboard stopped
> working.  I always upgrade all of my packages after building world and
> was prompted after the change to 14.0-CURRENT from 13.0-CURRENT to do
> so.  I ran the 'pkg upgrade' command and the prompt told me to run 'pkg
> bootstrap -f' because of the ABI change.  It downloaded a new pkg
> program and then upgraded all of my packages because of the change in ABI.
> 

There was a problem with xorg-server which made it build without udev on 14.

Try reinstalling xorg-server from ports (something like: portsnap fetch 
extract; cd /usr/ports/x11-servers/xorg-server && make clean reinstall clean)

Cheers,
Michael

> Tom
> 
> 
> -- 
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
> ___
> 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: Can't fetch https://www.freebsd.org/releng/index.html

[Michael Gmelin]

On Wed, 27 Jan 2021 09:40:24 +0900
KIRIYAMA Kazuhiko  wrote:

> Hi all,
> 
> I've been used https://www.freebsd.org/releng/index.html to know about
> latest FreeBSD updateing status for my many applications. I found that
> index.html can't fetch yesterday.
> 
> Is there anyone to tell me how to get latest FreeBSD updateing status
> information with source file ?

It's there, but redirecting to the new url:

requesting https://www.freebsd.org/releng/index.html
301 redirect to http://www.freebsd.org/releng/

-m

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



-- 
Michael Gmelin
___
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: jail fib no longer works after net.add_addr_allfibs=0

[Michael Gmelin]

On Mon, 11 Jan 2021 12:38:50 +
qroxana  wrote:

> I have exec.fib = 2 in /etc/jail.conf, but it seems the address of
> the jail is not inserted into this fib. What's the best practice
> for using jail with fib when net.add_addr_allfibs=0?

Depends on how you configure the jail address (seeing your full
jail.conf would be useful).

What I used to do when using fibs (switched everything to vnet now, as
fibs + jails can be painful), is setting something like this in rc.conf:

ifconfig_em0_name="jailif"
ifconfig_jailif="10.0.0.2/24 fib 2 description 'jail interface'"

and setting routes as needed:

static_routes="default_jailif"
route_default_jailif="default 10.0.0.1 -fib 2"

(in reality this involved vlans multiple addresses per interface)

Also, you need to make sure to use setfib correctly when jexec'ing into
a jail to (re)start daemons (plus, as a safety measure, configure
"_fib=2" within the jail's /etc/rc.conf).

Cheers,
Michael

-- 
Michael Gmelin
___
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: Finding a commit in cgit, given output from uname -a

[Michael Gmelin]

> On 2. Jan 2021, at 19:44, Graham Perrin  wrote:
> 
> FreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 
> main-c530-g8b4c3a03f: Fri Jan  1 15:27:15 GMT 2021 
> root@mowa219-gjp4-8570p:/usr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
>  amd64
> 
>  finds nothing.
> 
> Am I missing something?

Remove “g” from the hash.

-m

> 
> ___
> 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: after update to r368166: no sound recording

[Michael Gmelin]

> On 15. Dec 2020, at 08:44, Matthias Apitz  wrote:
> 
> El día lunes, diciembre 14, 2020 a las 10:16:21a. m. +0100, Matthias Apitz 
> escribió:
> 
>> I did a step by step down grading with 'svn up -r. hdaa.c hdaa.h'
>> (only these two files), starting from r368166 down to the following 
>> revisions:
>> 
>> r368166: no recording from pcm1
>> 
>> r358333: no recording from pcm1
>> 
>> r350078: no recording from pcm1
>> 
>> r337043: recording is fine
>> 
>> I've cc'ed now the commiters of the r358333 and r350078. kaktus@ and sbruno@
>> please check the issue 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727
>> and this mail thread in current@
> 
> I have nailed down the problem and locally fixed it with this:
> 
> # svn diff sys/dev/sound/pci/hda/hdaa.c
> Index: sys/dev/sound/pci/hda/hdaa.c
> ===
> --- sys/dev/sound/pci/hda/hdaa.c(revisión: 368166)
> +++ sys/dev/sound/pci/hda/hdaa.c(copia de trabajo)
> @@ -6598,6 +6598,7 @@
>devinfo->newgpo = -1;
>callout_init(>poll_jack, 1);
>devinfo->poll_ival = hz;
> +devinfo->init_clear = 1;/* added by g...@unixarea.de */
> 
>hdaa_lock(devinfo);
>res = hda_command(dev,
> 
> because there seems to be no code to set devinfo->init_clear from
> loader.conf; there is in hdaa.c:
> 
>   SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
>SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
>"init_clear", CTLFLAG_RW,
>>init_clear, 1,"Clear initial pin widget configuration");
> 
> but I don't see any function like hdaa_init_clear_handler() which writes
> the value to devinfo->init_clear; 
> 
> Am I mistaken?
> 
>matthias
> 
> 

Good catch, I played with the sysctl as well as device.hints, both which didn’t 
(seem to) make a difference.

-m




> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub

___
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: after update to r368166: no sound recording

[Michael Gmelin]

> On 11. Dec 2020, at 15:51, Jakob Alvermark  wrote:
> 
> 
>> On 12/11/20 8:06 AM, Matthias Apitz wrote:
>>> El día miércoles, diciembre 09, 2020 a las 11:55:18a. m. +0100, Hans Petter 
>>> Selasky escribió:
>>> 
>>> On 12/9/20 11:48 AM, Matthias Apitz wrote:
 El día miércoles, diciembre 09, 2020 a las 11:05:09a. m. +0100, Hans 
 Petter Selasky escribió:
 
> On 12/9/20 10:44 AM, Matthias Apitz wrote:
>> Hello,
>> 
>> I've updated a laptop Acer C720 from r342378 to r368166 and do not have
>> any sound incoming anymore. I rebooted r342378 from an USB stick and the
>> old kernel produces already noise in the speakers when I touch the
>> micro hole in the keyboard, the new kernel does not produce any noise
>> there. Both system have the same /boot/device.hints values:
>> 
>> 
>> Hello,
>> 
>> I reverted the kernel source in the directory sys/dev/sound/pci/hda to 
>> r342378:
>> 
>> $ cd /usr/src/sys/dev/sound/pci
>> $ svn info hda
>> Path: hda
>> Working Copy Root Path: /usr/src
>> URL: svn://svn.freebsd.org/base/head/sys/dev/sound/pci/hda
>> Relative URL: ^/head/sys/dev/sound/pci/hda
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 342378
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: mav
>> Last Changed Rev: 340071
>> Last Changed Date: 2018-11-02 18:02:10 +0100 (Fri, 02 Nov 2018)
>> 
>> compiled and installed the kernel:
>> 
>> $ uname -a
>> FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: 
>> Fri Dec 11 07:46:32 CET 2020 
>> guru@c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
>> 
>> and all is fine again as it was before. Someone with more knowledge should
>> have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
>> see which of the changes might break the things.
>> 
>> Thanks
>> 
>>matthias
>> 
>> 
> 
> Have you tried "hint.hdaa.1.init_clear=0" in /boot/loader.conf
> 

I updated my c720 to the same revision and could reproduce the problem. I 
didn’t have much time to look into it though. I played with a couple of 
settings (including this one), but it didn’t make a difference.

-m

> 
> Jakob
> 
> ___
> 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: KLD zfs.ko: depends on kernel - not available or version mismatch

[Michael Gmelin]

 make installkernel
>   shutdown -r now
>   
>   mount -u /
>   zpool import -Nf system (my /usr FS)
> 
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> 
> 
> >> Which results in dmesg messages:
> >> 
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type  
> > 
> > Be sure to check out /var/log/messages for extra issues.  For
> > example, with the bug I mentioned below, I couldn't load my nvidia
> > driver and that manifested as one driver having issues because it
> > depended on another, which had the root of the problem.  
> 
> I forgot to look there. If I find anything suspicious there, I’ll let
> you know. That system doesn’t have a convenient mail client yet, so
> for now its copying output to files and scp-ing that to the Mac.
> 
> >> I can load the zfs kernel module from kernel.old just fine:
> >> 
> >> ZFS filesystem version: 5
> >> ZFS storage pool version: features support (5000)  
> > 
> > I kicked my more bleeding-edge system over from 12.2-rel (r366954)
> > up into 13.0-current (r367044, 1300123) on 2020/10/26.  OpenZFS
> > kicked in 2020/8/24? I think the CFT was ~2018/8/21, not sure when
> > we had the OpenZFS ports. Current bumps the ABI version pretty
> > frequently so I'd think you'd have tripped across versioning issues
> > a long time ago if you had some drivers not being rebuilt.  
> 
> Having a conflict between kernel and world was what I was expecting
> too, but I can’t figure out what got me into that situation. For all
> I know, they should be in sync now, especially after I reverted the
> tree back to rev 366335 and making world again (acc. to above method).
> 
> >   
> >> This happens with any kernel module I???ve tried, such as
> >> geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the
> >> latter causes a kernel panic with kernel.old BTW).
> >> 
> >> I???ve gone back as far as Oct 7 (before changes to
> >> kern/elf_load_obj.c off the top of my head), looked at mailing
> >> list archives and forums etc, all to no avail.
> >> 
> >> I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I
> >> had /etc/malloc.conf with the recommended symlink from UPDATING,
> >> but the same happens with that moved out of the way. Nothing seems
> >> to help.
> >> 
> >> Do I need to go back further to get into a usable state or is
> >> there something else I should be doing?  
> > 
> > With very few exceptions (bug 250897, 2020/11/6), I've found
> > 13-current bootable since 10/26 (up through my current system, 13.0
> > r368388 (2020/12/6). You obviously need to make sure that an extra
> > drivers you add in are compiled against the kernel, but ZFS is
> > typically one of those.  
> 
> I think we covered that.
> 
> Thanks for the help and the pointers, but unfortunately the mystery
> remains.
> 

Do you have anything in /boot/modules?
(wild shot)

-m


-- 
Michael Gmelin
___
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

[Michael Gmelin]

> On 26. Nov 2020, at 19:21, Gary Jennejohn  wrote:
> 
> On Thu, 26 Nov 2020 10:44:19 -0700
> Warner Losh  wrote:
> 
>>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin  wrote:
>>> 
>>> 
>>> 
>>> On Thu, 26 Nov 2020 10:12:06 +0100
>>> Gary Jennejohn  wrote:
>>> 
>>>> On Thu, 26 Nov 2020 01:14:02 -0700
>>>> Warner Losh  wrote:
>>>> 
>>>>> On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn
>>>>>  wrote:  
>>>>>> On Thu, 26 Nov 2020 00:10:40 +
>>>>>> tech-lists  wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I have a usb3-connected harddrive. dmesg shows this:
>>>>>>> [...]
>>>>>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>>>>>> [...]
>>>>>>> 
>>>>>>> running current-r367806-arm64
>>>>>>> 
>>>>>>> I think it might be auto-spinning-down or auto-sleeping. It's
>>>>>>> making initial interaction lag of 2-3 seconds.  Is there a
>>>>>>> sysctl or something somewhere where I can tell it to never
>>>>>>> sleep?  Or is that something I'd need to contact the
>>>>>>> manufacturer about?  Or is there an alternative strategy like
>>>>>>> tmpfs.  It's not a "green" drive but I guess it might be
>>>>>>> "green" in that it's usb3 powered.
>>>>>>> 
>>>>>>> I have vfs.read_max=128 in /etc/sysctl.conf
>>>>>>> zdb has ashift=12
>>>>>>> 
>>>>>>> In case it's relevant, the filesystem on the disk is zfs. Once
>>>>>>> "woken up", inferaction is quick, as expected.
>>>>>>> thanks,
>>>>>>> 
>>>>>> 
>>>>>> I'd be interested in an answer to this question myself.  I have
>>>>>> several USB-attached UFS2 disks which spin down after a few
>>>>>> minutes.
>>>>>> 
>>>>>> But, based on some quick searches, this behavior is either a
>>>>>> "feature" of the disk itself - seems common with so-called green
>>>>>> disks - or of the controller in the external enclosure or docking
>>>>>> station.
>>>>>> 
>>>>>> This behavior makes sense for drives used with laptops, but for
>>>>>> desktop computers not so useful.
>>>>>> 
>>>>>> There are some sysctl's relevant to spindown, but they appear to
>>>>>> only come into play during suspend or shutdown.  The ones
>>>>>> relevant to USB which I found are:
>>>>>> 
>>>>>> kern.cam.ada.spindown_suspend: Spin down upon suspend
>>>>>> kern.cam.ada.spindown_shutdown: Spin down upon shutdown
>>>>>> 
>>>>>> There may be commands which a user can send the disk/controller to
>>>>>> disable this behavior, but I didn't find any with my simple
>>>>>> searches.  
>>>>> 
>>>>> For SAS drives, there's a mode page that controls this behavior.
>>>>> 
>>>>> You might see if the sysutil/ataidle port/package does what you
>>>>> want.  
>>>> 
>>>> Thanks, Warner, but that port is not in my HEAD ports tree.  It's
>>>> also not in the HEAD pkg repository.  Many the name has changed?
>>>> 
>>>> My disks are all SATA in various USB3 enclosures/docking stations.
>>>> 
>>> 
>>> I also used ataidle in the past, but it was removed from the ports tree
>>> in 2018 (see MOVED).
>>> 
>>> Since then, I'm using camcontrol to set standby timeout values on my
>>> SATA drives, I never tried it on USB devices though.
>>> 
>>> Example:
>>> 
>>> /sbin/camcontrol standby /dev/da2 -v -t 1800  
>> 
>> 
>> Perfect! I've not had to deal with sata disks that did this since the
>> ataidle days. I looked in camcontrol before suggesting it, but somehow
>> missed this... Glad I posted a bogus answer (sorry about that), since I
>> learned something new.
>> 
> 
> camcontrol unfortuantely doesn't work with my USB3 enclosures.  I
> suspect that the USB3-to-SATA bridge controller is doing its own thing
> and camcontrol has no effect on its behavior.  Not tragic for me since
> I use these disks primarily for backups.  But for someone using a USB
> attached disk as a primary file system this behavior will definitely be 
> a PITA.

Does using /dev/passX instead of /dev/daX make a difference? (I remember I had 
to do something like this when using smartctl on usb drives).

-m


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

[Michael Gmelin]

On Thu, 26 Nov 2020 10:12:06 +0100
Gary Jennejohn  wrote:

> On Thu, 26 Nov 2020 01:14:02 -0700
> Warner Losh  wrote:
> 
> > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn
> >  wrote: 
> > > On Thu, 26 Nov 2020 00:10:40 +
> > > tech-lists  wrote:
> > >
> > > > Hi,
> > > >
> > > > I have a usb3-connected harddrive. dmesg shows this:
> > > > [...]
> > > > da0:  Fixed Direct Access SPC-4 SCSI device
> > > > [...]
> > > >
> > > > running current-r367806-arm64
> > > >
> > > > I think it might be auto-spinning-down or auto-sleeping. It's
> > > > making initial interaction lag of 2-3 seconds.  Is there a
> > > > sysctl or something somewhere where I can tell it to never
> > > > sleep?  Or is that something I'd need to contact the
> > > > manufacturer about?  Or is there an alternative strategy like
> > > > tmpfs.  It's not a "green" drive but I guess it might be
> > > > "green" in that it's usb3 powered.
> > > >
> > > > I have vfs.read_max=128 in /etc/sysctl.conf
> > > > zdb has ashift=12
> > > >
> > > > In case it's relevant, the filesystem on the disk is zfs. Once
> > > > "woken up", inferaction is quick, as expected.
> > > > thanks,
> > > >
> > >
> > > I'd be interested in an answer to this question myself.  I have
> > > several USB-attached UFS2 disks which spin down after a few
> > > minutes.
> > >
> > > But, based on some quick searches, this behavior is either a
> > > "feature" of the disk itself - seems common with so-called green
> > > disks - or of the controller in the external enclosure or docking
> > > station.
> > >
> > > This behavior makes sense for drives used with laptops, but for
> > > desktop computers not so useful.
> > >
> > > There are some sysctl's relevant to spindown, but they appear to
> > > only come into play during suspend or shutdown.  The ones
> > > relevant to USB which I found are:
> > >
> > > kern.cam.ada.spindown_suspend: Spin down upon suspend
> > > kern.cam.ada.spindown_shutdown: Spin down upon shutdown
> > >
> > > There may be commands which a user can send the disk/controller to
> > > disable this behavior, but I didn't find any with my simple
> > > searches. 
> > 
> > For SAS drives, there's a mode page that controls this behavior.
> > 
> > You might see if the sysutil/ataidle port/package does what you
> > want. 
> 
> Thanks, Warner, but that port is not in my HEAD ports tree.  It's
> also not in the HEAD pkg repository.  Many the name has changed?
> 
> My disks are all SATA in various USB3 enclosures/docking stations.
> 

I also used ataidle in the past, but it was removed from the ports tree
in 2018 (see MOVED).

Since then, I'm using camcontrol to set standby timeout values on my
SATA drives, I never tried it on USB devices though.

Example:

/sbin/camcontrol standby /dev/da2 -v -t 1800

Best,
Michael


-- 
Michael Gmelin
___
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: Deprecating ftpd in the FreeBSD base system?

[Michael Gmelin]

> On 16. Sep 2020, at 22:53, Michael Gmelin  wrote:
> 
> 
> 
>>> On 16. Sep 2020, at 22:45, mike tancsa  wrote:
>>> 
>>> On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>>> # override default of no subsystems
>>> -Subsystemsftp/usr/libexec/sftp-server
>>> +Subsystemsftpinternal-sftp -l INFO
>> 
>> Hi,
>> 
>> What is the difference between these two ?  Is it not all OpenSSH ?
> 
> Yes, but one is an external binary, while internal doesn’t rely on that. 
> Which means that your chroot setup won’t require bin and lib dirs. For most 
> scenarios, internal is the way to go.
> 
> The man page has more details.
> 
> -m

p.s. this is a good write-up:

https://serverfault.com/questions/660160/openssh-difference-between-internal-sftp-and-sftp-server


> 
> 
>>---Mike
>> 
>> 
>> ___
>> 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: Deprecating ftpd in the FreeBSD base system?

[Michael Gmelin]

> On 16. Sep 2020, at 22:45, mike tancsa  wrote:
> 
> On 9/16/2020 2:07 PM, sth...@nethelp.no wrote:
>> # override default of no subsystems
>> -Subsystemsftp/usr/libexec/sftp-server
>> +Subsystemsftpinternal-sftp -l INFO
> 
> Hi,
> 
> What is the difference between these two ?  Is it not all OpenSSH ?

Yes, but one is an external binary, while internal doesn’t rely on that. Which 
means that your chroot setup won’t require bin and lib dirs. For most 
scenarios, internal is the way to go.

The man page has more details.

-m


> ---Mike
> 
> 
> ___
> 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: Deprecating ftpd in the FreeBSD base system?

[Michael Gmelin]

> On 16. Sep 2020, at 20:08, sth...@nethelp.no wrote:
> 
> 
>> 
>> FTP is (becoming?) a legacy protocol, and I think it may be time to
>> remove the ftp server from the FreeBSD base system - with the recent
>> security advisory for ftpd serving as a reminder.
>> 
>> I've proposed adding a deprecation notice to the man page in
>> https://reviews.freebsd.org/D26447 to start this off. There are a
>> number of ftp servers in ports, and if we're going to remove the base
>> system one we can create a port for it first, as well.
>> 
>> Any comments or concerns, please follow up in the code review or in email 
>> here.
> 
> Could we, at the same time, improve the documentation for sftp? I had
> to move an FTP server (with one chrooted user) from FTP to sftp today.
> I did:
> 
> 1. Add sftp user to /etc/passwd, with /usr/sbin/nologin as the shell.
> 2. Patch sshd config as follows:
> 
> --- etc/ssh/sshd_config.orig2018-06-16 22:04:20.868762000 +0200
> +++ etc/ssh/sshd_config2020-09-16 10:10:53.133211000 +0200
> @@ -112,7 +112,7 @@
> #Banner none
> 
> # override default of no subsystems
> -Subsystemsftp/usr/libexec/sftp-server
> +Subsystemsftpinternal-sftp -l INFO
> 
> # Example of overriding settings on a per-user basis
> #Match User anoncvs
> @@ -120,3 +120,8 @@
> #AllowTcpForwarding no
> #PermitTTY no
> #ForceCommand cvs server
> +Match User sftp
> +ChrootDirectory/usr/local/ftp/sftp
> +ForceCommand internal-sftp -l INFO
> +X11Forwarding no
> +AllowTcpForwarding no
> 
> 3. Ensure all levels of /usr/local/ftp/sftp are owned by root.
> 4. Create /usr/local/ftp/sftp/dev and add the following line to
> /etc/rc.conf:
> 
> syslogd_flags="-s -l /usr/local/ftp/sftp/dev/log"
> 
> Btw, I could not get /usr/libexec/sftp-server to work. Cryptic error
> message: "Received message too long 1416128883". Googling that one
> eventually led me to the internal-sftp subsystem and the rest of the
> sshd_config changes. The sshd_config man page is good, but I couldn't
> find anything about arguments (e.g. -l) for internal-sftp.

In case it helps, I documented an example sftp setup as part of the paperless 
port's man page last year:

https://svnweb.freebsd.org/ports/head/deskutils/py-paperless/files/paperless.7.in?revision=521891=co

-m

> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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: buildworld: "cp: /dev/null: Invalid argument"

[Michael Gmelin]

> On 12. Sep 2020, at 11:06, Hartmann, O.  wrote:
> 
> On Sat, 12 Sep 2020 10:03:18 +0200
> Michael Gmelin  wrote:
> 
>>> On 12. Sep 2020, at 09:55, Hartmann, O. 
>>> wrote:
>>> On Fri, 11 Sep 2020 07:18:33 -0600
>>> Alan Somers  wrote:
>>>>> On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann
>>>>>  wrote:
>>>>> On Thu, 10 Sep 2020 10:44:08 -0600
>>>>> Alan Somers  wrote:
>>>>>> No, it's devfs.  I'll fix it.
>>>>>> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone 
>>>>>> wrote:   
>>>>>>> I'm curious: does this give a similar issue?
>>>>>>> touch /tmp/foo
>>>>>>> cp /tmp/foo /tmo/foo2
>>>>>>> I'm wondering if the issue is that copy_file_range isn't
>>>>>>> handling empty files, or if it's a devfs issue.
>>>>>>> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
>>>>>>>  wrote:
>>>>>>>> It seems that SVN r365549 broke "cp /dev/null ..."
>>>>>>>>  imb
>>>>>>>>>> On 9/10/20 10:35 AM, Michael Butler wrote:
>>>>>>>>>>> Is anyone else seeing failures like this in building world
>>>>>>>>>>> and, in
>>>>>>> my
>>>>>>>>>>> case, cron jobs as well?
>>>>>>>>>>> Building
>>>>>>> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
>>>>>>>>>>> --- all_subdir_sbin ---
>>>>>>>>>>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
>>>>>>>>>>> --- all_subdir_stand ---
>>>>>>>>>>> --- zfsboot.ldr ---
>>>>>>>>>>> cp: /dev/null: Invalid argument
>>>>>>>>>>> *** [zfsboot.ldr] Error code 1
>>>>>>>>>>> make[5]: *** zfsboot.ldr removed
>>>>>>>>>>> --- all_subdir_kerberos5 ---
>>>>>>>>>>> Building
>>>>>>>>> /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
>>>>>>>>>>> --- all_subdir_stand ---
>>>>>>>>>>> make[5]: stopped in /usr/src/stand/i386/zfsboot
>>>>>>>>>>> .ERROR_TARGET='zfsboot.ldr'
>>>>>>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
>>>>>>>>>>> .MAKE.LEVEL='5'
>>>>>>>>>>> MAKEFILE=''
>>>>>>>>>>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes
>>>>>>>>>>> silent=yes
>>>>>>>>> verbose'
>>>>>>>>>>> _ERROR_CMD='cp /dev/null zfsboot.ldr;'
>>>>>>>>>>> .CURDIR='/usr/src/stand/i386/zfsboot'
>>>>>>>>>>> .MAKE='make'
>>>>>>>>>>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
>>>>>>>>>>> .TARGETS='all'
>>>>>>>>>>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
>>>>>>>>>>> LD_LIBRARY_PATH=''
>>>>>>>>>>> MACHINE='amd64'
>>>>>>>>>>> MACHINE_ARCH='amd64'
>>>>>>>>>>> MAKEOBJDIRPREFIX=''
>>>>>>>>>>> MAKESYSPATH='/usr/src/share/mk'
>>>>>>>>>>> MAKE_VERSION='20200902'
>>>>>>>>>>> ___
>>>>>>>>>>> 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: buildworld: "cp: /dev/null: Invalid argument"

[Michael Gmelin]

> On 12. Sep 2020, at 09:55, Hartmann, O.  wrote:
> 
> On Fri, 11 Sep 2020 07:18:33 -0600
> Alan Somers  wrote:
> 
>>> On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann 
>>> wrote:
>>> 
>>> On Thu, 10 Sep 2020 10:44:08 -0600
>>> Alan Somers  wrote:
>>> 
 No, it's devfs.  I'll fix it.
 
 On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone 
 wrote: 
> I'm curious: does this give a similar issue?
> 
> touch /tmp/foo
> cp /tmp/foo /tmo/foo2
> 
> I'm wondering if the issue is that copy_file_range isn't
> handling empty files, or if it's a devfs issue.
> 
> 
> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
>  wrote:  
>> 
>> It seems that SVN r365549 broke "cp /dev/null ..."
>> 
>>imb
>> 
>> On 9/10/20 10:35 AM, Michael Butler wrote:  
>>> Is anyone else seeing failures like this in building world
>>> and, in  
>>> my  
>>> case, cron jobs as well?
>>> 
>>> 
>>> Building  
>>> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr  
>>> --- all_subdir_sbin ---
>>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
>>> --- all_subdir_stand ---
>>> --- zfsboot.ldr ---
>>> cp: /dev/null: Invalid argument
>>> *** [zfsboot.ldr] Error code 1
>>> make[5]: *** zfsboot.ldr removed
>>> --- all_subdir_kerberos5 ---
>>> Building  
> /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
> 
>>> --- all_subdir_stand ---
>>> 
>>> make[5]: stopped in /usr/src/stand/i386/zfsboot
>>> .ERROR_TARGET='zfsboot.ldr'
>>> 
> 
>>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
>>> 
> 
>>> .MAKE.LEVEL='5'
>>> MAKEFILE=''
>>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes
>>> silent=yes  
> verbose'  
>>> _ERROR_CMD='cp /dev/null zfsboot.ldr;'
>>> .CURDIR='/usr/src/stand/i386/zfsboot'
>>> .MAKE='make'
>>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
>>> .TARGETS='all'
>>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
>>> LD_LIBRARY_PATH=''
>>> MACHINE='amd64'
>>> MACHINE_ARCH='amd64'
>>> MAKEOBJDIRPREFIX=''
>>> MAKESYSPATH='/usr/src/share/mk'
>>> MAKE_VERSION='20200902'
>>> 
>>> ___
>>> 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"
> 
 ___
 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"
>>> 
>>> I still get this error on a couple of boxes, while others seem to
>>> buildworld
>>> fine. All boxes are at CURRENT revision 365625. It is a bit looking
>>> weird to
>>> me. Running now a make cleanworld/cleandir on the specific boxes
>>> and start building OS again.
>>> 
>>> oh
>>> 
>> 
>> I don't know why it's intermittent, but in any case this patch should
>> fix it:
>> https://reviews.freebsd.org/D26395
>> -Alan
> 
> I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or
> just deleting usr/obj/) and starting a fresh build, those boxes with an
> newer kernel all fail at the very same point. We use META_MODE on some
> boxes, switched to WITHOUT_CLEAN these days and cleanded up on some
> systems therefore. That might be the reason why the problem occurs not
> consistently on all systems.
> 
> When will the pacth be committed?
> 

Alan already committed it:

https://svnweb.freebsd.org/base?view=revision=365643

-m

> Thanks in advance,
> 
> oh
___
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: Build of poudriere 13-CURRENT jail is failed

[Michael Gmelin]

> On 11. Sep 2020, at 22:12, Yasuhiro KIMURA  wrote:
> 
> Hello,
> 
> I made regular update of my 13-CUREENT amd64 environment from r365330
> to r365634. Host OS is successfully updated with regular steps written
> in /usr/src/Makefile. But update of poudriere jail is failed with
> error.

Please see: https://reviews.freebsd.org/D26395

-m

___
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: Is pkg site forbidden by brower?

[Michael Gmelin]

> On 6. Sep 2020, at 21:09, Yoshihiro Ota  wrote:
> 
> On Sun, 6 Sep 2020 14:47:00 +0200
> Michael Gmelin  wrote:
> 
>> 
>> 
>>>> On 6. Sep 2020, at 12:00, Niclas Zeising  
>>>> wrote:
>>> 
>>> 〓On 2020-09-06 09:00, grarpamp wrote:
>>>>> On 9/6/20, Kevin Oberman  wrote:
>>>>> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
>>>>>> Is "403 Forbidden" an intended response for a brower access to
>>>>>> http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
>>>>>> 
>>>>>> I used to see available packages with a brower and decided which one to
>>>>>> use.
>>>> Some more people have noted this change
>>>> as breaking tool scripts, etc.
>>>> And useful meta files are unfortunately now invisible:
>>>> packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig
>>>> If someone want to block the '/.../All/' dir full of pkgs,
>>>> maybe, but do not block any other part of the hier.
>>> 
>>> The reason that folder listing was disabled on the package download sites 
>>> is that it used too
>>> much resources.  For every hit on those URLs, the web server had to 
>>> dynamically generate the
>>> folder listing, and send it.  This caused DDoS-like scenarios, where these 
>>> were hit repeatedly,
>>> which caused problems for legitimate traffic.  Since the relevant 
>>> information is available in
>>> the txz files above, and also on freshports, and since pkg have no need for 
>>> directory listing,
>>> it was disabled.
>>> 
>> 
>> Is this part of why pkg repos are performing so much better recently? I‘m 
>> quite happy about
>> that :)
>> 
>> If there’s a use case for having access to this information, we could simply 
>> provide it through a
>> static index.html that’s recreated every time the directory changes.
>> 
>> Cheers,
>> Michael
> 
> Michael,
> 
> Do you own pkg sites?

Unfortunately not, but you could ask clusteradm@ about that.

Cheers,
Michael

> 
> I like the idea of creating static index.html file as there are modules with 
> version numbers and also modules with multiple version numbers.
> Brower helps to find which versions are available, for example.
> 
> Regards,
> Hiro
> ___
> 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: Is pkg site forbidden by brower?

[Michael Gmelin]

> On 6. Sep 2020, at 12:00, Niclas Zeising  wrote:
> 
> On 2020-09-06 09:00, grarpamp wrote:
>>> On 9/6/20, Kevin Oberman  wrote:
>>> On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:
 Is "403 Forbidden" an intended response for a brower access to
 http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?
 
 I used to see available packages with a brower and decided which one to
 use.
>> Some more people have noted this change
>> as breaking tool scripts, etc.
>> And useful meta files are unfortunately now invisible:
>> packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig
>> If someone want to block the '/.../All/' dir full of pkgs,
>> maybe, but do not block any other part of the hier.
> 
> The reason that folder listing was disabled on the package download sites is 
> that it used too much resources.  For every hit on those URLs, the web server 
> had to dynamically generate the folder listing, and send it.  This caused 
> DDoS-like scenarios, where these were hit repeatedly, which caused problems 
> for legitimate traffic.  Since the relevant information is available in the 
> txz files above, and also on freshports, and since pkg have no need for 
> directory listing, it was disabled.
> 

Is this part of why pkg repos are performing so much better recently? I‘m quite 
happy about that :)

If there’s a use case for having access to this information, we could simply 
provide it through a static index.html that’s recreated every time the 
directory changes.

Cheers,
Michael


___
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: Length of ZFS volume names

[Michael Gmelin]

> On 24. Aug 2020, at 17:20, Shawn Webb  wrote:
> 
> Hey FreeBSD peeps,
> 
> The zfs(8) manpage says that the maximum length of a dataset name is
> MAXNAMELEN (256 bytes). I've created a ZFS volume that has a dataset
> name length of 62. I don't see the ZFS volume in /dev/zvol and I
> noticed this sanitized error in dmesg:
> 
> Aug 24 11:07:24 bh-build-01 kernel: [2395] ZFS WARNING: Unable to create ZVOL 
> tank/bhyve/productname/dev/users/username/username-shortened_productname-dev-01/disk-01
>  (error=63).
> 
> So I'm left wondering, does devfs have a smaller limit than ZFS for
> node paths?
> 

Might be related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238112


> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
> 
> GPG Key ID:  0xFF2E67A277F8E1FA
> GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
> https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
___
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: KiCad is horrible on CURRENT

[Michael Gmelin]

> On 29. Jul 2020, at 21:29, Poul-Henning Kamp  wrote:
> 
> ----
> Michael Gmelin writes:
> 
>> I meant which xorg driver - modesetting or Intel?
> 
> It looks like "modesetting":
> 

You could try installing xf86-video-intel and see if that makes a difference 
(in terms of artifacts, can’t imagine it has anything to do with the focus 
issue?!).

Unfortunately, I use the machine I have around that’s similar to yours for 
something productive at the moment, so I can’t update it to current to try 
myself.

-m


>[   149.032] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
>[   149.038] (II) Module glx: vendor="X.Org Foundation"
>[   149.038]compiled for 1.20.8, module version = 1.0.0
>[   149.038]ABI class: X.Org Server Extension, version 10.0
>[   149.038] (==) Matched intel as autoconfigured driver 0
>[   149.038] (==) Matched modesetting as autoconfigured driver 1
>[   149.038] (==) Matched scfb as autoconfigured driver 2
>[   149.038] (==) Matched vesa as autoconfigured driver 3
>[   149.038] (==) Assigned the driver to the xf86ConfigLayout
>[   149.038] (II) LoadModule: "intel"
>[   149.038] (WW) Warning, couldn't open module intel
>[   149.038] (EE) Failed to load module "intel" (module does not exist, 0)
>[   149.038] (II) LoadModule: "modesetting"
>[   149.038] (II) Loading 
> /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
>[   149.039] (II) Module modesetting: vendor="X.Org Foundation"
>[   149.039]compiled for 1.20.8, module version = 1.20.8
>[   149.039]Module class: X.Org Video Driver
>[   149.039]ABI class: X.Org Video Driver, version 24.1
> 
> -- 
> 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.
> ___
> 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: KiCad is horrible on CURRENT

[Michael Gmelin]

> On 29. Jul 2020, at 21:18, Poul-Henning Kamp  wrote:
> 
> ----
> Michael Gmelin writes:
> 
>> Which driver are you using?
> 
> drm-devel-kmod-5.3.g20200724
> 


I meant which xorg driver - modesetting or Intel?

-m

> dmesg:
> 
>drmn0:  on vgapci0
>vgapci0: child drmn0 requested pci_enable_io
>vgapci0: child drmn0 requested pci_enable_io
>[drm] Unable to create a private tmpfs mount, hugepage support will be 
> disabled(-19).
>__pm_runtime_resume not implemented -- see your local kernel hacker
>pm_runtime_mark_last_busy not implemented -- see your local kernel hacker
>__pm_runtime_suspend not implemented -- see your local kernel hacker
>Failed to add WC MTRR for [0x8000-0x9fff]: -22; performance may 
> suffer
>[drm] Got stolen memory base 0x7d80, size 0x200
>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>[drm] Driver supports precise vblank timestamp query.
>[drm] Connector eDP-1: get mode from tunables:
>[drm]   - kern.vt.fb.modes.eDP-1
>[drm]   - kern.vt.fb.default_mode
>[drm] Connector DP-1: get mode from tunables:
>[drm]   - kern.vt.fb.modes.DP-1
>[drm]   - kern.vt.fb.default_mode
>[drm] Connector HDMI-A-1: get mode from tunables:
>[drm]   - kern.vt.fb.modes.HDMI-A-1
>[drm]   - kern.vt.fb.default_mode
>[drm] Connector DP-2: get mode from tunables:
>[drm]   - kern.vt.fb.modes.DP-2
>[drm]   - kern.vt.fb.default_mode
>[drm] Connector HDMI-A-2: get mode from tunables:
>[drm]   - kern.vt.fb.modes.HDMI-A-2
>[drm]   - kern.vt.fb.default_mode
>pm_runtime_get_if_in_use not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>register_oom_notifier not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>kmem_cache_shrink not implemented -- see your local kernel hacker
>sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
>[drm] Initialized i915 1.6.0 20190619 for drmn0 on minor 0
>register_acpi_notifier not implemented -- see your local kernel hacker
>async_schedule is dodgy -- see your local kernel hacker
>pm_runtime_set_autosuspend_delay not implemented -- see your local kernel 
> hacker
>__pm_runtime_use_autosuspend not implemented -- see your local kernel 
> hacker
>async_synchronize_cookie not implemented -- see your local kernel hacker
>acpi_video0:  on vgapci0
>WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 
> 13.0.
>VT: Replacing driver "vga" with new "fb".
>[drm] Reducing the compressed framebuffer size. This may lead to less 
> power savings than a non-reduced-size. Try to increase stolen memory size if 
> available in BIOS.
>start FB_INFO:
>type=11 height=1080 width=1920 depth=32
>cmsize=16 size=14745600
>pbase=0x8004 vbase=0xf8008004
>name=drmn0 flags=0x0 stride=10240 bpp=32
>cmap[0]=0 cmap[1]=7f cmap[2]=7f00 cmap[3]=c4a000
>end FB_INFO
>drmn0: fb0: i915drmfb frame buffer device
>drmn0: successfully loaded firmware image with name: 
> i915/kbl_dmc_ver1_04.bin
>[drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
> 
> 
> -- 
> 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.
> ___
> 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: KiCad is horrible on CURRENT

[Michael Gmelin]

> On 29. Jul 2020, at 21:02, Poul-Henning Kamp  wrote:
> 
> 
> Ed Maste writes:
>>> On Wed, 29 Jul 2020 at 06:20, Poul-Henning Kamp  wrote:
>>> 
>>> I just noticed that KiCad's scroll-bars flash a lot whenever the mouse
>>> pointer is moved, that sounds like it could be the focus-event-flooding.
>> 
>> For me KiCad's scroll bars are hidden, and flash briefly on and off
>> while the pointer's moving. This is with a USB mouse (trackball)
>> attached, and xfwm4.
> 
> I'm seing similar stuff, and sometimes I am also seeing some screen
> artifacts which could implicate DRM :-(
> 

Which driver are you using?


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