Re: FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED]
On 20/10/2023 00:14, Doug Hardie wrote: On Oct 19, 2023, at 16:16, Miroslav Lachman <000.f...@quip.cz> wrote: On 19/10/2023 21:26, Tomoaki AOKI wrote: On Thu, 19 Oct 2023 19:53:08 + Miroslav Lachman <000.f...@quip.cz> wrote: [..] It is hackery workaround. freebsd-update must not overwrite user modified files without safe merge of conflicts. yet it did it in the past, for example pf.conf and some other vital files. Kind regards Miroslav Lachman I don't think it hackery. What should have been is that default sshf_config to be in /etc/defaults and /etc/defaults/rc.conf points to it, and anyone needs custom settings to create sshd_config in /etc/ssh (or in somewhere else), like rc.conf case. I don't think /etc/ssh/sshd_config is the default not intended to be edited. I am on FreeBSD from 4.x times and it was always supposed to be modifed by users and was handled by mergemaster or etcupdate. If freebsd-update cannot deal with it then it is a bug in freebsd-update. All in all pre-installed /etc/ssh/sshd_config has almost everything commented out because defaults are built in. While that has been the norm since 2.5, it does have a significant problem that changes to sshd configuration variables do not get incorporated into updated systems easily. Yes, mergemaster will somewhat show you the new configuration items, they are not always obvious and are very easy to ignore. There was one update to sshd that caused it not to function without the new variable. I don't recall the version or variable anymore, but it caused me days of problems trying to figure out why I couldn't connect to my servers. And there was a problem with documented and shipped variable no longer works causing sshd failed to start after reboot: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209441 There always will be cases when something break badly. I believe that adding a couple lines of sh code to the end of sshd.conf would cause it to read /usr/local/etc/sshd.conf and avoid those issues. That is done in other places in the rc process. I don't have sshd.conf on my system but I you mean sshd_config it is not parsed / interpreted by sh. It is passed directly to sshd. Kind regards Miroslav Lachman
Re: FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED]
> On 20 Oct 2023, at 02:14, Doug Hardie wrote: > > I believe that adding a couple lines of sh code to the end of sshd.conf would > cause it to read /usr/local/etc/sshd.conf and avoid those issues. That is > done in other places in the rc process. > > — Doug Yes, it would be great if the stock /etc/sshd_config would include something like Include /usr/local/etc/ssh/* as the final line. I would never have to touch it again. It’s always a bother keeping it up to date, especially when running lots of jails. Ben
Re: FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED]
On 20/10/2023 08:55, Ben Stuyts wrote: On 20 Oct 2023, at 02:14, Doug Hardie wrote: I believe that adding a couple lines of sh code to the end of sshd.conf would cause it to read /usr/local/etc/sshd.conf and avoid those issues. That is done in other places in the rc process. — Doug Yes, it would be great if the stock /etc/sshd_config would include something like Include /usr/local/etc/ssh/* as the final line. I would never have to touch it again. It’s always a bother keeping it up to date, especially when running lots of jails. Except that /usr/local/etc/ is for configuration files used by ports/packages and not the services from base. If you want it, then it should be something like this: Include /etc/ssh/sshd_config.d/*.conf or this Include /etc/ssh/sshd_config.d/*.conf Include /usr/local/etc/ssh/sshd_config.d/*.conf But search the internet first, there are reported bugs and headaches with Include and Match. Kind regards Miroslav Lachman
Local sshd_config modifications (was: FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED])
> On 20 Oct 2023, at 12:07, Miroslav Lachman <000.f...@quip.cz> wrote: > > On 20/10/2023 08:55, Ben Stuyts wrote: >>> On 20 Oct 2023, at 02:14, Doug Hardie wrote: >>> >>> I believe that adding a couple lines of sh code to the end of sshd.conf >>> would cause it to read /usr/local/etc/sshd.conf and avoid those issues. >>> That is done in other places in the rc process. >>> >>> — Doug >> Yes, it would be great if the stock /etc/sshd_config would include something >> like >> Include /usr/local/etc/ssh/* >> as the final line. I would never have to touch it again. It’s always a >> bother keeping it up to date, especially when running lots of jails. > > Except that /usr/local/etc/ is for configuration files used by ports/packages > and not the services from base. > > If you want it, then it should be something like this: > > Include /etc/ssh/sshd_config.d/*.conf > > or this > > Include /etc/ssh/sshd_config.d/*.conf > Include /usr/local/etc/ssh/sshd_config.d/*.conf Noted, thanks. Personally I just use Include /etc/ssh/sshd_config.local, but I thought my initial solution would be more generic. > But search the internet first, there are reported bugs and headaches with > Include and Match. I personally have not seen any problems when using Match with this. But it looks like this was fixed in 8.4, and FreeBSD (12.4) is running 9.1. Looking at it now, I see that I also had to disable the Subsection sftp part, as I sometimes redefine it in the local file. And sshd barfs on duplicate Subsections. Ben
Re: Local sshd_config modifications
On 20/10/2023 10:41, Ben Stuyts wrote: Include /etc/ssh/sshd_config.d/*.conf Include /usr/local/etc/ssh/sshd_config.d/*.conf Noted, thanks. Personally I just use Include /etc/ssh/sshd_config.local, but I thought my initial solution would be more generic. But search the internet first, there are reported bugs and headaches with Include and Match. I personally have not seen any problems when using Match with this. But it looks like this was fixed in 8.4, and FreeBSD (12.4) is running 9.1. Looking at it now, I see that I also had to disable the Subsection sftp part, as I sometimes redefine it in the local file. And sshd barfs on duplicate Subsections. Yes, this can be another problem. Cannot speak of sshd because I never used Include with it but there are problems with e.g. sudoers.d or syslog.d included files - sometimes there cannot be redefinitions or the order of directives matters. Kind regards Miroslav Lachman
zfs list output RELENG_13 vs RELENG_14
Hi all, Just wondering if this change in output was on purpose or accidental. It breaks telegraf parsing for one thing, perhaps other scripts as well. In RELENG_13 we have zfs list -Hp -o name,avail,used,usedsnap,usedds zfs list -Hp -o name,avail,used,usedsnap,usedds cageroot 723864289280 216733548544 0 98304 cageroot/ROOT 723864289280 17766383616 0 98304 cageroot/ROOT/default 723864289280 17766285312 0 17766285312 cageroot/tmp 723864289280 21332996096 0 21332996096 cageroot/usr 723864289280 124012130304 0 98304 ... vs releng_14 # zfs list -Hp -o name,avail,used,usedsnap,usedds zroot 10016657408 15467933696 - - zroot/ROOT 10016657408 4927225856 - - zroot/ROOT/default 10016657408 4926791680 - - zroot/home 10016657408 778240 - - zroot/tmp 10016657408 589824 - - zroot/usr 10016657408 10526662656 - - zroot/usr/obj 10016657408 430080 - - zroot/usr/ports 10016657408 10525368320 - - with the dashes for zero values. ---Mike
Re: zfs list output RELENG_13 vs RELENG_14
On 20/10/2023 14:08, mike tancsa wrote: Hi all, Just wondering if this change in output was on purpose or accidental. It breaks telegraf parsing for one thing, perhaps other scripts as well. In RELENG_13 we have It is wrong or the man page is outdated. zfs-list(8) still shows -H Used for scripting mode. Do not print headers and separate fields by a single tab instead of arbitrary white space. -p Display numbers in parsable (exact) values. zfs list -Hp -o name,avail,used,usedsnap,usedds zfs list -Hp -o name,avail,used,usedsnap,usedds cageroot 723864289280 216733548544 0 98304 cageroot/ROOT 723864289280 17766383616 0 98304 cageroot/ROOT/default 723864289280 17766285312 0 17766285312 cageroot/tmp 723864289280 21332996096 0 21332996096 cageroot/usr 723864289280 124012130304 0 98304 ... vs releng_14 # zfs list -Hp -o name,avail,used,usedsnap,usedds zroot 10016657408 15467933696 - - zroot/ROOT 10016657408 4927225856 - - zroot/ROOT/default 10016657408 4926791680 - - zroot/home 10016657408 778240 - - zroot/tmp 10016657408 589824 - - zroot/usr 10016657408 10526662656 - - zroot/usr/obj 10016657408 430080 - - zroot/usr/ports 10016657408 10525368320 - - with the dashes for zero values. Kind regards Miroslav Lachman
Re: zfs list output RELENG_13 vs RELENG_14
On 10/20/2023 11:12 AM, Miroslav Lachman wrote: On 20/10/2023 14:08, mike tancsa wrote: Hi all, Just wondering if this change in output was on purpose or accidental. It breaks telegraf parsing for one thing, perhaps other scripts as well. In RELENG_13 we have It is wrong or the man page is outdated. zfs-list(8) still shows -H Used for scripting mode. Do not print headers and separate fields by a single tab instead of arbitrary white space. -p Display numbers in parsable (exact) values. This feels like a bug. Actually, I think there might be 2 bugs here. Its not actually showing the snapshot usage. I will start a separate thread for that. zfs list -Hp -o name,avail,used,usedsnap,usedds zfs list -Hp -o name,avail,used,usedsnap,usedds cageroot 723864289280 216733548544 0 98304 cageroot/ROOT 723864289280 17766383616 0 98304 cageroot/ROOT/default 723864289280 17766285312 0 17766285312 cageroot/tmp 723864289280 21332996096 0 21332996096 cageroot/usr 723864289280 124012130304 0 98304 ... vs releng_14 # zfs list -Hp -o name,avail,used,usedsnap,usedds zroot 10016657408 15467933696 - - zroot/ROOT 10016657408 4927225856 - - zroot/ROOT/default 10016657408 4926791680 - - zroot/home 10016657408 778240 - - zroot/tmp 10016657408 589824 - - zroot/usr 10016657408 10526662656 - - zroot/usr/obj 10016657408 430080 - - zroot/usr/ports 10016657408 10525368320 - - with the dashes for zero values. Kind regards Miroslav Lachman
Re: zfs list output RELENG_13 vs RELENG_14
On 10/20/2023 11:25 AM, mike tancsa wrote: On 10/20/2023 11:12 AM, Miroslav Lachman wrote: On 20/10/2023 14:08, mike tancsa wrote: Hi all, Just wondering if this change in output was on purpose or accidental. It breaks telegraf parsing for one thing, perhaps other scripts as well. In RELENG_13 we have It is wrong or the man page is outdated. zfs-list(8) still shows -H Used for scripting mode. Do not print headers and separate fields by a single tab instead of arbitrary white space. -p Display numbers in parsable (exact) values. This feels like a bug. Actually, I think there might be 2 bugs here. Its not actually showing the snapshot usage. I will start a separate thread for that. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274613 Opened ---Mike
14-Stable: Cannot load DRM kernel module
Hi everyone, yesterday, I updated to stable/14 and now I'm facing the problem that I cannot load the DRM kernel modules. After upgrading, I replaced graphics/drm-510-kmod with graphics/drm-515-kmod. I have the following DRM kmod related ports installed: drm-515-kmod-5.15.118 gpu-firmware-radeon-kmod-cedar-20220511 Upon loading radeonkms.ko, I get the following output in dmesg: KLD drm.ko: depends on linuxkpi_hdmi - not available or version mismatch linker_load_file: /boot/modules/drm.ko - unsupported file type KLD radeonkms.ko: depends on drmn - not available or version mismatch linker_load_file: /boot/modules/radeonkms.ko - unsupported file type I have the following kernel modules in /boot/modules # ls -ltr /boot/modules total 6987 -r-xr-xr-x 1 root wheel 501032 Jul 21 20:24 vboxdrv.ko -r-xr-xr-x 1 root wheel 15840 Jul 21 20:24 vboxnetadp.ko -r-xr-xr-x 1 root wheel 34328 Jul 21 20:24 vboxnetflt.ko -r-xr-xr-x 1 root wheel 18000 Oct 20 14:31 radeon_CEDAR_me_bin.ko -r-xr-xr-x 1 root wheel 16992 Oct 20 14:31 radeon_CEDAR_pfp_bin.ko -r-xr-xr-x 1 root wheel 15584 Oct 20 14:31 radeon_CEDAR_rlc_bin.ko -r-xr-xr-x 1 root wheel 36400 Oct 20 14:31 radeon_CEDAR_smc_bin.ko -r-xr-xr-x 1 root wheel 51072 Oct 20 20:58 dmabuf.ko -r-xr-xr-x 1 root wheel 92136 Oct 20 20:58 ttm.ko -r-xr-xr-x 1 root wheel 891984 Oct 20 20:58 drm.ko -r-xr-xr-x 1 root wheel 8581760 Oct 20 20:58 amdgpu.ko -r-xr-xr-x 1 root wheel 2394600 Oct 20 20:58 radeonkms.ko -r-xr-xr-x 1 root wheel 3013712 Oct 20 20:58 i915kms.ko -rw-r--r-- 1 root wheel 11396 Oct 20 20:58 linker.hints # I'm currently running a GENERIC kernel with added 'device iic'. uname -a reports FreeBSD x.y.z.de 14.0-STABLE FreeBSD 14.0-STABLE #1 stable/14-n265543-68513b4102dc-dirty: Fri Oct 16:38:55 CEST 2023 r...@x.y.z.de:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Where do I get the missing linuxkpi_hdmi kernel module from? What am I missing here? I would appreciate it if somebody could point me in the right direction. Thanks! Philipp
Re: 14-Stable: Cannot load DRM kernel module
Am 20.10.2023 um 21:01 schrieb Philipp-Joachim Ost: > Where do I get the missing linuxkpi_hdmi kernel module from? Follow-up: root cause was a case of PEBKAC. I had a MODULES_OVERRIDE rule in /etc/make.conf that prevented building the linuxkpi* kernel modules. It's working now. Sorry for the noise. Philipp
FreeBSD 14.0-RC2 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The second RC build of the 14.0-RELEASE release cycle is now available. Installation images are available for: o 14.0-RC2 amd64 GENERIC o 14.0-RC2 i386 GENERIC o 14.0-RC2 powerpc GENERIC o 14.0-RC2 powerpc64 GENERIC64 o 14.0-RC2 powerpc64le GENERIC64LE o 14.0-RC2 powerpcspe MPC85XXSPE o 14.0-RC2 armv7 GENERICSD o 14.0-RC2 aarch64 GENERIC o 14.0-RC2 aarch64 RPI o 14.0-RC2 aarch64 PINE64 o 14.0-RC2 aarch64 PINE64-LTS o 14.0-RC2 aarch64 PINEBOOK o 14.0-RC2 aarch64 ROCK64 o 14.0-RC2 aarch64 ROCKPRO64 o 14.0-RC2 riscv64 GENERIC o 14.0-RC2 riscv64 GENERICSD Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/releases/ISO-IMAGES/14.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use Git to do a source based update of an existing system, use the "releng/14.0" branch. A summary of changes since 14.0-RC1 includes: o OpenSSH has been updated to version 9.5p1. o OpenSSL has been updated to version 3.0.11. o Various VFS-related fixes. o OpenZFS has been updated to zfs-2.2-release. o Support for ZFS-backed Azure images has been implemented. o A crash with smartpqi(4) or mpi3mr(4) devices has been resolved. o An issue building virtual machine images for GCE has been resolved. o And various other miscellaneous fixes. A list of changes since 13.2-RELEASE is available in the releng/14.0 release notes: https://www.freebsd.org/releases/14.0R/relnotes/ Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 14.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD download mirrors): https://download.freebsd.org/releases/VM-IMAGES/14.0-RC2/ BASIC-CI images can be found at: https://download.freebsd.org/releases/CI-IMAGES/14.0-RC2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/amd64/base/ufs/14.0/RC2 /aws/service/freebsd/amd64/base/zfs/14.0/RC2 /aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC2 /aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC2 FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/aarch64/base/ufs/14.0/RC2 /aws/service/freebsd/aarch64/base/zfs/14.0/RC2 /aws/service/freebsd/aarch64/cloud-init/ufs/14.0/RC2 /aws/service/freebsd/aarch64/cloud-init/zfs/14.0/RC2 === Vagrant Images === FreeBSD/amd64 images are not available for this build, and are expected to be available next week. === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64, i386, and aarch64 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 14.0-RC2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again
