Re: Loader needs to be updated message
On Sat, 7 Sep 2024 21:31:21 -0600 Warner Losh wrote: > On Sat, Sep 7, 2024, 9:16 PM Tomoaki AOKI wrote: > > > On Sat, 7 Sep 2024 19:38:47 -0700 > > Mark Millard wrote: > > > > > void wrote on > > > Date: Sat, 07 Sep 2024 17:27:00 UTC : > > > > > > > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote: > > > > > > > > >I'm more interested in what is there than just what is not > > > > >there. May be show something analogous to: > > > > > > > > > ># gpart list | grep -E '(Name|type|efi|media)' > > > > >1. Name: mmcsd1s1 > > > > > efimedia: HD(1,MBR,,0x8000,0x3b68000) > > > > > rawtype: 12 > > > > > type: fat32lba > > > > >1. Name: mmcsd1 > > > > >1. Name: da0p1 > > > > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x82000) > > > > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > > label: BPIM3efi > > > > > type: efi > > > > >2. Name: da0p2 > > > > > efimedia: > > HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000) > > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > > type: freebsd-swap > > > > >3. Name: da0p3 > > > > > efimedia: > > HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800) > > > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > > > type: freebsd-swap > > > > >4. Name: da0p4 > > > > > efimedia: > > HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c0) > > > > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > > > > > type: freebsd-ufs > > > > >1. Name: da0 > > > > > > > > > >I'll note that on various type of systems, the (effectively) > > > > >ESP need not be specifically of "type: efi", possibly some > > > > >fat variant instead also works. (Of course, EFI need not be > > > > >the only alternative for various type of contexts.) > > > > > > > > > >I'll note the /boot/efi is normally just an empty directory > > > > >that is possibly used as a mount point. > > > > > > > > > >In some (somewhat older) configurations /boot/msdos is > > > > >similarly an empty directory and possibly used as the mount > > > > >point instead. > > > > > > > > > >> After source building to latest stable in the usual way, same error > > message 'loader needs updating'. > > > > > > > > This is on the guest > > > > > > > > # gpart list | grep -E '(Name|type|efi|media)' > > > > 1. Name: vtbd0p1 > > > > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400) > > > > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f > > > > type: freebsd-boot > > > > > > As I understand it, that "type: freebsd-boot" means that one of > > > the likes of: > > > > > > # ls -lodT /boot/gpt*boot* > > > -r--r--r-- 1 root wheel uarch 62139 Apr 7 15:55:46 2024 /boot/gptboot > > > -r-xr-xr-x 1 root wheel uarch 109568 Apr 7 15:55:46 2024 > > /boot/gptboot.efi > > > -r--r--r-- 1 root wheel uarch 176062 Apr 8 01:15:54 2024 > > /boot/gptzfsboot > > > > > > is in use inside that freebsd-boot partition (vtbd0p1). But only > > > one of those supports zfs. > > > > > > Fair warning that I never use any of those 3 --nor freebsd-boot > > > partitions. Nor have I ever used Bhyve. Do not blindly believe what I > > > report here. But hopefully it points in a useful direction to > > > initially investigate. > > > > > > Looking at: > > > > > > "man 8 gptboot.efi" indicates that "gptboot.efi works only with UFS > > > root file systems". > > > > > > "man 8 gptboot" indicates that "gptboot is used on BIOS-based > > > computers to boot from a UFS partition on a GPT-partitioned disk". > > > > > > BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based > > > computers to boot from a filesystem in a ZFS pool". > > > > > > So the partitioning is not set up for supporting the combination of: > > > EFI and ZFS-for-root-filesystem: if the gptzfsboot is u
Re: Loader needs to be updated message
On Sat, 7 Sep 2024 19:52:53 -0700 Mark Millard wrote: > Tomoaki AOKI wrote on > Date: Sun, 08 Sep 2024 01:54:28 UTC : > > > On Sun, 8 Sep 2024 02:01:02 +0100 > > void wrote: > > > > > On Sun, Sep 08, 2024 at 09:23:02AM +0900, Tomoaki AOKI wrote: > > > > > > . . . > > > > If not automounted, you can mount ESP manually as msdosfs there, at > > least for bare-metal host. IIUC, recent installation by bsdinstall > > creates fstab entry for it by default. > > void previously reported: > > QUOTE > # gpart list | grep -E '(Name|type|efi|media)' > 1. Name: vtbd0p1 > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400) > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f > type: freebsd-boot > 2. Name: vtbd0p2 > efimedia: HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200) > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > type: freebsd-swap > 3. Name: vtbd0p3 > efimedia: HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000) > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b > type: freebsd-zfs > 1. Name: vtbd0 > END QUOTE > > There is no ESP present in the guest. Instead there is a > "type: freebsd-boot" partition for which one of the likes of: > > # ls -lodT /boot/gpt*boot* > -r--r--r-- 1 root wheel uarch 62139 Apr 7 15:55:46 2024 /boot/gptboot > -r-xr-xr-x 1 root wheel uarch 109568 Apr 7 15:55:46 2024 /boot/gptboot.efi > -r--r--r-- 1 root wheel uarch 176062 Apr 8 01:15:54 2024 /boot/gptzfsboot > > would be in use. None of the 3 support the combination EFI and > ZFS-for-root-file-system. The only one of those 3 supporting zfs > is: gptzfsboot > It is documented to only supports old style BIOS context: > > "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based > computers to boot from a filesystem in a ZFS pool". > > gptboot and gptboot.efi only support UFS according to their man > pages. > > If EFI is in use, then the ESP-ish partition is not from the guest > context but from some place else --unless the man pages are wildly > wrong about what is supported for the gpt*boot 's. > > === > Mark Millard > marklmi at yahoo.com Ah, I've overlooked that. Thanks. So boot1.efi is not usable here just as gptboot.efi. gptzfsboot is the only bootcode for freebsd-boot partition on GPT which supports ZFS, and corresponding loader WAS zfsloader but IIRC ZFS support IS now incorporated into loader[_lua|_4th]. -- Tomoaki AOKI
Re: Loader needs to be updated message
On Sat, 7 Sep 2024 19:38:47 -0700 Mark Millard wrote: > void wrote on > Date: Sat, 07 Sep 2024 17:27:00 UTC : > > > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote: > > > > >I'm more interested in what is there than just what is not > > >there. May be show something analogous to: > > > > > ># gpart list | grep -E '(Name|type|efi|media)' > > >1. Name: mmcsd1s1 > > > efimedia: HD(1,MBR,,0x8000,0x3b68000) > > > rawtype: 12 > > > type: fat32lba > > >1. Name: mmcsd1 > > >1. Name: da0p1 > > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x82000) > > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > label: BPIM3efi > > > type: efi > > >2. Name: da0p2 > > > efimedia: HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000) > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > type: freebsd-swap > > >3. Name: da0p3 > > > efimedia: > > > HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800) > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > > type: freebsd-swap > > >4. Name: da0p4 > > > efimedia: > > > HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c0) > > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > > > type: freebsd-ufs > > >1. Name: da0 > > > > > >I'll note that on various type of systems, the (effectively) > > >ESP need not be specifically of "type: efi", possibly some > > >fat variant instead also works. (Of course, EFI need not be > > >the only alternative for various type of contexts.) > > > > > >I'll note the /boot/efi is normally just an empty directory > > >that is possibly used as a mount point. > > > > > >In some (somewhat older) configurations /boot/msdos is > > >similarly an empty directory and possibly used as the mount > > >point instead. > > > > > >> After source building to latest stable in the usual way, same error > > >> message 'loader needs updating'. > > > > This is on the guest > > > > # gpart list | grep -E '(Name|type|efi|media)' > > 1. Name: vtbd0p1 > > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400) > > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f > > type: freebsd-boot > > As I understand it, that "type: freebsd-boot" means that one of > the likes of: > > # ls -lodT /boot/gpt*boot* > -r--r--r-- 1 root wheel uarch 62139 Apr 7 15:55:46 2024 /boot/gptboot > -r-xr-xr-x 1 root wheel uarch 109568 Apr 7 15:55:46 2024 /boot/gptboot.efi > -r--r--r-- 1 root wheel uarch 176062 Apr 8 01:15:54 2024 /boot/gptzfsboot > > is in use inside that freebsd-boot partition (vtbd0p1). But only > one of those supports zfs. > > Fair warning that I never use any of those 3 --nor freebsd-boot > partitions. Nor have I ever used Bhyve. Do not blindly believe what I > report here. But hopefully it points in a useful direction to > initially investigate. > > Looking at: > > "man 8 gptboot.efi" indicates that "gptboot.efi works only with UFS > root file systems". > > "man 8 gptboot" indicates that "gptboot is used on BIOS-based > computers to boot from a UFS partition on a GPT-partitioned disk". > > BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based > computers to boot from a filesystem in a ZFS pool". > > So the partitioning is not set up for supporting the combination of: > EFI and ZFS-for-root-filesystem: if the gptzfsboot is used then it > needs to be old style BIOS-and-ZFS for the context. > > So my expectation here is that the gptzfsboot content in use in > vtbd0p1 (i.e. -i 1 vtbd0 in some commands) is out of date and needs > to be updated. To my knowledge, there is no simple technique to look > up the vintage present in -i 1 vtbd0 . > > I have no clue which of the following should be used for your context > to be sure that the content ends up up to date: > > The Protective MBR variant: > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0 > > The variant for without the Protective MBR: > # gpart bootcode -p /boot/gptzfsboot -i 1 vtbd0 > > Those commands are adjusted variations of what the man page's EXAMPLES > section shows, but not using the 2 example's ada0 notation. > > > 2. Name: vtbd0p2 > > efimedia: HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200) > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b > > type: freebsd-swap > > 3. Name: vtbd0p3 > > efimedia: HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000) > > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b > > type: freebsd-zfs > > 1. Name: vtbd0 > > > === > Mark Millard > marklmi at yahoo.com FYI: boot1.efi works with ZFS. gptboot.efi is basically the one which stripped ZFS-related codes from boot1.efi. And IIUC, boot1.efi shares most codes with loader.efi (except for its own FS module wrapper as a consumer, implemented for UFS and ZFS). It would be deleted in the future (that is your plan, Warner?), but currently still usable. -- Tomoaki AOKI
Re: Loader needs to be updated message
On Sun, 8 Sep 2024 02:01:02 +0100 void wrote: > On Sun, Sep 08, 2024 at 09:23:02AM +0900, Tomoaki AOKI wrote: > > >Can it be in reverse? > > > >I've not read (even if it's already provided somewhere or attached) the > >vmrun.sh script, but isn't there any possibility that it somehow > >uses loader on bare-metal (regardless on /boot/ or on ESP) to kick the > >guests? > >If so, version mismatch happenes, but newer kicks older. > >But yes, usually it is not at all the problem, as newer loader codes in > >same interpreter (lua/4th) is keeping backward compatibilities, I guess. > > > >Another case is that void already stated that > > > >>>In such a case, you might need something like: > >>> > >>># cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi > >> > >>and the error is gone!!! TYVM > > > >in another mail in this thread [1]. > > I should have made it clearer, in that other case, i did > # cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootaa64.efi > as it was an arm64 context > > >This could mean that efi/freebsd/loader.efi in ESP is not called by > >the UEFI firmware and efi/BOOT/efi/bootx64.efi is used instead. > > In *this* amd64 case, neither the -current server running bhyve > nor the 13.4-stable guest have bootx64.efi present. > > /boot/efi is empty on both the server and the guest. If not automounted, you can mount ESP manually as msdosfs there, at least for bare-metal host. IIUC, recent installation by bsdinstall creates fstab entry for it by default. -- Tomoaki AOKI
Re: Loader needs to be updated message
On Sat, 7 Sep 2024 17:07:23 -0600 Warner Losh wrote: > On Sat, Sep 7, 2024 at 12:24 PM void wrote: > > > On Sat, Sep 07, 2024 at 11:47:12AM -0600, Warner Losh wrote: > > >Wait. On the guest? > > > > > >Then what's the VM system you're using? > > > > > >Warner > > > > Bhyve. > > > > The server is freebsd-current. The guest is 13.2-stable. > > I see the error in the ascii beastie menu when booting the guest > > with vmrun.sh > > > > Hmmm, So somehow we're using the guest's boot loader and > the host's /boot/lua files then, I think. Uggg. > > Warner Can it be in reverse? I've not read (even if it's already provided somewhere or attached) the vmrun.sh script, but isn't there any possibility that it somehow uses loader on bare-metal (regardless on /boot/ or on ESP) to kick the guests? If so, version mismatch happenes, but newer kicks older. But yes, usually it is not at all the problem, as newer loader codes in same interpreter (lua/4th) is keeping backward compatibilities, I guess. Another case is that void already stated that >>In such a case, you might need something like: >> >># cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi > >and the error is gone!!! TYVM in another mail in this thread [1]. This could mean that efi/freebsd/loader.efi in ESP is not called by the UEFI firmware and efi/BOOT/efi/bootx64.efi is used instead. [1] https://lists.freebsd.org/archives/freebsd-current/2024-September/006372.html -- Tomoaki AOKI
Re: Loader needs to be updated message
On Fri, 6 Sep 2024 09:00:58 -0600 Warner Losh wrote: > On Fri, Sep 6, 2024, 8:44 AM void wrote: > > > On Fri, Sep 06, 2024 at 08:25:16AM -0600, Warner Losh wrote: > > >On Fri, Sep 6, 2024 at 8:13 AM void wrote: > > > > > >> Hi, > > >> > > >> when booting -current (arm64) after building world & friends and > > rebooting, > > >> the beastie menu shows "Loader needs to be updated". > > >> > > >> I presume this to be gptzfsboot because the system is root-on-zfs. > > >> > > >> The issue I'm having is that I can't see in the manpage how to actually > > >> update it. > > >> > > >> The system uses GELI encryption for zfs. i don't want to break this. > > >> > > > > > >Loader, not boot. /boot/loader or loader.efi does not match (is older than > > >and doesn't has the wrong version) the lua scripts. That needs to be > > >updated. > > > > > >Almost always this means 'you didn't update the ESP' which usually isn't > > >a problem, but can be across major (or multiple major) releases. > > > > > >Warner > > > > Hi Warner, > > > > some more context which I'm sorry I forgot to add > > > > source upgrade on a rpi4 (arm64) from n271321-9ae91f59c500 (28th July) to > > n271832-04262ed78d23 > > (today - this machine follows stablisation week) > > > > How is /boot/loader and/or loader.efi updated? > > What is ESP in this context? > > > > man loader.efi has the instructions. > > Warner Some additional explanation. Before, loader.efi itself could not be kicked directly from UEFI firmware and needs boot1.efi to kick loader.efi. In this case, boot code in ESP (uEFI System Partition, formatted with FAT32, 16 or possibly 12) was completely different with /boot/loader.efi. But now (by default for new UEFI installations), loader.efi can be kicked directly by UEFI firmware if it is put with proper directory and name in ESP. This would be what confusing you. With `make installworld` or usual freebsd-update, everything need updating in /boot/ should be updated, but nothing in ESP is updated automatically. This causes what you're experiencing. Unfortunately, how loader.efi should be installed in ESP depends on the environment it is installed. Old or buggy UEFI firmware could force you installing it as, for example for amd64, BOOT/EFI/BOOTx64.EFI in ESP to work, but usually BOOT/FreeBSD/loader.efi would work if UEFI boot manager is properly configured for it. Some would need ESP on all drives and keep all of them in sync. Yes, hard to automate properly for every possible situations, unlike /boot/. -- Tomoaki AOKI
Re: A few good ports on release iso images ?
On Sat, 10 Aug 2024 09:02:13 -0700 (PDT) "Rodney W. Grimes" wrote: > > Shawn Webb writes: > > > > > While probably less efficient than just running the tools outright, I > > > usually just set up a tmpfs that I chroot into and install those kinds > > > of packages. > > > > Yeah, I do something similar, with the footnote that I more often than > > not have no internet connection, so I have to remember to bring the > > packages. > > Build yourself a full release on USB and just be done with it. > The project keeps deleting stuff from base I find very useful, > I have given up on releases as a tool, I build a stick install > and tweak all the things I need, image it "just in case" and > keep it around for emergencies, and daily special use. > > A new stick is created for each release. > > > -- > Rod Grimes rgri...@freebsd.org Currently, IIRC, DVD image contains at least some of pkgs, while other images contains none. What would be useful for ALL images would be: *ports-mgmt/pkg, *All (at least, network interface ones) kmod ports which are allowed by their license and built with exactly the same src tree as the release itself. In some cases, any of kmod ports are needed to get internet access working, especially relatively new notebooks. What's important is, as already noted above, the bundled kmod ports SHALL be built with the kernel to be installed, exactly. For *.0 releases, there should be no problem with official pkgs. But for *.1 and later, official pkgs are built against oldest supported release of the corresponding stable branch, thus cause failing to kldload. Basically, my opinion is to force kmod ports to be always built from ports and stop providing official pkgs for them, but the above is the only exception. Internet access is needed to obtain/sync ports tree and distfiles to build. So kmods for "bootstrapping" would be important. For example, I've recently found this thread on forums.freebsd.org. [1] [1] https://forums.freebsd.org/threads/new-system-hardware-supported.93574/ -- Tomoaki AOKI
Re: filemon
On Tue, 30 Jul 2024 19:22:31 +0800
Alastair Hogge wrote:
>
>
> On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
> >On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> >> Gary Jennejohn writes:
> >
> >[..]
> >
> >>> I also load it from /boot/loader.conf using filemon_load="YES"
> >>
> >> This does cause the module to be loaded at boot time, but it's slower
> >> than loading it later, and it increases memory fragmentation. A better
> >> option is to include "filemon" in the kld_list variable in /etc/rc.conf
> >> or /etc/rc.conf.d/kld. For instance,
> >>
> >> % cat /etc/rc.conf.d/kld/filemon
> >> kld_list="${kld_list} filemon"
> >
> >Does this also apply today? I recently read from someone on a mailing list
> >that the kld_list in rc.conf is no longer needed, that any problems it used
> >to solve are solved, and that the preferred way is to load everything from
> >loader.conf.
>
> Was it the following mail from Warner on a relates commit?
>
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-May/024029.html
>
> --
> Sent from a device with a tiny bloody screen and no hard keyboard; please
> excuse my brevity.
Seems to be related to me, but only with single aspect, loading speed.
Another aspect is that loading multiple too large modules easily makes
boots crash. Staging area (memory region which loader allocates to load
kernel and modules, and maybe configured buffers) is limited.
Loading zfs.ko and GPU drivers (drm.ko, nvidia-drm.ko,
nvidia-modeset.ko, nvidia.ko and so on) via /boot/loader.conf[.loal]
alltogether easily makes boot to crash on module loads.
A few of examples related: Bug 277967 [1], Bug 277364 [2],
Bug 277827 [3]
You would find much, much more on forums.freebsd.org.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277967
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277364
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277827
--
Tomoaki AOKI
Re: exited on signal 11 (no core dump - other error)
On Fri, 12 Jul 2024 14:35:15 +0200 Miroslav Lachman <000.f...@quip.cz> wrote: > On 12/07/2024 11:56, Tomoaki AOKI wrote: > > On Fri, 12 Jul 2024 10:20:19 +0200 > > Miroslav Lachman <000.f...@quip.cz> wrote: > > [..] > > >> Something similar happens to me, but when logging into KDE Plasma. > >> Sometimes it happens that desktop applications that start from a saved > >> session (Firefox, Thunderbird, Telegram, Signal...) start loading and > >> then everything crashes. The login screen reappears and when I log in > >> again, everything crashes again until I restart the machine. The machine > >> gets into this state randomly, about once a week. > >> > >> Jul 5 12:24:52 xxx kernel: pid 1647 (packagekitd), jid 0, uid 0: exited > >> on signal 11 (core dumped) > >> Jul 5 12:25:28 xxx kernel: pid 1897 (kalarm), jid 0, uid 1001: exited > >> on signal 6 (core dumped) > >> Jul 5 12:25:36 xxx kernel: pid 1467 (Xorg), jid 0, uid 0: exited on > >> signal 6 (core dumped) > >> Jul 5 12:25:37 xxx kernel: pid 1772 (signal-desktop), jid 0, uid 1001: > >> exited on signal 5 (core dumped) > >> Jul 5 12:25:39 xxx pulseaudio[1630]: [] core-util.c: Failed to create > >> secure directory (/var/run/user/1001/pulse): No such file or directory > >> Jul 5 12:25:40 xxx kernel: pid 1776 (audacious), jid 0, uid 1001: > >> exited on signal 6 (core dumped) > >> Jul 5 12:25:41 xxx kernel: pid 1915 (drkonqi), jid 0, uid 1001: exited > >> on signal 6 (core dumped) > >> Jul 5 12:25:42 xxx kernel: pid 1914 (kwin_x11), jid 0, uid 1001: exited > >> on signal 6 (core dumped) > >> > >> My system is 13.3-p3 amd64. > >> > >> Kind regards > >> Miroslav Lachman > > > > What comes in my mind is... > > > > *Hardware problem > > *Main memory (including memory slot) > > *Dedicated grhaphics memories, if any > > (seems that X-related processes are crashing) > > *Power failures / instabilities > > > > *Software problem > > *Mis-alignments caused by ASLR or something > > *Bitten by uncommon bugs in fundamental libraries like libc, > > xcb, glib,... > > *Not sure it's MFC'ed to 13.x or not, but missingly determined > > instruction sets for SIMD libc or something alike. > > I also thought about the memory modules (even though they are ECC), but > a few days ago I replaced them with 4 other modules from the server and > the problem persisted. Of course it could be anything else (graphic > card, power supply, etc.), but it's strange that it only happens after > booting when logging into KDE. When everything crashes and the login > screen reappears, I try to log in again, everything crashes again > (usually in the part where Signal Desktop starts, but I don't know if > it's related). I can repeat this 5 or 10 times, but until I reboot, KDE > doesn't fully start. When I reboot, the machine runs all day, even for > several days at a time. > > It also happens that the screenlocker crashes > > Jul 11 17:32:16 xxx kernel: pid 6487 (kscreenlocker_greet), jid 0, uid > 1001: exited on signal 11 > Jul 11 17:32:16 xxx kernel: pid 6489 (kscreenlocker_greet), jid 0, uid > 1001: exited on signal 11 > > Then I have to log in as root via Ctrl+Alt+F2 and run: ck-unlock-session > Session1 > > Otherwise, when KDE is running, all applications work without crashing. > > Translated with DeepL.com (free version) > > > Kind regards > Miroslav Lachman Could MySQL related? IIRC, KDE defaulted its backend (for akonadi) to MySQL. If you're using MySQL for something other than KDE, too, and any of the database is/are heavily updated, is there any possibility that MySQL cannot flush/commit pending transactions in time? -- Tomoaki AOKI
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Tue, 4 Jun 2024 14:52:25 -0700 John Hixson wrote: > On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: > > On 16/06/2022 15:56, Rick Macklem wrote: > > > Miroslav Lachman <000.f...@quip.cz> wrote: > > > > On 24/01/2022 16:13, Rick Macklem wrote: > > > > > > > [...] > > > > > > > > > So, I think Mark and Yuri are correct and looking at up to date > > > > > Illumos sources is the next step. > > > > > (As I mentioned, porting the Apple sources is beyond what I am > > > > >willing to attempt.) > > > > > > > > > > rick > > > > > > > > Hello Rick, > > > > I would like to ask you I there is some progress with porting newer > > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a > > > > possibility where to start porting? > > > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date > > > and I agree that it should be easier than the Apple stuff to port into > > > FreeBSD. I don't think it is "straightforward" as someone involved > > > with Illumos said, due to the big differences in VFS/locking, but... > > > > > > Having said the above, I have not done much yet. I've been cleaning up > > > NFS stuff, although I am nearly done with that now. > > > I do plan on starting to work on it soon, but have no idea if/when I > > > will have something that might be useful for others. > > > > I'm glad to hear that. > > > > > > We have more and more problems with current state of mount_smbfs. I > > > > would be really glad if "somebody" can do the heroic work of > > > > implementing SMBv2 in FreeBSD. > > > > Maybe it's time to start some fundraising for sponsoring this work? > > > Well, funding isn't an issue for me (I'm just a retired guy who does this > > > stuff as a hobby). However, if there is someone else who is capable of > > > doing it if they are funded, I have no problem with that. > > > I could either help them, or simply stick with working on NFS and leave > > > SMBv23 to them. > > > > > > Sorry, but I cannot report real progress on this as yet, rick > > > > No need to sorry. I really appreciate your endless work on NFS and that you > > still have kind of interest to try porting SMBv2/3. > > Unfortunately I don't know anybody else trying to do this tremendous work. > > > > I am working on a from scratch implementation of smbfs. I do not have > any kind of time estimate since it is in my spare time. I chose this > route after spending considerable time looking at Apple and Solaris > implementations and wanting something without all of the legacy 1.0 > crap. I do have a very minimal working FUSE version at this point, but > there is much to do, and even more to abide by the various > specifications. > > I just thought I'd share in case anyone is interested. > > - John Hi! Thanks for popping in. As others already commented, this is a long awaited feature. As I've already raised a white flag to port darwin implementation, maybe I cannot help on coding, but I'd be happy to test once something to test is available. # I tried years ago with a bit of hope that the darwin code could be almost # a drop-in replacement, but it was clearly beyond me. Too many macros to # look for actual codes to see what for, functions etc which were incompatible # with FreeBSD SMB1 implementation. -- Tomoaki AOKI
Re: main cadd2ca217 doesn't boot
On Sun, 26 May 2024 00:21:31 +0100 Nuno Teixeira wrote: > Hello, > > Just upgraded to latest main at cadd2ca217 > > Boot menu shows up and then it stops earlier around: > .. > FreeBSD clang version ... > > No crash dump. > > Thanks, > > -- > Nuno Teixeira > FreeBSD UNIX: Web: https://FreeBSD.org Just a FYI: commit 40d951bc5932deb87635f5c1780a6706d0c7c012, amd64 boots fine for me. So commits after 02d15215cef2a28f1865e6ad5b19f18af1398b8b caused the problem, maybe. Regards. -- Tomoaki AOKI
Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?
On Tue, 02 Apr 2024 08:53:15 -0700 Chris wrote: > On 2024-04-02 04:32, Tomoaki AOKI wrote: > > On Tue, 02 Apr 2024 00:42:23 -0700 > > Chris wrote: > > > >> On 2024-04-01 22:51, Kevin Oberman wrote: > >> > On Mon, Apr 1, 2024 at 3:05 PM Chris wrote: > >> > > >> >> I experience challenges running FreeBSD on my Alder Lake laptop. > >> >> With some help on the list and Bugzilla, I was able to get Graphics > >> >> WiFi at least working. But still wasn't as stable as running on > >> >> more dated CPU's. As it is; I'm only able to use CURRENT. Beginning > >> >> of last week, in hopes of getting a more stable experience. I wiped > >> >> the partition (UFS) and unpacked the version available on the FreeBSD > >> >> ftp servers at that time. I quickly discovered that multi-cons (Ctrl+ > >> >> Alt+Fn || Alt+Fn) was no longer available. I posted this discovery to > >> >> the list. But no solution was discovered. I've since attempted to use > >> >> 2 more different newer versions. Both of them were also w/o multi-con(s) > >> >> support. What must I do to fix, or uncover the cause of this? > >> >> I only load the associated GPU module in rc.conf(5) (no keyboard > >> >> settings). > >> >> I'm also unable to get multi-cons booting from any of the boot media > >> >> produced within the last week. > >> >> > >> >> Following are some specifics: > >> >> > >> >> CPU: 12th Gen Intel(R) Core(TM) i3-1215U (2496.00-MHz K8-class CPU) > >> >> > >> >> IdeaPad 3 17IAU7 > >> >> > >> >> WORKS: > >> >> FreeBSD 15.0-CURRENT #0 main-n267640-7a4d1d1df0b2: > >> >> Thu Jan 18 04:04:32 UTC 2024 > >> >> > >> >> DOESN'T WORK: > >> >> FreeBSD 15.0-CURRENT #0 main-n269036-6baddb6b1176: > >> >> Fri Mar 29 10:19:43 UTC 2024 > >> >> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > >> >> amd64 > >> >> > >> >> 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 > >> >> > >> >> hostb0@pci0:0:0:0: class=0x06 rev=0x04 hdr=0x00 vendor=0x8086 > >> >> device=0x4609 subvendor=0x17aa subdevice=0x3803 > >> >> vendor = 'Intel Corporation' > >> >> class = bridge > >> >> subclass = HOST-PCI > >> >> vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 > >> >> device=0x46b3 subvendor=0x17aa subdevice=0x3b3a > >> >> vendor = 'Intel Corporation' > >> >> device = 'Alder Lake-UP3 GT1 [UHD Graphics]' > >> >> class = display > >> >> subclass = VGA > >> >> none0@pci0:0:4:0: class=0x118000 rev=0x04 hdr=0x00 vendor=0x8086 > >> >> device=0x461d subvendor=0x17aa subdevice=0x380c > >> >> vendor = 'Intel Corporation' > >> >> device = 'Alder Lake Innovation Platform Framework Processor > >> >> Participant' > >> >> class = dasp > >> >> pcib1@pci0:0:6:0: class=0x060400 rev=0x04 hdr=0x01 vendor=0x8086 > >> >> device=0x464d subvendor=0x17aa subdevice=0x380e > >> >> vendor = 'Intel Corporation' > >> >> device = '12th Gen Core Processor PCI Express x4 Controller' > >> >> class = bridge > >> >> subclass = PCI-PCI > >> >> none1@pci0:0:10:0: class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086 > >> >> device=0x467d subvendor=0x17aa subdevice=0x3813 > >> >> vendor = 'Intel Corporation' > >> >> device = 'Platform Monitoring Technology' > >> >> class = dasp > >> >> xhci0@pci0:0:13:0: class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 > >> >> device=0x461e subvendor=0x17aa subdevice=0x3824 > >> >> vendor = 'Intel Corporation' > >> >> device = 'Alder Lake-P Thunderbolt 4 USB Controller' > >> >> class =
Re: Multi cons support has disappeared (on Alder Lake) was: Alt+Fn isn't functional. Has this been removed?
; >> 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 > >> > >> > >> Thanks! > >> > >> --Chri > > > > > > I have a T16 and ran into that issue. It may be that BIOS changes have > > broken things, but I found that, by default, the F keys control volume, > > screen brightness, and many other things. I can use Fn+F[1-12] to perform > > traditional function key functions. I found that bios has an option to make > > the traditional functions the default which is how I am running today and > > have since shortly after I purchased the computer. One I set that BIOS > > option, everything worked "properly". I now use Fn+F[1-12] to adjust volume > > and screen brightness. I hope to get mute to work, but I need to figure out > > which event is set when Fn+F1 is pressed to write trivial devd support for > > it. > Well, I can't explain it. I set everything up in the BIOS to work > "traditionally" > and everything worked fine up until the upgrade. Where everything went > "south" > in the Fn department. But since you mentioned it. I thought I'd review the > settings > and sure enough, the Function key settings had changed. I have no > explanation. I > haven't been to the BIOS settings since initial setup. But only that setting > was > changed. I can't thank you enough for mentioning this, Kevin. I *really* > appreciate > your taking the time to reply! So I was correct. ;-) > > BTW, if you have not found it, Fn+K is screen lock. Most everything on my > > T16 now works with FreeBSD CURRENT. > Thanks. That was the first thing I looked for when I got it. I can't live w/o > the scrollock. Took me a bit. But I found it too. :) Another datapoint. Even on Lenovo ThinkPad series, the alternative ScrLk is different. On my ThinkPad P52, Non-existent ScrLk is mapped to Fn+B, not Fn+K. You should better reading provided PDF manual closely before ordering next time. Lenovo provides it relatively early for ThinkPads. > > Thanks again! :) > -- Tomoaki AOKI
Re: Alt+Fn isn't functional. Has this been removed?
On Fri, 29 Mar 2024 19:02:37 -0700 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 Are you sure your function keys are actually function keys? Not sure your IdeaPad is, but some Lenovo notebooks are configured function keys as special (mute, radio,...) keys by default and needs to configure in UEFI firmware to switch to function keys. If it's the case, Fn+Alt+F2 would switch to vty1. -- Tomoaki AOKI
Re: Request for Testing: TCP RACK
On Sun, 17 Mar 2024 11:40:54 -0400 "Drew Gallatin" wrote: > Resending with the patch as an attachment. > > Drew > > On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote: > > I don't have the full context, but it seems like the complaint is a > > performance regression in bonnie++ and perhaps other things when tcp_hpts > > is loaded, even when it is not used. Is that correct? > > > > If so, I suspect its because we drive the tcp_hpts_softclock() routine from > > userret(), in order to avoid tons of timer interrupts and context switches. > > To test this theory, you could apply a patch like: > > > > diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c > > index e9a16cd0b36e..54b540c97123 100644 > > --- a/sys/kern/subr_trap.c > > +++ b/sys/kern/subr_trap.c > > @@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame) > > * Software Timer Support for Network Processing" > > * by Mohit Aron and Peter Druschel. > > */ > > - tcp_hpts_softclock(); > > + /*tcp_hpts_softclock();*/ > > /* > > * Let the scheduler adjust our priority etc. > > */ > > > > > > If that fixes it, I suspect we should either make this hook optional for > > casual users of tcp_hpts(), or add some kind of "last called" timestamp to > > prevent it being called over and over and over on workloads which are > > syscall heavy. > > > > Note that for non-casual users of hpts (like Netflix, with hundreds of > > thousands of TCP connections managed by hpts), this call is a huge win, so > > I think we'd prefer that it remain in some form. > > > > Drew Controlled via RW or RWTUN sysctl/tunable? -- Tomoaki AOKI
Re: Request for Testing: TCP RACK
On Sun, 19 Nov 2023 04:01:01 +0900 Tomoaki AOKI wrote: > On Sat, 18 Nov 2023 09:50:43 +0100 > tue...@freebsd.org wrote: > > > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote: > > > > > > On Fri, 17 Nov 2023 18:51:05 +0100 > > > tue...@freebsd.org wrote: > > > > > >>> On Nov 17, 2023, at 17:06, Johan Hendriks > > >>> wrote: > > >>> > > >>> I am running the rack stack for quiet some time now on a baremetal > > >>> machiene and never had problems. > > >>> Also use pf. This is a test machine so not a lot happening on it. > > >>> > > >>> Are there any thing we can test? Do we have some test scripts we can > > >>> run? > > >> We are actually interested in feedback about using the stack in whatever > > >> use case you use TCP for. The stack has been tested with the Netflix use > > >> case, but not so much with others. That is why we ask for broader > > >> testing. > > >> > > >> Best regards > > >> Michael > > > > > > Are there any difference regarding with performance between main and > > > stable/14? If so, please ignore below. > > > > > > I have stable/14 environment which is configured to be able to switch > > > to TCP RACK and experienced huge performance loss when writing > > > a large file to smbfs share on commercial NAS. CC is cubic. > > > Testing large archive on the smbfs share doesn't seem to be > > > affected. > > > > > > Comparison between default (freebsd) and rack TCP stack using > > > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64. > > > Last 3 lines of outputs from clone (upload to NAS) are shown. > > Thank you very much for testing. This is what we are looking > > for. Would it be possible to repeat the test using NewReno as > > the CC? > > > > Best regards > > Michael > > Sure. Here we go! > > sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: freebsd > sysctl net.inet.tcp.cc.algorithm > net.inet.tcp.cc.algorithm: newreno > Umounted and remounted smbfs share. > > 1 item copied, 2343.1 MB in 37.65 s -- 62.2 MB/s > Leaked memory: 0 bytes > No errors occured. > > > sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: rack > Umounted and remounted smbfs share. > > 1 item copied, 2343.1 MB in 905.17 s -- 2.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > > sysctl net.inet.tcp.functions_default > net.inet.tcp.functions_default: freebsd > Without umount and remount to reproduce previous oddness, maybe caused > by keep-alive. > > 1 item copied, 2343.1 MB in 897.67 s -- 2.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > > Umounted and remounted, without change for CC and TCP stack. > > 1 item copied, 2343.1 MB in 37.43 s -- 62.6 MB/s > Leaked memory: 0 bytes > No errors occured. > > > All test are proceeded simultaneously. So the last one is with > CC=newreno and TCP stack=freebsd. > > Not exactly recorded, but testing transferred file by > diff -u -p -N was roughly 30MB/sec, while roughly 25MB/sec with > CC=cubic. > > > > > > > > Before switching to rack: > > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > Unmount the smbfs share, switch to rack, and after remount: > > > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > Switch back to freebsd (default) without unmounting: > > > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > Unmount and remount the smbfs share: > > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > > Leaked memory: 0 bytes > > > No errors occured. > > > > > > > > > Regards. > > > > > > -- > > > Tomoaki AOKI > > > -- > Tomoaki AOKI Just a follow up. This situation does not changed on stable/14, amd64 until commit a15b8e32942b2cbf70c7fc71e9c82d2b292e82c3. (So I've never reported again until now. Not tested on every updates.) tcphpts.ko is loaded. Note that options RATELIMIT and options TCPHPTS are dropped when changes to RACK is MFC'ed and added tcphpts_load="YES" in /boot/loader.conf instaad. Another note: Differences between CC=newreno and CC=cubic on testing transferred file seems to be just a fudge factor. both vaies mostly between the two values which I've previously reported. -- Tomoaki AOKI
Re: Removing fdisk and bsdlabel (legacy partition tools)
On Sat, 27 Jan 2024 21:52:06 -0700 Warner Losh wrote: > On Sat, Jan 27, 2024, 1:26 PM Cy Schubert wrote: > > > On January 26, 2024 7:13:15 PM PST, Ed Maste wrote: > > >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote: > > >> > > >> Probably many do, clueless there's a proposal to remove them, > > >> as many wont be tracking lists (I havent been tracking lately, > > >> focused on moving home, other will have other distractions) > > > > > >As Rod suggested I'll have the tools emit a warning when they are run, > > >so that those users will become aware. > > >https://reviews.freebsd.org/D43585 > > >https://reviews.freebsd.org/D43586 > > > > > > > We can also point people to the two new ports. > > > > The other thing we learned was that people use the installer to do > interesting things in the emergency holographic shell or the installer w/o > installing a system. We should look at ways we can shift to "mfs" so pkg > add can work in that env. Then the basis of the objections collapse. Then > it won't matter it isn't in base. Pkg add whatever recovery tools you think > you need or like to use, formerly in base or no... sure, it will go away... > but 99% of things are useful right away w/o a reboot... > > I don't think it would be a hard project... likely one that could be done > by creating a miniroot that can create the mfs, extract a tarnall to it > then pivot root to that pkg could be bootsrrapped and it would be easy > from there... > > Warner IIUC, there were opinions that "moving fidsk/bsdlabel to ports is not good, because it could require internet access even when it is not available". For there, IIRC, dvd1.iso included pre-built pkgs. So it coul be the best candidate. But IIRC, memstick.img doesn't include pre-built pkgs. Having another version of memstick.img something like full-memstick.img which contains full sets (or selected pkgs) would be nice for specific cases that hybrid media doesn't boot (maybe because of broken or too old BIOS). > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX:Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > > > > Pardon the typos. Small keyboard in use. -- Tomoaki AOKI
Re: noatime on ufs2
On Sun, 14 Jan 2024 16:13:06 -0800 Mark Millard wrote: > On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote: > > > On Sun, 14 Jan 2024 10:53:34 -0800 > > Mark Millard wrote: > > > >> On Jan 14, 2024, at 08:39, Olivier Certner wrote: > >> > >>> Hi Mark, > >>> > >>>> I never use atime, always noatime, for UFS. That said, I'd never propose > >>>> changing the long standing defaults for commands and calls. > >>> > >>> With this mail, you're giving more detailed objections on the > >>> social/political aspects of the proposed changed, or as we usually say > >>> more simply, POLA. > >>> > >>> All your points are already largely weakened by the fact that, to wrap-up > >>> in a single sentence at the risk of being slightly caricatural (but then > >>> see my other mails), nobody really seems to care seriously about access > >>> times. > >> > >> I seriously care about having a lack of access times. Yet, I've no > >> objection to needing to be explicit about it in commands and > >> subroutine interfaces, given the long standing interfaces (defaults). > >> It would be different if I could not achieve the lack of access > >> times. That defaults do not block having the desired settings makes > >> the change optional, not technically required. The defaults are, > >> thus, primarily social/political aspects of interfaces, not > >> technical requirements to make things work. > >> > >> Given that, I explicitly claim that avoiding POLA at this late stage > >> is my preference for the priority of competing considerations. I > >> make no claim of knowing the majority view of the tradeoffs. I would > >> claim that, if the majority is not by just some marginal amount, > >> contradicting that majority view for this would not be appropriate. > >> (Again: the social/political aspects.) > >> > >> And, hopefully, this is my last contribution to this particular > >> bike shed. > >> > >> === > >> Mark Millard > >> marklmi at yahoo.com > > > > I would prefer violating POLA here, with, for example, forcing admins > > to choose explicitly with installer menu > > I've not reported any objection to bsdinstall having explicit > choices required in its menus. Nor to changing how, say, > official snapshots are generated (so long as well notified > and documented). If my wording was unclear on that, I'm sorry. > > My focus was on things like mount command notation and > /etc/fstab notation (that tracks mount defaults) or subroutine > interface equivalents of such things and changing their > behavior without requiring changing the notation already in > place in various files. > > (I've tried to word the above without making new points, > avoiding contributing more to the bike shed material.) > > > Choose whether you need to retain last file access time or not: > >1: Don't keep(current default) > >2: Keep last one (default before 15.0) > > > > by hand, or via installer configuration or additional scripts. > > Of course, existing installations should not be affected. > > > > > === > Mark Millard > marklmi at yahoo.com So you mean changing behaviour of mount[_*] to default to noatime, in conjunction with configuration in /etc/fstab to default to noatime, right? So if changes are done as such, if anyone want atime active, add "-o atime" in mount[_*] command and/or "[,]atime" in /etc/fstab? -- Tomoaki AOKI
Re: noatime on ufs2
On Sun, 14 Jan 2024 10:53:34 -0800
Mark Millard wrote:
> On Jan 14, 2024, at 08:39, Olivier Certner wrote:
>
> > Hi Mark,
> >
> >> I never use atime, always noatime, for UFS. That said, I'd never propose
> >> changing the long standing defaults for commands and calls.
> >
> > With this mail, you're giving more detailed objections on the
> > social/political aspects of the proposed changed, or as we usually say more
> > simply, POLA.
> >
> > All your points are already largely weakened by the fact that, to wrap-up
> > in a single sentence at the risk of being slightly caricatural (but then
> > see my other mails), nobody really seems to care seriously about access
> > times.
>
> I seriously care about having a lack of access times. Yet, I've no
> objection to needing to be explicit about it in commands and
> subroutine interfaces, given the long standing interfaces (defaults).
> It would be different if I could not achieve the lack of access
> times. That defaults do not block having the desired settings makes
> the change optional, not technically required. The defaults are,
> thus, primarily social/political aspects of interfaces, not
> technical requirements to make things work.
>
> Given that, I explicitly claim that avoiding POLA at this late stage
> is my preference for the priority of competing considerations. I
> make no claim of knowing the majority view of the tradeoffs. I would
> claim that, if the majority is not by just some marginal amount,
> contradicting that majority view for this would not be appropriate.
> (Again: the social/political aspects.)
>
> And, hopefully, this is my last contribution to this particular
> bike shed.
>
> ===
> Mark Millard
> marklmi at yahoo.com
I would prefer violating POLA here, with, for example, forcing admins
to choose explicitly with installer menu
Choose whether you need to retain last file access time or not:
1: Don't keep(current default)
2: Keep last one (default before 15.0)
by hand, or via installer configuration or additional scripts.
Of course, existing installations should not be affected.
--
Tomoaki AOKI
Re: poudriere: swap_pager: out of swap space
On Thu, 11 Jan 2024 02:21:19 + Lexi Winter wrote: > hi list, > > i'm having a recurring problem with poudriere that i hope someone might > have an idea about. > > i'm building packages with poudriere on a system with 32GB memory, with > tmpfs and md disabled in poudriere (so it's using ZFS only) and with the > ZFS ARC limited to 8GB. > > running poudriere produces many kernel log messages like this: > > Jan 10 21:40:00 ilythia kernel: swap_pager: out of swap space > Jan 10 21:40:00 ilythia kernel: swp_pager_getswapspace(2): failed > Jan 10 22:41:55 ilythia kernel: swap_pager: out of swap space > Jan 10 22:41:55 ilythia kernel: swp_pager_getswapspace(21): failed > Jan 10 23:48:03 ilythia kernel: swap_pager: out of swap space > Jan 10 23:48:03 ilythia kernel: swp_pager_getswapspace(8): failed > Jan 11 00:05:00 ilythia kernel: swp_pager_getswapspace(1): failed > Jan 11 00:21:45 ilythia kernel: swp_pager_getswapspace(10): failed > > this is despite the system having a large amount of "Inact" memory > according to top(1): > > Mem: 3828M Active, 15G Inact, 2921M Laundry, 9263M Wired, 1559M Buf, 892M Free > ARC: 3113M Total, 994M MFU, 884M MRU, 39M Anon, 49M Header, 1139M Other > 1296M Compressed, 4130M Uncompressed, 3.19:1 Ratio > Swap: 2048M Total, 2048M Used, 8192B Free, 99% Inuse > > from what i can tell, these swap errors don't cause any issues with the > poudriere build, but they do seem to hinder interactive usage by causing > long hangs. > > does anyone have some idea what's going on here? i don't really > understand why the system has used 100% of available swap space when it > has plenty of Inact memory it could free to fulfill requirements. I'm currently building www/chromium, consuming 23.1GiB of memory and 11.4GiB of swap in use. 32GiB of physical memory but not intentionally limiting ZFS arc. If you don't build such a large ports, you could lower the number of poudriere jail with option -J, for example, from auto-tuned value to reduce memory usage. FYI: When chromium built around 87%, with USE_TMPFS=yes. 172 processes: 16 running, 156 sleeping CPU: 91.2% user, 1.5% nice, 6.7% system, 0.6% interrupt, 0.0% idle Mem: 13G Active, 1670M Inact, 6499M Laundry, 6985M Wired, 347K Buf, 3490M Free ARC: 3183M Total, 393M MFU, 2102M MRU, 2980K Anon, 34M Header, 643M Other 1826M Compressed, 3471M Uncompressed, 1.90:1 Ratio Swap: 64G Total, 12G Used, 53G Free, 18% Inuse -- Tomoaki AOKI
Re: noatime on ufs2
On Thu, 11 Jan 2024 08:36:24 +0100 Alexander Leidinger wrote: > Am 2024-01-10 22:49, schrieb Mark Millard: > > > I never use atime, always noatime, for UFS. That said, I'd never > > propose > > changing the long standing defaults for commands and calls. I'd avoid: > > [good points I fully agree on] > > There's one possibility which nobody talked about yet... changing the > default to noatime at install time in fstab / zfs set. > > I fully agree to not violate POLA by changing the default to noatime in > any FS. I always set noatime everywhere on systems I take care about, no > exceptions (any user visible mail is handled via maildir/IMAP, not > mbox). I haven't made up my mind if it would be a good idea to change > bsdinstall to set noatime (after asking the user about it, and later > maybe offer the possibility to use relatime in case it gets > implemented). I think it is at least worthwile to discuss this > possibility (including what the default setting of bsdinstall should be > for this option). > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF A different aspect of view. Nowadays, storages are quickly moving from HDD, aka spinning rust, to SSD. And SSD has a risk of sudden-death of wearing out. In ancient days, HDD dies not suddenly and at least some cases admins could have time to replace suspicious drives. But SSD dies basically suddenly. IMHO, this could be a valid reason to violate POLA. In limited use cases, atime is useful, at the cost of amplified write accesses. But in most cases, it doesn't have positive functionality nowadays. Anyway, we should have time to discuss whether it should be done or not until upcoming stable/15 branch. stable/14 is already here and it wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point to introduce this, unlike discussion about vi and ee on forums. -- Tomoaki AOKI
Re: noatime on ufs2
On Mon, 8 Jan 2024 14:12:06 -0700 Warner Losh wrote: > On Mon, Jan 8, 2024 at 1:41 PM Xin LI wrote: > > > > > > > On Sun, Jan 7, 2024 at 5:27 AM void wrote: > > > >> Hi, > >> > >> Does /var/mail still need atime? > >> > >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on > >> rpi4/8BG which installs into one / . If it's mounted with noatime, > >> will it have consequences for /var/mail ? > > > > > > It doesn't matter if you don't normally receive emails locally (nowadays, > > it's rare). > > > > If you do receive emails locally, it depends on what application(s) that > > you are using. Most applications nowadays check both mtime and atime plus > > sizes of the mailbox file and do not rely on atime (because they saved the > > previous mtime). Without atime updates, some application may claim that > > you have new mail when the mailbox is not empty when they first start. > > > > That's said, if I were you and I'm using some flash based storage (with > > rpi it's highly likely) regardless if I'm using mail locally; most of the > > time the data is not really useful for anything, and it does increase the > > wear of your storage. > > > > This reminds me that -- we probably should have implemented the Linux > > "relative atime" (update atime iff (atime <= mtime || atime <= ctime) || > > atime is older than a day) and "no diratime" (don't update directory atime) > > for UFS and make the "relatime" option the default; I had an > > incomplete implementation about a decade ago somewhere but with the recent > > VFS changes it's probably easier to start over. IMHO, updating atime every > > time when a file is accessed is not really providing useful data (like who > > accessed the file, etc.) for audit purposes and does come with performance > > (more write I/O) and reliability (wear of SSD and other flash devices) > > cost, therefore not generally useful in modern days. The Linux relative > > atime is a pretty clever idea that has covered the most useful use case for > > atime (Did I accessed the file after it was last modified) and also > > provided a coarse-grained update (capped to daily, which is a reasonable > > compromise) to the atime. > > > > I like that compromise. It will miss a lot, but that 'miss' results in > atime being good to only about a day, which for the vast majority of things > is fine. > > Warner > > > > Cheers, Looks great if possible. Maybe /usr/bin/mail would be almost all of the MUA which actually require atime and local mailboxes (under /var/mail) would usually be used for local cron-generated ones. Others would use POP or IMAP running on different computer in most cases, I think. Regards. -- Tomoaki AOKI
Re: Move u2f-devd into base?
On Mon, 8 Jan 2024 10:35:03 -0600
Kyle Evans wrote:
> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
> >> wrote:
> >>
> >>> We have FIDO/U2F support for SSH in base.
> >>>
> >>> We also have a group "u2f", 116, in the default /etc/group file.
> >>>
> >>> Why do we keep the devd configuration (to chgrp the device nodes)
> >>> in a port, security/u2f-devd? Can't we just add this to base, too?
> >>> It's just another devd configuration file.
> >>>
> >>
> >> This properly belongs to devfs.conf no? Otherwise it's a race...
> >>
> >> Warner
> >>
> >> --
> >>> Christian "naddy" Weisgerber na...@mips.inka.de
> >
> > It's devd.conf materials. It actually is security/usf-devd/files
> > u2f.conf and its contents is sets of notify 100 { match "vendor" ...
> > match "product" ... action "chgrpy u2f ..." };.
> > Some hase more items in it, though.
> >
> > So it should be in ports to adapt for latest products more quickly than
> > in base, I think.
> >
>
> I don't see any obvious reason that we can't compromise and have a
> baseline of products in base and just use the port for new products not
> yet known to base. These vendors presumably aren't going to quickly
> repurpose some PID for a non-u2f thing, much less in a way that we care
> about.
>
> Thanks,
>
> Kyle Evans
Looks reasonable to me.
Regards.
--
Tomoaki AOKI
Re: Move u2f-devd into base?
On Mon, 8 Jan 2024 08:18:38 -0700
Warner Losh wrote:
> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
> wrote:
>
> > We have FIDO/U2F support for SSH in base.
> >
> > We also have a group "u2f", 116, in the default /etc/group file.
> >
> > Why do we keep the devd configuration (to chgrp the device nodes)
> > in a port, security/u2f-devd? Can't we just add this to base, too?
> > It's just another devd configuration file.
> >
>
> This properly belongs to devfs.conf no? Otherwise it's a race...
>
> Warner
>
> --
> > Christian "naddy" Weisgerber na...@mips.inka.de
It's devd.conf materials. It actually is security/usf-devd/files
u2f.conf and its contents is sets of notify 100 { match "vendor" ...
match "product" ... action "chgrpy u2f ..." };.
Some hase more items in it, though.
So it should be in ports to adapt for latest products more quickly than
in base, I think.
--
Tomoaki AOKI
Re: git repo port issues?
On Thu, 4 Jan 2024 12:49:03 -0700 Warner Losh wrote: > On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote: > > > Tomoaki AOKI wrote: > > > > > > > > Or create database (key-value store would be sufficient) storing commit > > > order (like r* of svn) and commit hash. > > > I'm still not certain whether commit order or commit hash should be the > > > "key". Possibly store hash as the key fisrt and store assigned MONOTONIC > > > order as value, then, add the just-stored order as key and hash as > > > value in another database would be neeed. If the database can contain 2 > > > value for 1 key, it would be suitable for you to store the assigned > > > time in UTC as "when it is committed to FreeBSD master repo". > > > > I do miss the incrementing "r" value - it's a nice immediate way to > > tell which update is more recent. Actually, to me, that is more important > > than the date - I've attempted to base my changes on the date due to the > > absense of such a useful field. > > > > See sys/conf/newvers.sh for the 'n' value we use in uname strings. It's a > linear count of commits on the first-parent branch back to the start of the > repo. > > Also, the dates usualy are first order correct and i use them for the stats > i run. Though I've also just dropped tags on the first commit of each year > too... > > Also be advised that the pre FreeBSD 8 or so tree still has some surprising > artifacts in it. > > Warner What I suspect/fear is that current n* numbers are assured to same value for the same officially existing branch or not. What I want is such an assured number (order). What happenes if something lile below happened? *Accidentally commit something into local repo racking, for example, stable/14 instead of local (personal) developement branch. *Noticed before next `git pull` and revert it and commit it to correct local branch. *Pull upstream (official) updates. This case, checked-out tree would be match upstream (if no other changes are not yet done). If n* number is kept the same as upstream with situations like above, it could be VERY helpful if n* is exposed in mails automatically sent to dev-commits-* ML and somehow in cgit repo (like r* numbers for old, svn era commits). If not, what I've described in my previous post would be helpful if used for auto-post to ML and (hopefully) cgit, IMHO. Regards. > > Actually, I think I may implement such a thing on my local cgit repo. > > > > https://cgit.dyslexicfish.net/ports/latest/tree/ > > https://cgit.dyslexicfish.net/src/current/tree/ > > > > Cheers, Jamie -- Tomoaki AOKI
Re: git repo port issues?
On Wed, 3 Jan 2024 23:32:27 + Brooks Davis wrote: > On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote: > > On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote: > > > > > > Nothing about dates is centralized in git, but some server side checks > > > could be implemented on CommitDate. IMO we should require that > > > CommitDate be >= the previous one and less than "now". > > > > Given that git commit objects form a DAG, I don't see how you can > > impose linearity. > > Check each commit in a push to ensure that its CommitDate is newer than > its first parent's CommitDate (you could check them all, but as a > project we're mostly linear). Seems like a pretty trivial property to > enforce. > > -- Brooks Or create database (key-value store would be sufficient) storing commit order (like r* of svn) and commit hash. I'm still not certain whether commit order or commit hash should be the "key". Possibly store hash as the key fisrt and store assigned MONOTONIC order as value, then, add the just-stored order as key and hash as value in another database would be neeed. If the database can contain 2 value for 1 key, it would be suitable for you to store the assigned time in UTC as "when it is committed to FreeBSD master repo". Just a thought. Regards. -- Tomoaki AOKI
Re: Proposal: Disable compression of newsyslog by default
On Sat, 23 Dec 2023 15:14:20 -0800 Xin Li wrote: > On 2023-12-23 07:09, Enji Cooper wrote: > > 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. > > I appreciate your feedback! > > Thank you for pointing out the implications of this change for embedded > systems and jails using UFS. I understand your concerns, especially > regarding larger FreeBSD consumers who might still rely on UFS instead > of ZFS. > > Note that the committed change was designed to simplify code > maintenance, particularly for downstream software vendors. By reducing > the number of configuration lines in newsyslog.conf to a single line in > /etc/crontab, it makes it easier for downstream maintainers to follow > the latest FreeBSD codebase, because they don't have to manually solve > merge conflicts when someone changes newsyslog.conf anymore. This > should ease the integration and maintenance processes for these vendors. > > > 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. > > Now back to the proposed behavior change, regarding your suggestion to > change the default in the installer, I have reservations about this > approach. One of my primary motivations for this change is to move away > from using flags to specify which compression method should be used. In > my view, the software package distributed configuration should not > dictate the compression method to be used by the user. Rather, its role > should be to inform newsyslog about the suitability of a file for > compression. This shift in approach aims to provide users with greater > flexibility and autonomy in managing their compression settings. > > Cheers, I think any config files which is updated by freebsd-update and/or etcupdate and/or mergemaster should better be in /etc/defaults and any configuration in them should be able to overridden by configuration files directly under /etc, like rc.conf. Is it possible to override EVERY configurations in /etc/newsyslog.conf by any configuration files under /etc/newsyslog.conf.d and/or /usr/local/etc/newsyslog.conf.d? If so, just moving default one to /etc/defaults would help, I think, like at commit d105b00084a533f41a1277d08cfacb15062d9b50 [1]. [1] https://cgit.freebsd.org/src/commit/?id=d105b00084a533f41a1277d08cfacb15062d9b50 Regards. -- Tomoaki AOKI
Re: symlink to /boot/loader.efi
On Fri, 22 Dec 2023 12:17:15 -0700 Warner Losh wrote: > On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome wrote: > > > > > > > > On 22. Dec 2023, at 11:09, Mark Millard wrote: > > > > > > Tomoaki AOKI wrote on > > > Date: Thu, 21 Dec 2023 23:21:00 UTC : > > > > > >> On Thu, 21 Dec 2023 14:22:14 +0100 > > >> Dimitry Andric wrote: > > >> > > >>> Yeah, my procedure is the same as yours: I first copy > > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then > > copy the freshly built and installed /boot/loader.efi to > > /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this > > could not be just another step in the installworld procedure. > > >>> > > >>> That said, I am unsure if the pathname /boot/efi/efi is always the > > same, at least for all UEFI systems. It is the default layout when you do a > > regular install with recent installer onto a UEFI system, but some users > > may use completely different mount points. So you should still have some > > way of configuring the default location for loader installation. > > >>> > > >>> Also, on default installations a fallback entry named > > /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > > loader.efi but with a different name. Namely, the default name that UEFI > > (on x86_64 at least) searches for, if it doesn't know anything else. I.e. > > if it isn't configured via efibootmgr(8), or the EFI variables have been > > junked for some reason. It might make sense to also update that file. > > >>> > > >>> -Dimitry > > >> > > >> Just an idea. > > >> > > >> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > > >> "where am I placed?" info, maybe via kenv. > > >> > > >> Would need boot1.efi to pass something (ideally, "where am I booted > > >> from?", but "boot1_used=1" is sufficient). > > >> > > >> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > > >> directly from UEFI firmware. If nothing is passed to it, it can probe > > >> "where it is?" using UEFI call and set it, otherwise, it should > > >> be /boot/loader.efi, so nothing is needed to do. > > > > > > To my knowledge aarch64 and armv7 never use the copy in > > > /boot/loader.efi during a boot. It has to have been copied > > > into the appropriate msdosfs such that it has an > > > appropriate path and name there. That is what is found > > > and used during the boot. > > > > > > All UEFI systems start from ESP (EFI System Partition). The only good > > reason to install boot1.efi there is when you have very small ESP and need > > to save that space - and in that case the boot1.esp will search and execute > > /boot/loader.efi. > > > > Yes. I consider this a legacy need only. Part of the problem with 'fixing' > boot1.efi to include all the newest filesystems, crypto, etc means that it > grows too large for this use case. > > > > The problem about boot1.efi (or any other UEFI chainload) is that loading > > file and executing it will not replace current program in memory, but will > > add new one, this may be problem with systems with minimal memory > > configurations. And yes, boot1.efi is not really platform specific - it is > > just another EFI application - one can build and use it on arm (or any > > other) systems and then it will load and start /boot/loader.efi. > > > > starting loader directly from ESP has few advantages — you wont waste > > memory for boot1.efi, you save a bit of boot time, you can use auxiliary > > files from ESP to pass some information to loader.efi (for example to tell > > where your rootfs is in case of multiboot setups). > > > > the boot1.efi could be a bit more appealing if it would be able to load > > and start kernel directly, allowing to build very memory limited setups, > > but then again, it does sound like very specific corner case. > > > > Yes. boot1.efi is a bit of a special case. It originally was done as a > quick port of boot1 from powerpc and was quite small. However, as we > expanded the supported boot paths, it grew. > > And growth isn't the only problem. boot1.efi uses its own drivers and > filesystems that do leverage the base libsa stuff, but do it in slightly > different ways that loader.efi does. It also largely duplicates loa
Re: symlink to /boot/loader.efi
On Fri, 22 Dec 2023 16:15:42 +0200 Toomas Soome wrote: > > > > On 22. Dec 2023, at 16:07, Konstantin Belousov wrote: > > > > On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote: > >> > >> > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > >>> > >>> Tomoaki AOKI wrote on > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : > >>> > >>>> On Thu, 21 Dec 2023 14:22:14 +0100 > >>>> Dimitry Andric wrote: > >>>> > >>>>> Yeah, my procedure is the same as yours: I first copy > >>>>> /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, > >>>>> then copy the freshly built and installed /boot/loader.efi to > >>>>> /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why > >>>>> this could not be just another step in the installworld procedure. > >>>>> > >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the > >>>>> same, at least for all UEFI systems. It is the default layout when you > >>>>> do a regular install with recent installer onto a UEFI system, but some > >>>>> users may use completely different mount points. So you should still > >>>>> have some way of configuring the default location for loader > >>>>> installation. > >>>>> > >>>>> Also, on default installations a fallback entry named > >>>>> /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > >>>>> loader.efi but with a different name. Namely, the default name that > >>>>> UEFI (on x86_64 at least) searches for, if it doesn't know anything > >>>>> else. I.e. if it isn't configured via efibootmgr(8), or the EFI > >>>>> variables have been junked for some reason. It might make sense to also > >>>>> update that file. > >>>>> > >>>>> -Dimitry > >>>> > >>>> Just an idea. > >>>> > >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > >>>> "where am I placed?" info, maybe via kenv. > >>>> > >>>> Would need boot1.efi to pass something (ideally, "where am I booted > >>>> from?", but "boot1_used=1" is sufficient). > >>>> > >>>> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > >>>> directly from UEFI firmware. If nothing is passed to it, it can probe > >>>> "where it is?" using UEFI call and set it, otherwise, it should > >>>> be /boot/loader.efi, so nothing is needed to do. > >>> > >>> To my knowledge aarch64 and armv7 never use the copy in > >>> /boot/loader.efi during a boot. It has to have been copied > >>> into the appropriate msdosfs such that it has an > >>> appropriate path and name there. That is what is found > >>> and used during the boot. > >> > >> > >> All UEFI systems start from ESP (EFI System Partition). The only good > >> reason to install boot1.efi there is when you have very small ESP and need > >> to save that space - and in that case the boot1.esp will search and > >> execute /boot/loader.efi. > >> > > No, this is not the only good reason, or even the least important reason. > > > > boot1.efi is extremely convenient for the normal (*) configuration where > > machine is dedicated for a single FreeBSD system. It finds and chain-load > > real loader.efi from the first UFS GPT partition which I always assign to > > the root. This means that I do not need to care about updating loader.efi > > at all, it is done during normal installworld. > > > > * at least for me > > > > I use this setup for >5 years on all my disk-booting machines. > > Yes, that one is also [good] reason, however, I personally do consider it > missing feature of bectl/beadm activate;) > > rgds, > toomas Additional note. boot1.efi looks for /boot/loader.efi with the order below. This is implemented when smh@ fixed the fatal issue which disallow booting from memstick when ESP alreay exixts among internal drives. *Prefer ZFS pool over UFS (first sniff ZFS pool, if not exixts, UFS) on each drives checked. *Look for the drive which boot1.efi itself is loaded from. *If none found both on ZFS pool nor UFS, try driv
Re: symlink to /boot/loader.efi
On Fri, 22 Dec 2023 12:02:54 +0200 Toomas Soome wrote: > > On 22. Dec 2023, at 11:54, Mark Millard wrote: > > > > On Dec 22, 2023, at 01:36, Toomas Soome wrote: > >> > >> > >> > >>> On 22. Dec 2023, at 11:09, Mark Millard wrote: > >>> > >>> Tomoaki AOKI wrote on > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC : > >>> > >>>> On Thu, 21 Dec 2023 14:22:14 +0100 > >>>> Dimitry Andric wrote: > >>>> > >>>>> Yeah, my procedure is the same as yours: I first copy > >>>>> /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, > >>>>> then copy the freshly built and installed /boot/loader.efi to > >>>>> /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why > >>>>> this could not be just another step in the installworld procedure. > >>>>> > >>>>> That said, I am unsure if the pathname /boot/efi/efi is always the > >>>>> same, at least for all UEFI systems. It is the default layout when you > >>>>> do a regular install with recent installer onto a UEFI system, but some > >>>>> users may use completely different mount points. So you should still > >>>>> have some way of configuring the default location for loader > >>>>> installation. > >>>>> > >>>>> Also, on default installations a fallback entry named > >>>>> /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > >>>>> loader.efi but with a different name. Namely, the default name that > >>>>> UEFI (on x86_64 at least) searches for, if it doesn't know anything > >>>>> else. I.e. if it isn't configured via efibootmgr(8), or the EFI > >>>>> variables have been junked for some reason. It might make sense to also > >>>>> update that file. > >>>>> > >>>>> -Dimitry > >>>> > >>>> Just an idea. > >>>> > >>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass > >>>> "where am I placed?" info, maybe via kenv. > >>>> > >>>> Would need boot1.efi to pass something (ideally, "where am I booted > >>>> from?", but "boot1_used=1" is sufficient). > >>>> > >>>> To do so, loader.efi can confirm whether it was loaded via boot1.efi or > >>>> directly from UEFI firmware. If nothing is passed to it, it can probe > >>>> "where it is?" using UEFI call and set it, otherwise, it should > >>>> be /boot/loader.efi, so nothing is needed to do. > >>> > >>> To my knowledge aarch64 and armv7 never use the copy in > >>> /boot/loader.efi during a boot. It has to have been copied > >>> into the appropriate msdosfs such that it has an > >>> appropriate path and name there. That is what is found > >>> and used during the boot. > >> > >> > >> All UEFI systems start from ESP (EFI System Partition). The only good > >> reason to install boot1.efi there is when you have very small ESP and need > >> to save that space - and in that case the boot1.esp will search and > >> execute /boot/loader.efi. Or if you need the functionality the patch at Bug 207940 [1] provides, which is not yet implemented on loader.efi. ;-) [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 > > Yep. May be I misinterpreted what the text strongly tied to > > "it should be /boot/loader.efi" and so ended up not pointing > > out an actual distinction. Ah, sorry for mis-leading words. > >> The problem about boot1.efi (or any other UEFI chainload) is that loading > >> file and executing it will not replace current program in memory, but will > >> add new one, this may be problem with systems with minimal memory > >> configurations. And yes, boot1.efi is not really platform specific - it is > >> just another EFI application - one can build and use it on arm (or any > >> other) systems > > > > Not powerpc (32-bit), powerpc64, or powerpc64le: these are > > not UEFI systems at all, if I understand right. > > > Yes, building EFI application implies platform with UEFI support. > > rgds, > toomas > > > > > Of course, if only tier 1 is documented, such would not be > > covered. But docu
Re: symlink to /boot/loader.efi
On Thu, 21 Dec 2023 14:22:14 +0100 Dimitry Andric wrote: > Yeah, my procedure is the same as yours: I first copy > /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then > copy the freshly built and installed /boot/loader.efi to > /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this > could not be just another step in the installworld procedure. > > That said, I am unsure if the pathname /boot/efi/efi is always the same, at > least for all UEFI systems. It is the default layout when you do a regular > install with recent installer onto a UEFI system, but some users may use > completely different mount points. So you should still have some way of > configuring the default location for loader installation. > > Also, on default installations a fallback entry named > /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of > loader.efi but with a different name. Namely, the default name that UEFI (on > x86_64 at least) searches for, if it doesn't know anything else. I.e. if it > isn't configured via efibootmgr(8), or the EFI variables have been junked for > some reason. It might make sense to also update that file. > > -Dimitry Just an idea. It would be nice if loader.efi (hopefully, boot1.efi,too) could pass "where am I placed?" info, maybe via kenv. Would need boot1.efi to pass something (ideally, "where am I booted from?", but "boot1_used=1" is sufficient). To do so, loader.efi can confirm whether it was loaded via boot1.efi or directly from UEFI firmware. If nothing is passed to it, it can probe "where it is?" using UEFI call and set it, otherwise, it should be /boot/loader.efi, so nothing is needed to do. If no related kenv is set and freebsd-boot partition exists, it should be booted with legacy (BIOS) boot. The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI device path. So would need analyzing where actually is on booted FreeBBSD environment. > > > On 21 Dec 2023, at 13:59, Nuno Teixeira wrote: > > > > Hello Dimitry, > > > > For a moment I forgot that efiboot is a fat system... > > I am inspired on what installworld does to kernel and kernel.old. > > I was thinking in something like it but with efi boot, something automatic. > > > > Thanks! > > > > Dimitry Andric escreveu no dia quinta, 21/12/2023 à(s) > > 12:48: > > On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > > > > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and > > > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > > > For safety reasons I always have a copy of last running loader by > > > appending "-old.efi" to loader or boota64 and use beinstall to get BEs if > > > needed. > > > > > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi -> > > > /boot/loader.efi ? > > > > Symlinks do not work on FAT file systems, so I assume you mean a symlink > > placed in /boot (assuming that is UFS or ZFS), which points to > > /boot/efi/efi/freebsd? > > > > At the moment I think installworld would not write 'through' such a > > symlink. In fact, it makes a hard link from /boot/loader_lua.efi to > > /boot/loader.efi, unlinking any previous /boot/loader.efi. > > > > That said, it would be nice to have some sort of semi-official way of > > upgrading the real EFI loader through installworld. It would probably > > require some top-level Makefile magic. > > > > -Dimitry > > > > > > > > -- > > Nuno Teixeira > > FreeBSD Committer (ports) -- Tomoaki AOKI
Re: nvme timeout issues with hardware and bhyve vm's
On Thu, 7 Dec 2023 14:38:37 -0800 Pete Wright wrote: > > > On 10/13/23 7:34 PM, Warner Losh wrote: > > > > > > > the messages i posted in the start of the thread are from the VM itself > > (13.2-RELEASE). The zpool on the hypervisor (13.2-RELEASE) showed no > > such issues. > > > > Based on your comment about the improvements in 14 I'll focus my > > efforts > > on my workstation, it seemed to happen regularly so hopefully i can > > find > > a repo case. > > > > > > Let me now if you see similar messages in stable/14. I think I've fixed > > all the > > issues with timeouts, though you shouldn't ever seem them in a vm setup > > unless something else weird is going on. > > > > > Hi Warner, just resurfacing this thread because I've had a few lockups > on my workstation running 14.0-STABLE. I was able to capture a photo of > the hang and this seems to be the most important line: > > nvme0: Resetting controller due to a timeout and possible hot unplug. > > When I scan the device after reboot I don't see any errors, but if there > is a particular thing I should check via nvmecontrol please let me know. > Also, since it mentions possible hot unplug I wonder if this is > hardware/firmware related to my system? > > Anyway, haven't found a repro case yet but it has locked up a few times > the past two weeks. > > -pete > > > -- > Pete Wright > p...@nomadlogic.org If I myself encounter this kind of problem ON BARE METAL HARDWARE, I would usually suspect *Overheating caused hang of NVMe controller or PCI bridge on SSD, or *Unstable physical connection (bad contact) first. -- Tomoaki AOKI
Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource
On Sat, 25 Nov 2023 12:16:49 -0800 David Wolfskill wrote: > On Sun, Nov 26, 2023 at 04:36:33AM +0900, Tomoaki AOKI wrote: > > Hi. > > > > Not tested, but does upgrading to commit ed88eef140a1 [1] and later > > help? (I'm still at commit 5d4f897f88ed on main.) > > > > [1] > > https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 > > > > Regards. > > > > Yes; thank you (and jhb@): after hand-applying the ed88eef140a1 commit & > rebuilding, the laptop rebooted OK: > > g1-48(15.0-C)[1] uname -aUK > FreeBSD g1-48.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #530 > main-n266611-49a83b94395a-dirty: Sat Nov 25 20:04:25 UTC 2023 > r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > 154 154 > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > The notion that anyone would perceive a need to "make neo-Nazis > look bad" is about as absurd as perceiving a need to "hydrate" water. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. Glad to hear it helped. :-) And sorry, I should have noted that commit ed88eef140a1 is the next commit after 49a83b94395a, which you had been bitten by the issue. Regards. -- Tomoaki AOKI
Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource
Hi.
Not tested, but does upgrading to commit ed88eef140a1 [1] and later
help? (I'm still at commit 5d4f897f88ed on main.)
[1]
https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809
Regards.
On Sat, 25 Nov 2023 05:45:24 -0800
David Wolfskill wrote:
> After I saw this with both my headless "build machine" and a laptop (and
> verified that there were no more recent commits to main), I figured it
> might be worth reporting.
>
> This was after a source update from:
> FreeBSD 15.0-CURRENT #473 main-n266588-2a35f3cdf63d-dirty: Fri Nov 24
> 13:11:48 UTC 2023
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 154 154
>
> ("-dirty" because I had hand-applied 50335b1ae4e4:
>
> main-n266589-50335b1ae4e4
> commit 50335b1ae4e48712f831e85ddfa7b00da0af382c
> Author: Emmanuel Vadot
> Date: Fri Nov 24 11:30:09 2023 +0100
>
> sys/mutex.h: Reorder includes
>
> Fixes: 2a35f3cdf63d ("sys/mutex.h: Include sys/lock.h instead of
> sys/_lock.h")
>
> after seeing a build failure yesterday after updating to
> main-n266588-2a35f3cdf63d.)
>
> Here's a backtrace:
>
> ...
> Event timer "HPET6" frequency 14318180 Hz quality 340
> Event timer "HPET7" frequency 14318180 Hz quality 340
> panic: bus_generic_rman_activate_resource: rman 0x81b0b0e8 doesn't
> match for resource 0xf801092b9280
> cpuid = 20
> time = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82eaf8b0
> vpanic() at vpanic+0x132/frame 0x82eaf9e0
> panic() at panic+0x43/frame 0x82eafa40
> bus_generic_rman_activate_resource() at
> bus_generic_rman_activate_resource+0x146/frame 0x82eafaa0
> acpi_alloc_sysres() at acpi_alloc_sysres+0x83/frame 0x82eafae0
> acpi_alloc_resource() at acpi_alloc_resource+0x108/frame 0x82eafba0
> bus_alloc_resource() at bus_alloc_resource+0x9b/frame 0x82eafc00
> acpi_timer_probe() at acpi_timer_probe+0xaa/frame 0x82eafc80
> device_probe_child() at device_probe_child+0x16f/frame 0x82eafcd0
> device_probe() at device_probe+0x8a/frame 0x82eafcf0
> device_probe_and_attach() at device_probe_and_attach+0x32/frame
> 0x82eafd20
> bus_generic_attach() at bus_generic_attach+0x18/frame 0x82eafd40
> acpi_probe_children() at acpi_probe_children+0x226/frame 0x82eafda0
> acpi_attach() at acpi_attach+0x97b/frame 0x82eafe30
> device_attach() at device_attach+0x3bc/frame 0x82eafe70
> device_probe_and_attach() at device_probe_and_attach+0x70/frame
> 0x82eafea0
> bus_generic_attach() at bus_generic_attach+0x18/frame 0x82eafec0
> device_attach() at device_attach+0x3bc/frame 0x82eaff00
> device_probe_and_attach() at device_probe_and_attach+0x70/frame
> 0x82eaff30
> bus_generic_new_pass() at bus_generic_new_pass+0xed/frame 0x82eaff60
> bus_set_pass() at bus_set_pass+0x36/frame 0x82eaff90
> configure() at configure+0x9/frame 0x82eaffa0
> mi_startup() at mi_startup+0x1c8/frame 0x82eafff0
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stopped at kdb_enter+0x32: movq$0,0xe3cf53(%rip)
> db>
>
> I can leave this machine in this state for a few hours, so if there's
> any diagnostic information to be gained, I'm happy to do that, but I'll
> need clues as to what to do.
>
> If I can get a dump, I'm happy to make it available (but I'll hold off
> on trying that for now, as I expect the attempt could disturb evidence).
>
> Information about the machine(s) & update history may be found at
> https://www.catwhisker.org/~david/FreeBSD/history/ in case that's
> of use. (This includes a copy of /var/run/dmesg.boot from the last
> successful verbose boot, which was from yesterday.)
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> The notion that anyone would perceive a need to "make neo-Nazis
> look bad" is about as absurd as perceiving a need to "hydrate" water.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
--
Tomoaki AOKI
Re: Request for Testing: TCP RACK
On Sat, 18 Nov 2023 09:50:43 +0100 tue...@freebsd.org wrote: > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote: > > > > On Fri, 17 Nov 2023 18:51:05 +0100 > > tue...@freebsd.org wrote: > > > >>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote: > >>> > >>> I am running the rack stack for quiet some time now on a baremetal > >>> machiene and never had problems. > >>> Also use pf. This is a test machine so not a lot happening on it. > >>> > >>> Are there any thing we can test? Do we have some test scripts we can run? > >> We are actually interested in feedback about using the stack in whatever > >> use case you use TCP for. The stack has been tested with the Netflix use > >> case, but not so much with others. That is why we ask for broader testing. > >> > >> Best regards > >> Michael > > > > Are there any difference regarding with performance between main and > > stable/14? If so, please ignore below. > > > > I have stable/14 environment which is configured to be able to switch > > to TCP RACK and experienced huge performance loss when writing > > a large file to smbfs share on commercial NAS. CC is cubic. > > Testing large archive on the smbfs share doesn't seem to be > > affected. > > > > Comparison between default (freebsd) and rack TCP stack using > > sysutils/clone on stable/14 at commit 7d1321288ad9, amd64. > > Last 3 lines of outputs from clone (upload to NAS) are shown. > Thank you very much for testing. This is what we are looking > for. Would it be possible to repeat the test using NewReno as > the CC? > > Best regards > Michael Sure. Here we go! sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: freebsd sysctl net.inet.tcp.cc.algorithm net.inet.tcp.cc.algorithm: newreno Umounted and remounted smbfs share. 1 item copied, 2343.1 MB in 37.65 s -- 62.2 MB/s Leaked memory: 0 bytes No errors occured. sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: rack Umounted and remounted smbfs share. 1 item copied, 2343.1 MB in 905.17 s -- 2.6 MB/s Leaked memory: 0 bytes No errors occured. sysctl net.inet.tcp.functions_default net.inet.tcp.functions_default: freebsd Without umount and remount to reproduce previous oddness, maybe caused by keep-alive. 1 item copied, 2343.1 MB in 897.67 s -- 2.6 MB/s Leaked memory: 0 bytes No errors occured. Umounted and remounted, without change for CC and TCP stack. 1 item copied, 2343.1 MB in 37.43 s -- 62.6 MB/s Leaked memory: 0 bytes No errors occured. All test are proceeded simultaneously. So the last one is with CC=newreno and TCP stack=freebsd. Not exactly recorded, but testing transferred file by diff -u -p -N was roughly 30MB/sec, while roughly 25MB/sec with CC=cubic. > > > > Before switching to rack: > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > Unmount the smbfs share, switch to rack, and after remount: > > 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > Switch back to freebsd (default) without unmounting: > > 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > Unmount and remount the smbfs share: > > 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s > > Leaked memory: 0 bytes > > No errors occured. > > > > > > Regards. > > > > -- > > Tomoaki AOKI -- Tomoaki AOKI
Re: Request for Testing: TCP RACK
On Fri, 17 Nov 2023 18:51:05 +0100 tue...@freebsd.org wrote: > > On Nov 17, 2023, at 17:06, Johan Hendriks wrote: > > > > I am running the rack stack for quiet some time now on a baremetal machiene > > and never had problems. > > Also use pf. This is a test machine so not a lot happening on it. > > > > Are there any thing we can test? Do we have some test scripts we can run? > We are actually interested in feedback about using the stack in whatever > use case you use TCP for. The stack has been tested with the Netflix use > case, but not so much with others. That is why we ask for broader testing. > > Best regards > Michael Are there any difference regarding with performance between main and stable/14? If so, please ignore below. I have stable/14 environment which is configured to be able to switch to TCP RACK and experienced huge performance loss when writing a large file to smbfs share on commercial NAS. CC is cubic. Testing large archive on the smbfs share doesn't seem to be affected. Comparison between default (freebsd) and rack TCP stack using sysutils/clone on stable/14 at commit 7d1321288ad9, amd64. Last 3 lines of outputs from clone (upload to NAS) are shown. Before switching to rack: 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s Leaked memory: 0 bytes No errors occured. Unmount the smbfs share, switch to rack, and after remount: 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s Leaked memory: 0 bytes No errors occured. Switch back to freebsd (default) without unmounting: 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s Leaked memory: 0 bytes No errors occured. Unmount and remount the smbfs share: 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s Leaked memory: 0 bytes No errors occured. Regards. -- Tomoaki AOKI
Re: kldunload kernel: How should the kernel behave when it is requested to unload itself
On Fri, 10 Nov 2023 00:10:13 +0800 Zhenlei Huang wrote: > Hi, > > This is *NOT* joking. > > While working on https://reviews.freebsd.org/D42527 I realized the > module kernel also has userrefs, that is to say, userland can request > to unload kernel, aka `kldunload kernel`. > > This is interesting. Well no doubt that the loader can unload kernel. > Then after the kernel is loaded and has been initialized (SYSINIT), how > should it behave when it get an unload request? > > I'm proposing https://reviews.freebsd.org/D42530 to do not allow unloading > the kernel. It is by intuition. > > What do you think ? > > > Best regards, > Zhenlei Possibly too paranoid, but the summery on D42530 looks a bit confusing. Would better to be 'The userland or kernel shall not unload the module "kernel".' or 'The userland or kernel shall not unload the "kernel" module.' . The original SUMMARY could be read as, in meaning, 'The userland or kernel shall not unload *.ko.' *.ko is sometimes called as "kernel module", although it stants for "kernel object". -- Tomoaki AOKI
Re: AMD Zen 4 (Ryzen 7000) resource allocation issues (on 14.0)
On Sat, 14 Oct 2023 14:12:04 + Gary Jennejohn wrote: > On Sat, 14 Oct 2023 15:05:22 +0200 > Daniel Engberg wrote: > > > On 2023-10-14T13:07:11.000+02:00, Daniel Engberg > > wrote: > > > > > Hi, > > > > > > After updating BIOS on my Asus motherboard (ProArt X670E-CREATOR > > > WIFI) the kernel fails to allocate resources for a bunch of devices > > > including USB and built-in SATA. This behaviour is also observed on > > > at least ASRock boards too so it doesn't seem to be a specific issue > > > to one manufacturer or model. If anyone has any ideas how to fix > > > this I'd be grateful. > > > > > > I've tried turning off and on "Fast boot" in BIOS without any > > > success, enabing SR-IOV makes the kernel hang during boot. > > > > > > dmesg with older bios (working): > > > > > > > > >https://forums.freebsd.org/threads/sata-drives-show-in-bios-but-wont-show-in-dev.89656/page-2#post-620854 > > > > > > dmesg with new bios (not working): > > > > > > https://reviews.freebsd.org/P612 > > > > > > Related PR: > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272507 > > > > > > If you need to more information or testing just ask and please CC me > > > when replying. > > > > > > Best regards, > > > > > > Daniel > > > > In addition to the above, 13.2-RELEASE fails in the same way, also > > 15.0-CURRENT (20231005-8818f0f1124e-265728). In addition to that, USB > > also fails to init so USB devices won't work once the kernel boots. > > > > Considering that none of the current FreeBSD versions work I suspect > that you'll have to flash the previous BIOS version to get a working > system again. > > -- > Gary Jennejohn Or check in detail for defaults on BIOS (UEFI firmware) settings changes. Hopefully, these are usually described in readme or update notes or something alike. If any, try reverting back to the previous defaults except you intentionally changed on previous BIOS. Sometimes BIOS vendors change their BIOS defaults to something FreeBSD dislikes. -- Tomoaki AOKI
Re: poudriere jail upgrade 14.0-BETA5 -> 14.0-RC1 continues to fail
On Sat, 14 Oct 2023 12:22:38 +0100 Nuno Teixeira wrote: > Hello all, > > I did try updating BETA1 -> BETA2, BETA2 -> BETA3, ..., BETA5 -> RC1 in > poudriere: > > `poudriere jail -u -j JAIL -t 14.0-RC1` > > All fails with: > --- > > /usr/src/sys/x86/x86/cpu_machdep.c > /usr/src/tests/sys/netpfil/pf/pfsync.sh > /usr/src/usr.bin/man/man.sh > /var/db/etcupdate/log > To install the downloaded upgrades, run > "/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK install". > Installing updates... done. > No updates are available to install. > Run '/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK fetch' first. > [00:11:17] Error: Fail to upgrade system > --- > > Any clues? > > Thanks, > > -- > Nuno Teixeira > FreeBSD Committer (ports) Shortage on /tmp? If not, what happens when you run `/tmp/poudriere.3homsGor/freebsd-update.1BURpmmK fetch` as suggested by pudriere? Or possibly your nearest mirror not yet has needed updates to fetch? FYI: I'm using src upgrading and created poudriere jail as below `poudriere jail -c -v stable/14 -a amd64 -K kernname -j jailname \ -m src=/usr/src` and didn't yet encountered problems on updating poudriere jail. This way, poudriere uses pre-built objects under /usr/obj as default. Regards. -- Tomoaki AOKI
Re: revision not displayed in a2440348eed7
On Tue, 26 Sep 2023 15:19:46 -0700 Cy Schubert wrote: > In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp>, > Tomoaki > AOKI writes: > > On Tue, 26 Sep 2023 15:48:50 +0200 > > Marek Zarychta wrote: > > > > > W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze: > > > > At least up to 15.0-CURRENT, nothing has happend by > > > > WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in > > > > 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7, > > > > but revision not showed by `uname -a' ;-( > > > > > > > > What changed > > > > > > Nothing changed. Perhaps your build system can't check git hash ? If > > > your sources are from git repository, you need at least git-lite > > > installed and full git repository available on build machine. If you > > > checked out the repository with gitup and have gitup installed, it > > > should also work. It won't work if your build machine has access to > > > only a part of the repository like worktree. > > > > > > Cheers > > > > > > -- > > > Marek Zarychta > > > > Just a possibility, but copying src tree to directory other than the > > directory where checked out from git repo and building there could > > lose track with git hash. > > > > Another possibility is that if you build src with any user other than > > the one owning local (pulled) git repo could also lose track with git > > hash. For example, if I `git log HEAD` with regular user and the local > > repo is pulled by root, it fails. No special configuration is done. > > > > % git log HEAD > > fatal: detected dubious ownership in repository at '/usr/src' > > To add an exception for this directory, call: > > > > git config --global --add safe.directory /usr/src > > > > > > This could be due to e6dc6a27230, which was committed this morning. There > is discussion on the src commits ML (dev-commits-src-all, > dev-commits-src-main) about reverting the change. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 Would be unrelated here, unfortunately. As the subject says, the commit the original reporter is bitten at (not bi-sected) is at a2440348eed7, which is before e6dc6a27230. -- Tomoaki AOKI
Re: revision not displayed in a2440348eed7
On Tue, 26 Sep 2023 15:48:50 +0200 Marek Zarychta wrote: > W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze: > > At least up to 15.0-CURRENT, nothing has happend by > > WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in > > 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7, > > but revision not showed by `uname -a' ;-( > > > > What changed > > Nothing changed. Perhaps your build system can't check git hash ? If > your sources are from git repository, you need at least git-lite > installed and full git repository available on build machine. If you > checked out the repository with gitup and have gitup installed, it > should also work. It won't work if your build machine has access to > only a part of the repository like worktree. > > Cheers > > -- > Marek Zarychta Just a possibility, but copying src tree to directory other than the directory where checked out from git repo and building there could lose track with git hash. Another possibility is that if you build src with any user other than the one owning local (pulled) git repo could also lose track with git hash. For example, if I `git log HEAD` with regular user and the local repo is pulled by root, it fails. No special configuration is done. % git log HEAD fatal: detected dubious ownership in repository at '/usr/src' To add an exception for this directory, call: git config --global --add safe.directory /usr/src -- Tomoaki AOKI
Re: revision not displayed in a2440348eed7
On Tue, 26 Sep 2023 15:29:00 +0900 KIRIYAMA Kazuhiko wrote: > Hi, Yuri > > On Tue, 26 Sep 2023 10:31:34 +0900, > Yuri wrote: > > > > KIRIYAMA Kazuhiko wrote: > > > Hi, list > > > > > > I updated to a2440348eed7, but could not display revision: > > > > > > admin@tbedfc:~ % uname -a > > > FreeBSD tbedfc 15.0-CURRENT FreeBSD 15.0-CURRENT #0: Tue Sep 26 00:15:10 > > > JST 2023 root@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > > admin@tbedfc:~ % > > > > > > Why ??? > > > > Are you using WITH_REPRODUCIBLE_BUILD? > > > > Exact opposite state of affairs: > > admin@tbedfc:~ % cat /etc/src.conf > WITHOUT_REPRODUCIBLE_BUILD=yes > admin@tbedfc:~ % > > --- > Kazuhiko Kiriyama So next possibility. Are you sure that... *There is no "WITH_REPRODUCIBLE_BUILD=no" nor "WITH_REPRODUCIBLE_BUILD=false" lines both in /etc/src.conf and /etc/make.conf *If you are using any script to automate src builds, there are none like above in the `make` command lines in the script. As you may alreay know of, but easily forgotton, values set to WITH_foo and/or WITHOUT_bar does not have any meaning. Just the variable is set or not is checked. I've bitten by something alike before. -- Tomoaki AOKI
Re: make installworld filed with "Required library libdialog.so.9 not found"
On Wed, 20 Sep 2023 18:16:47 +0200 Dimitry Andric wrote: > On 20 Sep 2023, at 15:02, KIRIYAMA Kazuhiko wrote: > > > > On Wed, 20 Sep 2023 15:56:28 +0900, > > Dimitry Andric wrote: > ... > > Fortunately old binaries exist and `cp > > /past_created/usr/src/amd64.amd64/tmp/usr/lib/libdialog.so.9 > > /usr/lib' then go forward but stopped at stand/i386/boot2: > > > > ===> stand/i386/boot2 (install) > > objcopy -S -O binary boot1.out boot1 > > objcopy -S -O binary boot2.out boot2.bin > > btxld -v -E 0x2000 -f bin -b > > /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr -o > > boot2.ld -P 1 boot2.bin > > make[6]: exec(btxld) failed (No such file or directory) > > *** Error code 1 > > > > Stop. > > make[6]: stopped in /usr/src/stand/i386/boot2 > > As far as I remember, this typically happens when some sources are touched, > and it is attempting to rebuild the boot loader binaries at install time. > This should normally not happen, as everything has been built during > buildworld already. But this problem sometimes occurs when system clocks are > out of sync, or when files in the object tree get their dates modified for > other reasons. IIRC, this happenes on the scenario below. buildword buildkernel modify something related with only kernel or kernel modules buildkernel aggain installkernel reboot etcpudate -p installworld, then, bang! start rebuiding boot codes and loaders. > > In this particular case it is trying to re-link btx using btxld, but since > that tool is only available during buildworld, it cannot find it. I don't > know of a good way to fix this, except maybe to run a buildworld with > WITHOUT_CLEAN, e.g.: > > make -DWITHOUT_CLEAN -j buildworld > > That should rebuild all things that need rebuilding without doing excessive > cleaning, and from there you can attempt to installworld again. > > -Dimitry -- Tomoaki AOKI
Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)
At least, if I read the code correctly,
"com.fudosecurity:block_cloning",
should be added to array
*features_for_read[]
of stand/libsa/zfs/zfsimpl.c.
There are check codes like below, so without it, boot codes would
reject to boot from any pool having block_cloning feature enabled.
Am I missing something?
> for (i = 0; features_for_read[i] != NULL; i++) {
> if (memcmp(nvp_name->nv_data,
features_for_read[i], nvp_name->nv_size) == 0) {
> found = 1;
> break;
> }
> }
>
> if (!found) {
> printf("ZFS: unsupported feature: %.*s\n",
> nvp_name->nv_size, nvp_name->nv_data);
> rc = EIO;
> }
Regards.
On Mon, 18 Sep 2023 09:26:56 -0400
Alexander Motin wrote:
> block_cloning feature is marked as READONLY_COMPAT. It should not
> require any special handling from the boot code.
>
> On 18.09.2023 07:22, Tomoaki AOKI wrote:
> > Really OK?
> >
> > I cannot find block_cloning in array *features_for_read[] of
> > stand/libsa/zfs/zfsimpl.c, which possibly mean boot codes (including
> > loader) cannot boot from Root-on-ZFS pool having block_cloning active.
> >
> > Not sure adding '"com.fudosecurity:block_cloning",' here is sufficient
> > or not. Possibly more works are needed.
> >
> > IMHO, all default-enabled features should be safe for booting.
> > Implement features with disalded, impement boot codes to support them,
> > then finally enable them by default should be the only valid route.
> >
> >
> > [1] https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c
> >
> >
> > On Mon, 18 Sep 2023 07:31:46 +0200
> > Martin Matuska wrote:
> >
> >> I vote for enabling block cloning on main :-)
> >>
> >> mm
> >>
> >> On 16. 9. 2023 19:14, Alexander Motin wrote:
> >>> On 16.09.2023 01:25, Graham Perrin wrote:
> >>>> On 16/09/2023 01:28, Glen Barber wrote:
> >>>>> o A fix for the ZFS block_cloning feature has been implemented.
> >>>>
> >>>> Thanks
> >>>>
> >>>> I see
> >>>> <https://github.com/openzfs/zfs/commit/5cc1876f14f90430b24f1ad2f231de936691940f>,
> >>>> with
> >>>> <https://github.com/freebsd/freebsd-src/commit/9dcf00aa404bb62052433c45aaa5475e2760f5ed>
> >>>> in stable/14.
> >>>>
> >>>> As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT
> >>>> n265350-72d97e1dd9cc): should we assume that additional fixes, not
> >>>> necessarily in time for 14.0-RELEASE, will be required before
> >>>> vfs.zfs.bclone_enabled can default to 1?
> >>>
> >>> I am not aware of any block cloning issues now. All this thread about
> >>> bclone_enabled actually started after I asked why it is still
> >>> disabled. Thanks to Mark Millard for spotting this issue I could fix,
> >>> but now we are back at the point of re-enabling it again. Since the
> >>> tunable does not even exist anywhere outside of FreeBSD base tree, I'd
> >>> propose to give this code another try here too. I see no point to
> >>> have it disabled at least in main unless somebody needs time to run
> >>> some specific tests first.
> >
>
> --
> Alexander Motin
--
Tomoaki AOKI
Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available)
(Intentionally dropped @gmail.com recipients, as gmail refuses to accept emaif from my email domain, unfortunately.) Really OK? I cannot find block_cloning in array *features_for_read[] of stand/libsa/zfs/zfsimpl.c, which possibly mean boot codes (including loader) cannot boot from Root-on-ZFS pool having block_cloning active. Not sure adding '"com.fudosecurity:block_cloning",' here is sufficient or not. Possibly more works are needed. IMHO, all default-enabled features should be safe for booting. Implement features with disalded, impement boot codes to support them, then finally enable them by default should be the only valid route. [1] https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c On Mon, 18 Sep 2023 07:31:46 +0200 Martin Matuska wrote: > I vote for enabling block cloning on main :-) > > mm > > On 16. 9. 2023 19:14, Alexander Motin wrote: > > On 16.09.2023 01:25, Graham Perrin wrote: > >> On 16/09/2023 01:28, Glen Barber wrote: > >>> o A fix for the ZFS block_cloning feature has been implemented. > >> > >> Thanks > >> > >> I see > >> <https://github.com/openzfs/zfs/commit/5cc1876f14f90430b24f1ad2f231de936691940f>, > >> > >> with > >> <https://github.com/freebsd/freebsd-src/commit/9dcf00aa404bb62052433c45aaa5475e2760f5ed> > >> > >> in stable/14. > >> > >> As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT > >> n265350-72d97e1dd9cc): should we assume that additional fixes, not > >> necessarily in time for 14.0-RELEASE, will be required before > >> vfs.zfs.bclone_enabled can default to 1? > > > > I am not aware of any block cloning issues now. All this thread about > > bclone_enabled actually started after I asked why it is still > > disabled. Thanks to Mark Millard for spotting this issue I could fix, > > but now we are back at the point of re-enabling it again. Since the > > tunable does not even exist anywhere outside of FreeBSD base tree, I'd > > propose to give this code another try here too. I see no point to > > have it disabled at least in main unless somebody needs time to run > > some specific tests first. -- Tomoaki AOKI
Re: CURRRENT snapshot won't boot due missing ZFS feature
On Sat, 16 Sep 2023 08:43:49 -0700 Mark Millard wrote: > void wrote on > Date: Sat, 16 Sep 2023 12:12:02 UTC : > > > On Sat, Sep 16, 2023 at 12:55:19PM +0100, Warner Losh wrote: > > > > >Yes. The boot loader comes from the host. It must know how to read ZFS. > > > > It knows how to read zfs. > > I expect Warner was indicating: you have a (efi?) loader that knows > how to deal with the features listed in: > > sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd > > being active but not with some new feature(s) listed in: > > sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2 > > being active. > > The following are the "read-only-compatibile no" features > that are new in openzfs-2.2 compared to openzfs-2.1-freebsd : > > blake3 > ednor > head_errlog > vdev_zaps_v2 > > So any of those being active leads to lack of even read-only > activity being compatible. (Although, the loader's subset > of the potential overall activity might allow ignoring some > specific "read-only-compatibile no" status examples.) > > For reference: > > # diff -u99 > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2 > --- > /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.1-freebsd > 2021-06-24 20:08:57.206621000 -0700 > +++ /usr/main-src/sys/contrib/openzfs/cmd/zpool/compatibility.d/openzfs-2.2 > 2023-06-10 15:59:25.354999000 -0700 > @@ -1,34 +1,40 @@ > -# Features supported by OpenZFS 2.1 on FreeBSD > +# Features supported by OpenZFS 2.2 on Linux and FreeBSD > allocation_classes > async_destroy > +blake3 > +block_cloning > bookmark_v2 > bookmark_written > bookmarks > device_rebuild > device_removal > draid > +edonr > embedded_data > empty_bpobj > enabled_txg > encryption > extensible_dataset > filesystem_limits > +head_errlog > hole_birth > large_blocks > large_dnode > livelist > log_spacemap > lz4_compress > multi_vdev_crash_dump > obsolete_counts > project_quota > redacted_datasets > redaction_bookmarks > resilver_defer > sha512 > skein > spacemap_histogram > spacemap_v2 > userobj_accounting > +vdev_zaps_v2 > +zilsaxattr > zpool_checkpoint > zstd_compress > > (Last I checked, /usr/share/zfs/compatibility.d/openzfs-2.2 does > not exist yet. Thus were I had the diff look.) It may be because it's not yet listed here, thus not installed. /usr/src/cddl/share/zfs/compatibility.d/Makefile > > On the host in question, there are many guests, > > some with zfs-boot, some not, just file-based. > > But with what openzfs features active vs. not active > 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. > > For reference (from an aarch64 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/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 -- Tomoaki AOKI
Re: Continually count the number of open files
On Wed, 13 Sep 2023 11:52:19 -0700 Bakul Shah wrote: > On Sep 12, 2023, at 11:59 PM, Graham Perrin wrote: > > > > (I'm a tcsh user, I can easily 'sh' before running the command.) > > You can switch to zsh. Most of csh/tcsh + sh + many more features. > > > baloo is not used in 273669. > > It certainly feels like an inotify like use or a file-descr leak. > The bug reporter can try "procstat fd " on running processes > to see which one has all those open files. Another thing worth > trying is to run under ktrace -di to see which syscalls were made. Additional note. For emergency I heve a line below in ~/.tcshrc.mine and a flag file ~/.Use_zsh. This way, you can switch back to tcsh by deleting the flag file whenever you want. No need to update master.passwd entry, as the login shell itself is still tcsh and zsh is `exec`'ed from tcsh. if ( -X zsh && -f ~/.Use_zsh ) exec zsh -- Tomoaki AOKI
Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics
On Fri, 8 Sep 2023 17:03:07 -0700 Mark Millard wrote: > On Sep 8, 2023, at 15:30, Martin Matuska wrote: > > > I can confirm that the patch fixes the panic caused by the provided script > > on my test systems. > > Mark, would it be possible to try poudriere on your system with a patched > > kernel? > > . . . > > On 9. 9. 2023 0:09, Alexander Motin wrote: > > On 08.09.2023 09:52, Martin Matuska wrote: > >> . . . > > > > Thank you, Martin. I was able to reproduce the issue with your script and > > found the cause. > > > > I first though the issue is triggered by the `cp`, but it appeared to be > > triggered by `cat`. It also got copy_file_range() support, but later than > > `cp`. That is probably why it slipped through testing. This patch fixes > > it for me: https://github.com/openzfs/zfs/pull/15251 . > > > > Mark, could you please try the patch? > > If all goes well, this will end up reporting that the > poudriere bulk -a is still running but has gotten past, > say, 320+ port->package builds finished (so: more than > double observed so far for the panic context). Later > would be a report with a larger figure. A normal run > I might let go for 6000+ ports and 10 hr or so. > > Notes as I go . . . > > Patch applied, built, and installed to the test media. > Also, booted: > > # uname -apKU > FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #75 > main-n265228-c9315099f69e-dirty: Thu Sep 7 13:28:47 PDT 2023 > root@amd64-ZFS:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG > amd64 amd64 150 150 > > Note that this is with a debug kernel (-dbg- in path and -DBG in > the GENERIC* name). Also, the vintage of what it is based on has: > > git: 969071be938c - main - vfs: copy_file_range() between multiple > mountpoints of the same fs type > > The usual sort of sequencing previously reported to get to this > point. Media update starts with the rewind to the checkpoint in > hopes of avoiding oddities from the later failure. > > . . . : > > [main-amd64-bulk_a-default] [2023-09-08_16h31m51s] [parallel_build:] Queued: > 34588 Built: 414 Failed: 0 Skipped: 39Ignored: 335 Fetched: 0 > Tobuild: 33800 Time: 00:30:41 > > > So 414 and and still building. > > More later. (It may be a while.) > > === > Mark Millard > marklmi at yahoo.com Would it planned to be MFC'ed to stable/14, and then releng/14.0 once MFV'ed to main? Regards. -- Tomoaki AOKI
Re: etcupdate -p, and other uses of etcupdate(8) (was: Has the update procedure changed?)
On Sun, 27 Aug 2023 18:16:35 +0100 Graham Perrin wrote: > On 07/08/2023 16:51, Kevin Oberman wrote: > > UPDATING seems to match the Makefile except that Makefile is far less > > detailed. The Makefile even says "See src/UPDATING `COMMON ITEMS' for > > more complete information." > > > > … "etcupdate -p". … > > <https://mastodon.bsd.cafe/@fbfortune/110960171470986602> prompted me to > look at > <https://github.com/freebsd/freebsd-src/commit/1909a1f4947d85e27564a3fa54d3df6f71a065dc#diff-e5eba14393c650ee8e8bcd7ca7a2d2dfecd6d15e54b927b89d04ed7eb1eb93baR540-R546>. > > > > Is this fortune-provided tip outdated? For new install with bsdinstall [1] and binary update by freebsd-update [2], yes. But for src updates, no [3]. [1] https://lists.freebsd.org/archives/freebsd-current/2023-August/004194.html [2] https://lists.freebsd.org/archives/freebsd-current/2023-August/004208.html [3] https://lists.freebsd.org/archives/freebsd-current/2023-August/004210.html -- Tomoaki AOKI
Re: Status for zfs upgrade?
Hi. Thanks for the pointer! Although the data in the page are a bit outdated, but the methods to determine features described there looks helpful. (For example, the problematic block_cloning feature is not listed yet.) And yes, I've noticed the Alpha2 commit, but ATM release schedule page was not updated yet. Regards. On Fri, 18 Aug 2023 12:36:59 +0200 (CEST) Ronald Klop wrote: > Hi, > > This blog might be interesting to you. > https://vermaden.wordpress.com/2022/03/25/zfs-compatibility/ > > BTW: stable/14 is delayed one week: > https://www.freebsd.org/releases/14.0R/schedule/ > > Regards, > Ronald. > > Van: Tomoaki AOKI > Datum: vrijdag, 18 augustus 2023 00:00 > Aan: freebsd-current@freebsd.org > Onderwerp: Status for zfs upgrade? > > > > Hi. > > > > Creation of stable/14 is planned at Aug.18, 2023 (Already TODAY in > > Japan, JST+9). > > > > Is it safe for now to `zfs upgrade `, if tunable > > vfs.zfs.bclone_enabled is set to 0? > > > > If not, I should wait until next stable branch, /15. > > (I upgrade pool only when ZFS codes are 100% match between main and > > latest stable. Meaning doable only when new stable branch is created.) > > > > Regards. > > > > -- > > Tomoaki AOKI > > > > > > > > > > -- Tomoaki AOKI
Re: www/chromium will not build on a host w/ 8 CPU and 16G mem
On Tue, 15 Aug 2023 23:19:37 -0700 Mark Millard wrote: > Matthias Apitz wrote on > Date: Wed, 16 Aug 2023 04:31:38 UTC : > > > I have built ~2200 ports successful on my build server, which is a > > Dell R210 with 8x 3.30GHz CPU and 15.8 GB memory: > > > > Aug 11 19:03:21 jet kernel: CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz > > (3292.74-MHz K8-class CPU) > > Aug 11 19:03:21 jet kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 > > CPUs > > Aug 11 19:03:21 jet kernel: avail memory = 16582250496 (15814 MB) > > > > I have set swap to 4GB + 10GB + 10GB: > > > > # swapctl -lh > > Device: Bytes Used: > > /dev/da0p3 4.0G 1.5G > > /dev/md9 10G 1.5G > > /dev/md10 10G 1.5G > > Are those /dev/md* vnode backed? If not, what type are they? > > FYI: On 2017-Feb-13, at 7:20 PM, Konstantin Belousov > wrote on the freebsd-arm list: > > QUOTE > . . . > > swapfile write requires the write request to come through the filesystem > write path, which might require the filesystem to allocate more memory > and read some data. E.g. it is known that any ZFS write request > allocates memory, and that write request on large UFS file might require > allocating and reading an indirect block buffer to find the block number > of the written block, if the indirect block was not yet read. > > As result, swapfile swapping is more prone to the trivial and unavoidable > deadlocks where the pagedaemon thread, which produces free memory, needs > more free memory to make a progress. Swap write on the raw partition over > simple partitioning scheme directly over HBA are usually safe, while e.g. > zfs over geli over umass is the worst construction. > END QUOTE > > Use of swap partitions is to be recommended to minimize the chance of > paging related deadlocks. > > You have not reported on how much swap was in use shortly before the > "was killed: a thread waited too long to allocate a page" notice. > (After the notice is too late of a time frame to be of interest.) > > > and poudriere does use ZFS. > > > > Building the last outstanding port www/chromium in single job mode > > fails reproducible with a kernel message: > > > > Aug 16 06:14:04 jet kernel: pid 48725 (ninja), jid 3, uid 65534, was killed: > > a thread waited too long to allocate a page > > You have not been explicit about how you have managed > RAM+SWAP tradeoffs in /usr/local/etc/poudriere.conf > settings. > > In /usr/local/etc/poudriere.conf : what are you using > as the USE_TMPFS value: > > # Use tmpfs(5) > # This can be a space-separated list of options: > # wrkdir- Use tmpfs(5) for port building WRKDIRPREFIX > # data - Use tmpfs(5) for poudriere cache/temp build data > # localbase - Use tmpfs(5) for LOCALBASE (installing ports for > packaging/testing) > # all - Run the entire build in memory, including builder jails. > # yes - Enables tmpfs(5) for wrkdir and data > # no- Disable use of tmpfs(5) > > Only 2 of the options keep the tmpfs use small: > > data > no > > For example, building rust can use 10 GiBytes+ of just tmpfs > space that competes for RAM+SWAP. > > The last personal I helped that was getting "a thread waited > too long to allocate a page" it turned out that changing the > USE_TMPFS= assignment to one of the 2 options eliminated the > issue. (No guarnatee of such here.) [There were 2 USE_TMPFS= > assignments, the 2nd "winning" --but the first had been > intended.] > > Are you defining ALLOW_MAKE_JOBS= ? If yes, are you using > /usr/local/etc/poudriere.d/make.conf (or the like) to assign > MAKE_JOBS_NUMBER= (or the like)? If yes, to what? Last I knew > the official port -> package builders use MAKE_JOBS_NUMBER=2 > for their activity with ALLOW_MAKE_JOBS in use. > > A similar point goes for if you are assigning > ALLOW_MAKE_JOBS_PACKAGES= . Are you? > > These can contribute to RAM+SWAP usage and higher load > averages. > > > What could I do in the port's options or kernel values? > > I've not actually gone in either of those directions above. > But nothing at this point says if I've happened to cover > your case vs. not. > > === > Mark Millard > marklmi at yahoo.com Just a FYI: www/chromium built fine (stable/13, though) with poudriere. RAM is 32GB and 64GB single dedicated swap partition on SSD. Using ports-mgmt/poudriere-devel. No ccache used. In /usr/local/etc/poudriere.conf, USE_TMPFS=yes ALLOW_MAKE_JOBS=yes The line below is kept commented out. #TMPFS_LIMIT=8 On main (booted from different physical drive on the same PC), I don't use poudriere[-devel], but www/chromium (previous version) built fine using ports-mgmt/pkg_replace. The size of /tmp (swap-backed tmpfs) is not limited (means at maximum of 64GB). -- Tomoaki AOKI
Re: Defaulting serial communication to 115200 bps for FreeBSD 14
On Tue, 15 Aug 2023 21:02:57 -0700 Cy Schubert wrote: > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > >message dated "Tue, 15 Aug 2023 17:18:37 -0400." > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > In message om> > , Ed Maste writes: > > FreeBSD currently uses 9600 bps as the default for serial > > communication -- in the boot loader, kernel serial console, /etc/ttys, > > and so on. This was consistent with most equipment in the 90s, when > > these defaults were established. Today 115200 bps seems to be much > > more common, and I'm proposing that we make it the default for FreeBSD > > 14.0. > > > > I have a review open: https://reviews.freebsd.org/D36295. There are a > > few minor nits in the review to be addressed still but assuming > > there's general agreement I'll iterate on those and commit this in a > > few logical chunks. > > > > There should probably be an UPDATING entry for those who use boot0 to > revert back to 9600 in that case. Not read the diff though, if the baud rate is re-initialized in boot1 or later (including btx, loader, kernel and userland) and handshake again, most of the boot process and later would run at 115200 bps. -- Tomoaki AOKI
Re: www/firefox does not compile in 14-CURRENT w/ poudriere
On Tue, 15 Aug 2023 21:39:56 +0900
Tomoaki AOKI wrote:
> On Tue, 15 Aug 2023 08:35:01 +0200
> Matthias Apitz wrote:
>
> >
> > The port www/firefox stops to build in congigure phase with:
> >
> > DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-wasi
> > /tmp/conftest._vo3qtm2.c -c`
> > DEBUG: The command returned non-zero exit status 1.
> > DEBUG: Its error output was:
> > DEBUG: | error: unable to create target: 'No available targets are
> > compatible with triple "wasm32-unknown-wasi"'
> > DEBUG: | 1 error generated.
> > ERROR: Failed compiling a simple C source with the wasm C compiler
> >
> > Which compiler should be used? I set CC=clang via the make.conf.
>
> Maybe this hurts.
> www/firefox depends on devel/wasi-libcxx, devel/wasi-libc and
> devel/wasi-compiler-rt13. These are only for llvm/clang13 for now.
>
> And clang on main is at 16, but if you don't override the default of
> www/firefox, it should depend on devel/llvm13 and use it, if base
> llv/clang is NOT 13.
Forgot to mention.
If you want to force CC=clang for ports other than ww/firefox, maybe
below would help.
.if !${.CURDIR:M/usr/ports/www/firefox*}
CC= clang
.endif
> > Thanks
> > matthias
> >
> >
> > --
> > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> > Public GnuPG key: http://www.unixarea.de/key.pub
>
>
> --
> Tomoaki AOKI
--
Tomoaki AOKI
Re: www/firefox does not compile in 14-CURRENT w/ poudriere
On Tue, 15 Aug 2023 08:35:01 +0200 Matthias Apitz wrote: > > The port www/firefox stops to build in congigure phase with: > > DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=wasm32-wasi > /tmp/conftest._vo3qtm2.c -c` > DEBUG: The command returned non-zero exit status 1. > DEBUG: Its error output was: > DEBUG: | error: unable to create target: 'No available targets are compatible > with triple "wasm32-unknown-wasi"' > DEBUG: | 1 error generated. > ERROR: Failed compiling a simple C source with the wasm C compiler > > Which compiler should be used? I set CC=clang via the make.conf. Maybe this hurts. www/firefox depends on devel/wasi-libcxx, devel/wasi-libc and devel/wasi-compiler-rt13. These are only for llvm/clang13 for now. And clang on main is at 16, but if you don't override the default of www/firefox, it should depend on devel/llvm13 and use it, if base llv/clang is NOT 13. > Thanks > matthias > > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub -- Tomoaki AOKI
Re: Potential show-stopper in em driver?
On Mon, 14 Aug 2023 11:55:04 +1000 "Greg 'groggy' Lehey" wrote: > I've spent the last couple of days chasing random hangs on my -CURRENT > box. It seems to be related to the Ethernet driver (em). I've been > trying without much success to chase it down, and I'd be grateful. > The box is headless, and all communication is via the net, which > doesn't make it any easier. I've tried a verbose boot, but nothing of > interest shows up. Typically it happens during the nightly backups, > which are over NFS: > > Aug 13 21:06:46 dereel kernel: <<<66>n>nffs server s6>neurekfs server > aeureka:/dum:p: /ndoump: tnot responding > Aug 13 21:06:46 dereel kernel: > Aug 13 21:06:46 dereel kernel: responding > Aug 13 21:06:46 dereel kernel: > Aug 13 21:06:46 dereel kernel: server eureka:/dump:n not responding > > And if you haven't seen those garbled messages before, admire. > They've been there for a long time, and they have nothing to do with > the problem. More to the point, there are no other error messages. > > I've run three kernels on this box over the last few weeks: > > 1. FreeBSD dereel 14.0-CURRENT FreeBSD 14.0-CURRENT amd64 1400093 #10 > main-n264292-7f9318a022ef: Mon Jul 24 17:13:32 AEST 2023 > grog@dereel:/usr/obj/eureka/home/src/FreeBSD/git/main/amd64.amd64/sys/GENERIC > amd64 > >This works with no problems. > > 2. FreeBSD 14.0-CURRENT amd64 1400094 #11 main-n264653-517e0978db1f: Thu Aug > 10 14:17:13 AEST 2023 > grog@dereel:/usr/obj/eureka/home/src/FreeBSD/git/main/amd64.amd64/sys/GENERIC > > 3. FreeBSD dereel 14.0-ALPHA1 FreeBSD 14.0-ALPHA1 amd64 1400094 #12 > main-n264693-b231322dbe95: Sat Aug 12 14:31:44 AEST 2023 > grog@dereel:/usr/obj/eureka/home/src/FreeBSD/git/main/amd64.amd64/sys/GENERIC > amd64 > >Both of these exhibit the problem. > > Note that we're now ALPHA1, so it's a good idea to get to the bottom > of it. The box is an ThinkCentre M93p. I'm attaching a verbose boot > log, though I don't expect anybody to find something of use there. > I'm also currently building a new world in case something has happened > since Saturday. > > Greg > -- > Sent from my desktop computer. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA.php Does commit f1b5488f7bba7f25a57750f87cbcbccbd5b9d16b [1] related? How does it go if disabling TSO as documeted on the commit message? CC'ing kbowling@, who committed all (I could find on cgit) e1000/em-related bits between the timeframe of 1. and 2. [1] https://cgit.freebsd.org/src/commit/?id=f1b5488f7bba7f25a57750f87cbcbccbd5b9d16b -- Tomoaki AOKI
Re: Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8
On Sun, 13 Aug 2023 23:16:47 + Alastair Hogge wrote: > On 2023-08-13 23:22, Matthias Apitz wrote: > > fwd to freebsd-current@ because I don't know if kde@ is read by someone; > > > > matthias > > > > - Forwarded message from bugzilla-nore...@freebsd.org - > > > > Date: Sun, 13 Aug 2023 15:08:04 + > > From: bugzilla-nore...@freebsd.org > > To: k...@freebsd.org > > Subject: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270041 > > Oh nice! How I have missed this BZ report, this will get my 14-CURRENT > hosts up to date, thanks for sharing. Maybe because it was once closed. :-) Now it's reopened. Feel free to pop in and report your result there. Applied the uploaded patch, or increased ulimit in poudriere.conf. Update OK or not. -- Tomoaki AOKI
Re: Fwd: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8
On Sun, 13 Aug 2023 17:22:19 +0200 Matthias Apitz wrote: > fwd to freebsd-current@ because I don't know if kde@ is read by someone; > > matthias > > - Forwarded message from bugzilla-nore...@freebsd.org - > > Date: Sun, 13 Aug 2023 15:08:04 + > From: bugzilla-nore...@freebsd.org > To: k...@freebsd.org > Subject: [Bug 270041] www/qt5-webengine: Poudriere build fails for 5.15.8 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270041 > > --- Comment #11 from Matthias Apitz --- > I stumbled across the bug in mid August again and had to wait two times in > poudriere 6 hours to get to the failure. After the 2nd time I search with Don > Google to get to this fix... > > The issue should be re-opened again (I don't know how to do so) and the > maintainer should fix this port appropriately. Thanks > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug. > > - End forwarded message - > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub Reopened as original reporter. ;-) I myself is no longer bitten again, as I've raised ulimit in /usr/local/etc/poudriere.conf. CC'ing kai@ here, who committed the latest actual "update" to 5.15.8. Unfortunately, bugzilla picks the maintainer (and automatically mails to) from ports Makefile. So kde@ is picked as maintainer here. -- Tomoaki AOKI
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
Resent. Not yet sent from ML but later one was sent.
Adding @freebsd.org address of Enji, as gmail does not accept mails
from dec.sakura.ne.jp, which has neither DKIM functionality nor SPF
record.
On Thu, 10 Aug 2023 16:32:32 -0700
Enji Cooper wrote:
> > On Aug 10, 2023, at 4:00 PM, Tomoaki AOKI wrote:
> >
> > On Thu, 10 Aug 2023 18:09:54 -0400
> > Charlie Li wrote:
> >
> >> Enji Cooper wrote:
> >>> Hmm… All lang/python27 requiring ports should be marked BROKEN and
> >>> removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
> >> We can't entirely do that yet. Unfortunately, moinmoin, original mailman
> >> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
> >> It was the case that Chrom{e,ium} and qt-webengine still had Python 2
> >> build bits but they've since migrated off.
> >>
> >> --
> >> Charlie Li
> >> …nope, still don't have an exit line.
> >
> > Can lang/tauthon used instead of lang/python27?
> > It's a fork of python27 and maintained (slowly) like [1].
>
> Lang/tauthon probably could be used instead.
Even if original upstream is abandoned, maintained fork would better be
allowed. If tauthon can be considered "well maintained", consumers of
python27 which is enough compatible with tauthon can switch to tauthon
and un-deprecated.
> > I don't use python nor tauthon directly, though.
> > I dislike languages killing backward compatibility... :-(
> >
> > I love C as even recent llvm/clang has an ability to compile K&R
> > codes, if proper options are set. This is how ALL computer languages
> > SHALL BE.
>
> The problem that python2 -> python3 was trying to solve was multifold: there
> were a variety of issues with the language, as defined in python2, which made
> the syntax changes going from 2 to 3 necessary.
>
> That being said, the whole “python2 is going away in 2020” was advertised
> well in advance (several years). If projects hadn’t done the work of getting
> off python2 by 2020, it’s their fault in not prioritizing that effort.
>
> The problem with packages like MoinMoin, etc, is that unless they’re
> completely isolated (vendor and provide all of their dependencies), they are
> likely developing pieces of software on vulnerable versions of third-party
> packages since many packages started yanking python2 support in the past
> couple years. Yanking python2 support allows third-party projects to be
> developed with more modern syntax niceties like the walrus operator, type
> hints, asyncio, etc. It’s not logical for pieces of software to not improve.
>
> Python is not C or Perl; the transition from 2 to 3 was particularly painful,
> but the changes were based on development that was over a decade in the
> making.
If I'm the project owner of python, I would have been decided to
abandon python and switch to different name because of backward
incompatibility. But unfortunately, they didn't do so.
If the software itself runs on python, I think you're completely right.
It should be rewritten.
But for softwares which uses python only on build time, staying on
python27 should be allowed.
In small projects, if the person who built the building environment
retired from the project and noone else can understand / maintain the
build system, the only selection is "stay there until someone who can
construct new build environment pops in". This could happen here and
there, unfortunately.
For example,
*Consider python27 and required py-* as bootstrapping tool.
*Build python27 and required py-* everytime the port is built
and cleanup afterwards, INSIDE PORTS WORKDIR.
*python27 and required py-* are listed in distinfo of each port which
requires python27 on build time only.
would allow lang/python27 to be deleted, if possible.
>
> Cheers,
> -Enji
--
Tomoaki AOKI
Re: Has the update procedure changed?
On Fri, 11 Aug 2023 15:27:46 +0200 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > This can help new installation using release tarballs (official or > > locally built) or upgrading with overwriting using said tarballs, but > > how does freebsd-update? > > freebsd-update uses the same release process. > > DES > -- > Dag-Erling Smørgrav - d...@freebsd.org Ah, thanks! So just anyone running through source update like us are possibly bitten. -- Tomoaki AOKI
Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
On Thu, 10 Aug 2023 18:09:54 -0400
Charlie Li wrote:
> Enji Cooper wrote:
> > Hmm… All lang/python27 requiring ports should be marked BROKEN and
> > removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
> We can't entirely do that yet. Unfortunately, moinmoin, original mailman
> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
> It was the case that Chrom{e,ium} and qt-webengine still had Python 2
> build bits but they've since migrated off.
>
> --
> Charlie Li
> …nope, still don't have an exit line.
Can lang/tauthon used instead of lang/python27?
It's a fork of python27 and maintained (slowly) like [1].
I don't use python nor tauthon directly, though.
I dislike languages killing backward compatibility... :-(
I love C as even recent llvm/clang has an ability to compile K&R
codes, if proper options are set. This is how ALL computer languages
SHALL BE.
[1]
https://github.com/naftaliharris/tauthon/commit/52473e14e93366e02cf0b63b4c7fd952420e5ee3
--
Tomoaki AOKI
Re: Has the update procedure changed?
On Thu, 10 Aug 2023 16:08:26 +0200 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > Yes. But if bsdinstall and freebsd-update automatically bootstrap > > etcupdate if not yet done, newbies and casual users wouldn't be bitten. > > https://cgit.freebsd.org/src/commit/?id=e9120a256075543376496fbd75949eed1f13a887 > > DES > -- > Dag-Erling Smørgrav - d...@freebsd.org Oh, thanks! I've completely missed it when landed. This can help new installation using release tarballs (official or locally built) or upgrading with overwriting using said tarballs, but how does freebsd-update? I'm not enough familiar with how freebsd-update upgrades base. -- Tomoaki AOKI
Re: Has the update procedure changed?
On Thu, 10 Aug 2023 03:15:43 -0700 (PDT) "Jeffrey Bouquet" wrote: > On Thu, 10 Aug 2023 06:32:14 +0900, Tomoaki AOKI > wrote: > > > On Wed, 9 Aug 2023 05:50:05 -0700 > > David Wolfskill wrote: > > > > > On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote: > > > > ... > > > > > > > > Please correct me if I'm missing something. > > > > I use source update for years and not using bsdinstall nor > > > > freebsd-update. > > > > > > > > Does bsdinstall (and/or freebsd-update) create the first current tree > > > > for etcupdate, if not yet exists? > > > > > > > > This would be most confusing and harmful point of etcupdate. > > > > When I first tried etcupdate, I didn't noticed that I needed > > > > `etcupdate extract -B` BEFORE UPDATING src tree. > > > > Without this, etcupdate cannot detect what should be updated, even if a > > > > plenty of updates are required. > > > > > > > > At the moment, I must use mergemaster, and after that, `etcupdate > > > > extract -B` for next run. > > > > > > > > I think bsdinstall can create current tree, which is turned over to old > > > > tree on actual run, for etcupdate. > > > > So do freebsd-update. It would be able to create current tree JUST > > > > BEFORE INSTALLING UPDATE. > > > > > > > > I was helped by mergemaster, but after it completely retires, features > > > > above should be mandatory. > > > > > > > > > > TL;DR: Please see the "Bootstrapping" section of etcupdate(8). > > > > I know. ;-) I'm using etcupdate when it first MFC'ed to latest stable > > branch ATM, and bitten at the first time. > > > > Anyone not familiar with etcupdate would bitten by forgotton > > bootstrapping. :-( > > > > > > > Details: I have been doing source-based updates of FreeBSD since around > > > 1999. As such, I used mergemaster for a long time, and got used to it. > > > > > > With the switch to git, the $FreeBSD$ lines in config files became ... > > > well, misleading noise. And since mergemaster tried to use them, that > > > didn't work very well. This provided the incentive I needed to switch > > > to etcupdate. > > > > > > And... yeah; there was a "learning curve." And the "bootstrapping" bit > > > is necessary. But it has worked well for me since. > > > > Yes. But if bsdinstall and freebsd-update automatically bootstrap > > etcupdate if not yet done, newbies and casual users wouldn't be bitten. > > > > For source-based update users like us, > > > > *Bootstrapping section of man page should be near the top, > > for example, betweem DESCRIPTION and MODES section, not inside > > EXAMPLES section. > > > > *Also documented in UPDATING (or new document for common instructions) > > and handbook. > > > > should be needed. > > etcupdate cannot extract old tree from already-updated src. > > So anyone forgotton bootstrapping is forced to roll back src for > > bootstrapping and roll forward again BEFORE installworld, once > > mergemaster dissapears. > > > > > > > > Peace, > > > david > > > -- > > > David H. Wolfskill da...@catwhisker.org > > > Given Trump's claims about fairness in elections, his notion of a > > > "fair trial" is almost certainly at variance with objective reality. > > > > > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. > > > > > > -- > > Tomoaki AOKI > > > Say 3/5 of FreeBSD installs have not used etcupdate yet, and for those they > are > less likely to encounter problems [ at least in my experience ] because > mergemaster > has always be intuitive, an either-or choice at each menu, near zero chance of > PBKAC, would it not make sense to keep mergemaster around slightly modified, > for instance, with a new section of code that would prepare the result for > "now the next time /etc is updated, use only etcupdate THIS WAY". > alternately, > upgrade etcupdate to be VERY verbose in its threeway merge so that > 1... version A of file is in /etc, version B of file is in /var/???, desired > version > of file is in /var/??? or /usr/src/??? user's and legacy items in the > /etc > version are ...
Re: Has the update procedure changed?
On Wed, 9 Aug 2023 05:50:05 -0700 David Wolfskill wrote: > On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote: > > ... > > > > Please correct me if I'm missing something. > > I use source update for years and not using bsdinstall nor > > freebsd-update. > > > > Does bsdinstall (and/or freebsd-update) create the first current tree > > for etcupdate, if not yet exists? > > > > This would be most confusing and harmful point of etcupdate. > > When I first tried etcupdate, I didn't noticed that I needed > > `etcupdate extract -B` BEFORE UPDATING src tree. > > Without this, etcupdate cannot detect what should be updated, even if a > > plenty of updates are required. > > > > At the moment, I must use mergemaster, and after that, `etcupdate > > extract -B` for next run. > > > > I think bsdinstall can create current tree, which is turned over to old > > tree on actual run, for etcupdate. > > So do freebsd-update. It would be able to create current tree JUST > > BEFORE INSTALLING UPDATE. > > > > I was helped by mergemaster, but after it completely retires, features > > above should be mandatory. > > > > TL;DR: Please see the "Bootstrapping" section of etcupdate(8). I know. ;-) I'm using etcupdate when it first MFC'ed to latest stable branch ATM, and bitten at the first time. Anyone not familiar with etcupdate would bitten by forgotton bootstrapping. :-( > Details: I have been doing source-based updates of FreeBSD since around > 1999. As such, I used mergemaster for a long time, and got used to it. > > With the switch to git, the $FreeBSD$ lines in config files became ... > well, misleading noise. And since mergemaster tried to use them, that > didn't work very well. This provided the incentive I needed to switch > to etcupdate. > > And... yeah; there was a "learning curve." And the "bootstrapping" bit > is necessary. But it has worked well for me since. Yes. But if bsdinstall and freebsd-update automatically bootstrap etcupdate if not yet done, newbies and casual users wouldn't be bitten. For source-based update users like us, *Bootstrapping section of man page should be near the top, for example, betweem DESCRIPTION and MODES section, not inside EXAMPLES section. *Also documented in UPDATING (or new document for common instructions) and handbook. should be needed. etcupdate cannot extract old tree from already-updated src. So anyone forgotton bootstrapping is forced to roll back src for bootstrapping and roll forward again BEFORE installworld, once mergemaster dissapears. > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Given Trump's claims about fairness in elections, his notion of a > "fair trial" is almost certainly at variance with objective reality. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. -- Tomoaki AOKI
Re: Has the update procedure changed?
On Tue, 8 Aug 2023 23:22:32 -0700
Kevin Oberman wrote:
> On Mon, Aug 7, 2023 at 9:12 AM Matthias Apitz wrote:
>
> > El día lunes, agosto 07, 2023 a las 08:51:55a. m. -0700, Kevin Oberman
> > escribió:
> >
> > > On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers wrote:
> > >
> > > >
> > > >
> > > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman
> > wrote:
> > > >
> > > >
> > > > On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz
> > wrote:
> > > >
> > > >> In the past I was used to use the following procedure to install a new
> > > >> kernel and world:
> > > >>
> > > >> # cd /usr/src
> > > >> # make installkernel
> > > >> # shutdown -r now
> > > >>
> > > >> boot -s from the loader prompt
> > > >>
> > > >> # adjkerntz -i
> > > >> # mount -a -t ufs
> > > >> # mergemaster -p
> > > >> # cd /usr/src
> > > >> # make installworld
> > > >> # mergemaster
> > > >> # yes | make delete-old
> > > >> # yes | make delete-old-libs
> > > >>
> > > >> # reboot
> > > >>
> > > ...
> >
> > > I am more confused about "etcupdate -p". Both files put it after the
> > > kernel installation and reboot but before the installworld. The man page
> > > for etcupdate says that '-p' it should be run before "make buildworld"
> > and
> > > I have always followed the man pages.
> >
> > The man page of mergemaster says:
> >
> > -p Pre-buildworld mode.
> >
> "
>
> >
> > i.e. it must be run after installkernel and before installworld to
> > adjust the new /etc/group and /etc/master.passwd. After installworld
> > mergemaster
> > should be run (or etcupdate) without -p to adjust all the scripts below
> > /etc, /etc/rc.d/ ... I've used this procedure above for many years and
> > it always let me decide it I want the new or the old or deal later with
> > the diff of all these files. And so I did it yesterday and it worked fine
> > again.
> >
> > Will check the next time what etcupdate wants to do, because it seems
> > the sucsessor of mergemaster.
> >
> > matthias
> >
> > --
> > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> > +49-176-38902045
> > Public GnuPG key: http://www.unixarea.de/key.pub
> >
>
> etcupdate is the successor to mergemaster. It is vastly better, but does
> have a learning curve when you first start using it. Also, it has quite a
> few commands that are seldom needed and I think that intimidates people a
> bit. Unless you understand a three-way merge, it is confusing. It's not
> complicated, but different from mergemster. (freebsd-update always has done
> a three-way merge.)
>
> I don't see how you get this from the man page.
> "Compares only files known to be
> essential to the success of {build|install}world, i.e.,
> /etc/group and /etc/master.passwd.
>
> If it is potentially updating files that MIGHT be essential to a successful
> buildworld, running it after buildkernel seems quite wrong. At least I read
> {build|install}world as buildworld or installworld.
>
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Please correct me if I'm missing something.
I use source update for years and not using bsdinstall nor
freebsd-update.
Does bsdinstall (and/or freebsd-update) create the first current tree
for etcupdate, if not yet exists?
This would be most confusing and harmful point of etcupdate.
When I first tried etcupdate, I didn't noticed that I needed
`etcupdate extract -B` BEFORE UPDATING src tree.
Without this, etcupdate cannot detect what should be updated, even if a
plenty of updates are required.
At the moment, I must use mergemaster, and after that, `etcupdate
extract -B` for next run.
I think bsdinstall can create current tree, which is turned over to old
tree on actual run, for etcupdate.
So do freebsd-update. It would be able to create current tree JUST
BEFORE INSTALLING UPDATE.
I was helped by mergemaster, but after it completely retires, features
above should be mandatory.
--
Tomoaki AOKI
freebsd-current@freebsd.org
On Tue, 8 Aug 2023 17:02:32 +0300 Konstantin Belousov wrote: > On Tue, Aug 08, 2023 at 10:46:12PM +0900, Tomoaki AOKI wrote: > > On Tue, 8 Aug 2023 15:38:46 +0300 > > Konstantin Belousov wrote: > > > > > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote: > > > > On Sun, 6 Aug 2023 12:55:07 +0300 > > > > Konstantin Belousov wrote: > > > > > > > > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > > > > > On Wed, 23 Feb 2022 01:30:28 +0200 > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > > > > > Ok, the next step is to get the CPU feature reports from P- > > > > > > > > > vs. E- cores. > > > > > > > > > Patch below should work, with verbose boot. > > > > > > > > > > > > > > > > Not much difference on that level: > > > > > > > > > > > > > > > > --- zzzp2022-02-22 18:18:24.531704000 -0500 > > > > > > > > +++ zzze2022-02-22 18:18:18.631236000 -0500 > > > > > > > > @@ -1,22 +1,21 @@ > > > > > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz > > > > > > > > K8-class CPU) > > > > > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz > > > > > > > > K8-class CPU) > > > > > > > >Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 > > > > > > > > Stepping=2 > > > > > > > > Features=0xbfebfbff > > > > > > > > Features2=0x7ffafbff > > > > > > > >AMD Features=0x2c100800 > > > > > > > >AMD Features2=0x121 > > > > > > > >Structured Extended > > > > > > > > Features=0x239ca7eb > > > > > > > >Structured Extended > > > > > > > > Features2=0x98c027ac > > > > > > > >Structured Extended > > > > > > > > Features3=0xfc1cc410 > > > > > > > >XSAVE Features=0xf > > > > > > > > > > > > > > > > IA32_ARCH_CAPS=0xd6b > > > > > > > >VT-x: Basic Features=0x3da0500 > > > > > > > > Pin-Based > > > > > > > > Controls=0xff > > > > > > > > Primary Processor > > > > > > > > Controls=0xfffbfffe > > > > > > > > Secondary Processor > > > > > > > > Controls=0xf5d7fff > > > > > > > > Exit Controls=0x3da0500 > > > > > > > > Entry Controls=0x3da0500 > > > > > > > > EPT > > > > > > > > Features=0x6f34141 > > > > > > > > VPID > > > > > > > > Features=0x10f01 > > > > > > > >TSC: P-state invariant, performance statistics > > > > > > > > -64-Byte prefetching > > > > > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > > > > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > > > > > > > > > As another blind guess, try to disable pcid, > > > > > > > vm.pmap.pcid_enabled=0. > > > > > > > > > > > > > > > > > > > Hi. > > > > > > > > > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > > > > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > > > > > Japanese). [1] > > > > > > Crashes with UFS, but ZFS is claimed to be OK. > > > > > > > > > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > > > > > So check logics on workarouund codes (IIRC, all are MFC'ed before > > > > > > 13.2) > > > > > > wo
freebsd-current@freebsd.org
On Tue, 8 Aug 2023 15:38:46 +0300 Konstantin Belousov wrote: > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote: > > On Sun, 6 Aug 2023 12:55:07 +0300 > > Konstantin Belousov wrote: > > > > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > > > On Wed, 23 Feb 2022 01:30:28 +0200 > > > > Konstantin Belousov wrote: > > > > > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > > > Ok, the next step is to get the CPU feature reports from P- vs. > > > > > > > E- cores. > > > > > > > Patch below should work, with verbose boot. > > > > > > > > > > > > Not much difference on that level: > > > > > > > > > > > > --- zzzp2022-02-22 18:18:24.531704000 -0500 > > > > > > +++ zzze2022-02-22 18:18:18.631236000 -0500 > > > > > > @@ -1,22 +1,21 @@ > > > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class > > > > > > CPU) > > > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class > > > > > > CPU) > > > > > >Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 > > > > > > Stepping=2 > > > > > > Features=0xbfebfbff > > > > > > Features2=0x7ffafbff > > > > > >AMD Features=0x2c100800 > > > > > >AMD Features2=0x121 > > > > > >Structured Extended > > > > > > Features=0x239ca7eb > > > > > >Structured Extended > > > > > > Features2=0x98c027ac > > > > > >Structured Extended > > > > > > Features3=0xfc1cc410 > > > > > >XSAVE Features=0xf > > > > > > > > > > > > IA32_ARCH_CAPS=0xd6b > > > > > >VT-x: Basic Features=0x3da0500 > > > > > > Pin-Based Controls=0xff > > > > > > Primary Processor > > > > > > Controls=0xfffbfffe > > > > > > Secondary Processor > > > > > > Controls=0xf5d7fff > > > > > > Exit Controls=0x3da0500 > > > > > > Entry Controls=0x3da0500 > > > > > > EPT > > > > > > Features=0x6f34141 > > > > > > VPID > > > > > > Features=0x10f01 > > > > > >TSC: P-state invariant, performance statistics > > > > > > -64-Byte prefetching > > > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > > > > Hi. > > > > > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > > > Japanese). [1] > > > > Crashes with UFS, but ZFS is claimed to be OK. > > > > > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > > > wouldn't be working? > > > > > > Show me the output from x86info -r on the machine, I do not care which > > > specific core it is, they should be all the same. x86info is available > > > as sysutils/x86info. > > > > Requested to original reporter and got the result below. > > HTH. > > > > --- > > root@eq12:~ # x86info -r > > x86info v1.31pre > > /dev/cpuctl0: No such file or directory > > Found 4 identical CPUs > > Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 > > Type: 0 (Original OEM) > > CPU Model (x86info's best guess): Unknown model. > ... > > eax in: 0x001a, eax = 2001 ebx = ecx = edx = > > > > The CPU is reported as small core/atom, so the workaround is turned on. > I do not think that the issue reported is related to the TLB/PG_G errata. > > Why do you think that this is hw issue at all, and not some software bug > in the build etc ? Because the issue looks similar (crashes on UFS but not ZFS, and as far as the original reporter tested, vm.pmap.pcid_enabled=0 in /boot/loader.conf helped). Moreover, N100 CPU is Alder Lake-N. So potentially includes the same design issue (common circuits, firmwares, ...). So I suspected the same problem persists even without P-core and adviced the original reporter to add the workaround in /boot/loader.conf. It seems to help until now. -- Tomoaki AOKI
freebsd-current@freebsd.org
On Sun, 6 Aug 2023 12:55:07 +0300 Konstantin Belousov wrote: > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > On Wed, 23 Feb 2022 01:30:28 +0200 > > Konstantin Belousov wrote: > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- > > > > > cores. > > > > > Patch below should work, with verbose boot. > > > > > > > > Not much difference on that level: > > > > > > > > --- zzzp2022-02-22 18:18:24.531704000 -0500 > > > > +++ zzze2022-02-22 18:18:18.631236000 -0500 > > > > @@ -1,22 +1,21 @@ > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > >Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > > Features=0xbfebfbff > > > > Features2=0x7ffafbff > > > >AMD Features=0x2c100800 > > > >AMD Features2=0x121 > > > >Structured Extended > > > > Features=0x239ca7eb > > > >Structured Extended > > > > Features2=0x98c027ac > > > >Structured Extended > > > > Features3=0xfc1cc410 > > > >XSAVE Features=0xf > > > >IA32_ARCH_CAPS=0xd6b > > > >VT-x: Basic Features=0x3da0500 > > > > Pin-Based Controls=0xff > > > > Primary Processor > > > > Controls=0xfffbfffe > > > > Secondary Processor > > > > Controls=0xf5d7fff > > > > Exit Controls=0x3da0500 > > > > Entry Controls=0x3da0500 > > > > EPT Features=0x6f34141 > > > > VPID > > > > Features=0x10f01 > > > >TSC: P-state invariant, performance statistics > > > > -64-Byte prefetching > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > Hi. > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > Japanese). [1] > > Crashes with UFS, but ZFS is claimed to be OK. > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > wouldn't be working? > > Show me the output from x86info -r on the machine, I do not care which > specific core it is, they should be all the same. x86info is available > as sysutils/x86info. Requested to original reporter and got the result below. HTH. --- root@eq12:~ # x86info -r x86info v1.31pre /dev/cpuctl0: No such file or directory Found 4 identical CPUs Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 Type: 0 (Original OEM) CPU Model (x86info's best guess): Unknown model. eax in: 0x, eax = 0020 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 0x0001, eax = 000b06e0 ebx = 00800800 ecx = 7ffafbbf edx = bfebfbff eax in: 0x0002, eax = 00feff01 ebx = 00f0 ecx = edx = eax in: 0x0003, eax = ebx = ecx = edx = eax in: 0x0004, eax = fc004121 ebx = 01c0003f ecx = 003f edx = eax in: 0x0005, eax = 0040 ebx = 0040 ecx = 0003 edx = 10102020 eax in: 0x0006, eax = 00578ff7 ebx = 0002 ecx = 0009 edx = eax in: 0x0007, eax = 0002 ebx = 239ca7eb ecx = 98c007bc edx = fc184410 eax in: 0x0008, eax = ebx = ecx = edx = eax in: 0x0009, eax = ebx = ecx = edx = eax in: 0x000a, eax = 07300605 ebx = ecx = 0007 edx = 8603 eax in: 0x000b, eax = 0001 ebx = 0001 ecx = 0100 edx = eax in: 0x000c, eax = ebx = ecx = edx = eax in: 0x000d, eax = 0207 ebx = 0a88 ecx = 0a88 edx = eax in: 0x000e, eax = ebx = ecx = edx = eax in: 0x000f, eax = ebx = ecx = edx = eax in: 0x0010, eax = ebx = 0004 ecx = edx =
freebsd-current@freebsd.org
On Wed, 23 Feb 2022 01:30:28 +0200 Konstantin Belousov wrote: > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > Patch below should work, with verbose boot. > > > > Not much difference on that level: > > > > --- zzzp2022-02-22 18:18:24.531704000 -0500 > > +++ zzze2022-02-22 18:18:18.631236000 -0500 > > @@ -1,22 +1,21 @@ > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > >Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > Features=0xbfebfbff > > Features2=0x7ffafbff > >AMD Features=0x2c100800 > >AMD Features2=0x121 > >Structured Extended > > Features=0x239ca7eb > >Structured Extended > > Features2=0x98c027ac > >Structured Extended > > Features3=0xfc1cc410 > >XSAVE Features=0xf > >IA32_ARCH_CAPS=0xd6b > >VT-x: Basic Features=0x3da0500 > > Pin-Based Controls=0xff > > Primary Processor > > Controls=0xfffbfffe > > Secondary Processor > > Controls=0xf5d7fff > > Exit Controls=0x3da0500 > > Entry Controls=0x3da0500 > > EPT Features=0x6f34141 > > VPID Features=0x10f01 > >TSC: P-state invariant, performance statistics > > -64-Byte prefetching > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > Show me the full verbose dmesg of the boot then. > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > Hi. Intel N100 is reported to crash without this tunable on 13.2 at freebsd-users-jp ML (as this is a ML in Japanese, reported in Japanese). [1] Crashes with UFS, but ZFS is claimed to be OK. N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) wouldn't be working? Sorry, I'm just a liaison here and do not have any actual affected haedware (means that cannot test at all myself). The reporter claims that the actual hardware is as follows. Beelink EQ12 intel N100, 16GB-DDR5,512GB M.2 SSD [4] Working states are reported as follows. Installed to ZFS: OK Stock 13.2 without any custom tunalble: Crash with UFS Tunable vm.pmap.pcid_enabled=0 in /boot/loader.conf: No crash reported with situation below. *Add "vm.pmap.pcid_enabled=0" on /boot/loader (on installed geom) just after the installation finished. *Reboot to the installed partition. *`portsnap fetch extract` *`cd /usr/ports/ports-mgmt/portmaster ; make install clean` *`portmaster www/apache24` And any other operations after above are claimed OK. Tunable vm.pmap.pcid_invlpg_workaround=1 instead above: Better than stock 13.2, but crashes on `portmaster www/apache24` of the procedures above. [1] https://lists.freebsd.org/archives/freebsd-users-jp/2023-July/000205.html [2] https://www.intel.com/content/www/us/en/products/sku/231803/intel-processor-n100-6m-cache-up-to-3-40-ghz/specifications.html [3] https://en.wikipedia.org/wiki/Alder_Lake [4] https://www.bee-link.com/eq12-n100-clone-1-82615581 Regards. -- Tomoaki AOKI
Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others
On Sun, 02 Jul 2023 14:41:55 +0900 (JST)
Yasuhiro Kimura wrote:
> From: Nuno Teixeira
> Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required by
> "pkg" and others
> Date: Sun, 2 Jul 2023 06:22:48 +0100
>
> > Hello all,
> >
> > I'm returning to current and installed from
> > 20230622-b95d2237af40-263748-bootonly.iso and upgraded to cab2d43b83b
> > (amd64).
> >
> > Did a magnific delete-old and delete-old-libs and now a lot of packages
> > complain about "ld-elf.so.1: Shared object "libssl.so.111" not found,
> > required by..."
> >
> > To fix it I rebooted with BE from first instalation since I used
> > beinstall.sh for upgrade.
> >
> > I know that a lot of things happened in the last days with llvm15->llvm16,
> > openssl3, etc.
> >
> > My question is when can I do a delete-old{-libs}?
> > I'm thinking building pkgs with a updated current on poudriere and then
> > clean up libs?
> >
> > Thanks,
>
> The source of the issue is the migration from OpenSSL 1.1.1 to 3.0.
>
> So if you use packages built by yourself (e,g. by using poudriere,
> portmaster, porupgrade, etc. or simply 'make install'), then you
> should rebuild and reinstall all packages and then should do
> `make delete-old-libs`.
>
> If you use official binary packages, then you should wait until all
> packages are built with OpenSSL 3.0.
>
> HTH.
>
> ---
> Yasuhiro Kimura
FYI:
I basically never `make delete-old-libs` blindly.
First, run `make check-old-libs` and record the result.
Then, create an ad-hoc script to check for affected ports installed and
generate updating script.
Then, look into the temporary list generated (or generated script) if
any port should be actually rebuilt.
Run the generated script if needed.
Attached is the quick and ugly ad-hoc script I used this time.
Beware! This generates updating script requiring ports-mgmt/pkg_replace.
Edit it to use whatever you want.
If you're using poudriere[-devel], it should rebuild everything.
I don't use poudriere on main, as it should force me tooo many full
rebuilds than on stable/* branches.
If letting poudriere to rebuild everything and configured local repo,
`pkg upgrade` would do the right thing, maybe.
--
Tomoaki AOKI
#!/bin/sh
#Posted Feb.25,2015 to FreeBSD-current ML by Mark Millard
#Modified by Tomoaki AOKI to generate upgrading script for portupgrade.
# Define files to (temporarily) generate.
OLDLIB="base_openssl"
CHECKPREFIX1="/lib/libcrypto"
CHECKFORRE1="${CHECKPREFIX1}[^ ]*\.so\.111"
CHECKPREFIX2="/usr/lib/libssl"
CHECKFORRE2="${CHECKPREFIX2}[^ ]*\.so\.111"
CHECKPREFIX3="/usr/lib32/libcrypto"
CHECKFORRE3="${CHECKPREFIX3}[^ ]*\.so\.111"
CHECKPREFIX4="/usr/lib32/libssl"
CHECKFORRE4="${CHECKPREFIX4}[^ ]*\.so\.111"
DETECTED="/tmp/${OLDLIB}deps0"
NeedUpdate="/tmp/${OLDLIB}deps"
ActualScript="/tmp/rebuild_${OLDLIB}_deps.sh"
# echo CHECKFORRE is ${CHECKFORRE}
# Define pre processing procedure if needed (optional).
PreUpdate="CurDir=\`pwd\`"
# Define port updating program of your choice.
UpdateProgram="pkg_replace -l /usr/ports/${OLDLIB}_deps-\`date \"+%Y%m%d%H%M%S\"\`.log -c -m 'WITH+=NVIDIA,NVIDIA_GL DISABLE_VULNERABILITIES=yes' -v -W -w -b -f"
# Define post processing procedure if needed (optional).
PostUpdate="cd \${CurDir} && portsclean -C"
if [ -f ${DETECTED} ] ; then
rm ${DETECTED}
fi
if [ -f ${NeedUpdate} ] ; then
rm ${NeedUpdate}
fi
# find /usr/local/*bin* /usr/local/lib* -type f \
# | xargs ldd -f '%p %A\n' 2>&1 | grep "^/lib/libncurses[^ ]*\.so\.8" | cut -w -f2 \
# | xargs ldd -a | egrep '(^/.*:$| /lib/libncurses[^ ]*\.so\.8 )' \
# | grep -B1 " /lib/libncurses" | grep "^/.*:$" | sed -e's;:$;;' \
# | xargs pkg which -q -o | sort -u
## Unfortunetely, this didn't work if second ldd includes shell variable.
## Always edit it manually as CHECKFORRE.
#
#find /usr/local/*bin* /usr/local/lib* -type f \
#| xargs ldd -f '%p %A\n' 2>&1 | grep "^${CHECKFORRE}" | cut -w -f2 \
#| xargs ldd -a | egrep '(^/.*:$| /lib/libncurses[^ ]*\.so\.8 )' \
#| grep -B1 " ${CHECKPREFIX}" | grep "^/.*:$" | sed -e's;:$;;' \
#| xargs pkg which -q -o | sort -u > ${NeedUpdate}
## Replacing single quotes with double quotes for egrep allowed using shell variable.
find /usr/local/*bin* /usr/local/lib* -type f \
| xargs ldd -f '%p %A\n' 2>&1 | grep "^${CHECKFORRE1}" | cut -w -f2 \
| xargs ldd -a | egrep "(^/.*:$| ${CHECKFORRE1} )" \
| grep -B
Re: Where did the nvd devices go?
Maybe I'm wrong, but does D25168 "geom(4): Look for aliases when searching for providers by name" [1], which is already accepted but not yet committed, help? [1] https://reviews.freebsd.org/D25168 On Wed, 21 Jun 2023 23:07:51 -0700 Kevin Oberman wrote: > Just found another breakage due to nvd becoming a symlimk. I use gkrellm as > my system monitor and, after the update, my SSD showed no activity. Easy > fix to edit the configuration to disable nvd0 and enable nda0, but another > case of a tool not following the symlink. > > If I get a little time tomorrow. I'll try finding the code in gkrellm and > see if I can figure out whether the breakage is a roble in the port or a > system issue, but no promises. > > On Wed, Jun 21, 2023 at 8:43 PM Warner Losh wrote: > > > > > > > On Wed, Jun 21, 2023 at 8:47 PM Kevin Oberman wrote: > > > >> > >> Commands used were "gpart show nvd0" and "geli attach -d -k > >> /dev/nvd0p7". Also tried both with and without the "/dev" which fail for > >> nvd* and succeed with nda*. > >> > > > > Ah. I see the problem. libgeom doesn't parse the nodes, nor does > > it use them when searching for a geom by name... > > > > I need to carefully think about how to fix it, though, since it may be an > > ABI change and we're getting trickily close > > to 14 to be mucking with this... > > > > Warner > > > > > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 -- Tomoaki AOKI
Re: Help request: strange issue with xfce xfwm4 on AMD hardware, running head
On Mon, 29 May 2023 21:05:42 +0200
Guido Falsi wrote:
> On 28/05/23 20:45, Guido Falsi wrote:
>
> >> It may well be something broke... but I'm just wanting to be double
> >> sure it's against a consistent package set. If something broke, then I
> >> can't help.
> >
> > I see, I did not understand what you meant at first.
> >
> > What I posted was the result of a simple "pkg upgrade", which is what I
> > usually do to update the machine, and usually works quite fine.
> >
> > I have not tested forcing all packages reinstallation ("pkg upgrade -f"
> > if I get it correctly).
> >
> > That is something I was already planning to do. Will report back
> > tomorrow for that.
> >
>
> Well forcing reinstallation of all ports (with rebuilt kmod ports) made
> the issue disappear.
>
> SO it looks like it was really nothing. Sorry for the noise and thanks
> for the suggestions!
>
> --
> Guido Falsi
IIRC, drm*-kmod port didn't seem to be updated in the first place.
OTOH, generic kernel seems to be updated via pkgbase.
This could cause problems with incompatibilities.
And fixed with forcibly updating all pkgs.
poudliere built new pkg, but pkg doesn't thought it's updated , maybe.
--
Tomoaki AOKI
Re: Surprise null root password
On Fri, 26 May 2023 16:26:06 -0700 bob prohaska wrote: > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote: > > > > The question is how you update the configuration files, > > mergemaster/etcupdate/something else? > > > > Via etcupdate after installworld. In the event the system > requests manual intervention I accept "theirs all". It seems > odd if that can null a root password. > > Still, it does seem an outside possibility. I could see it adding > system users, but messing with root's existing password seems a > bit unexpected. > > Thanks very much for raising the point! > > bob prohaska Maybe that's it. As you chose "theirs all" (maybe theirs-full?), conflicted files (include /etc/master.passwd) are overwritten by brand-new default ones. You should choose "(e) edit" and manually merge them correctly. -- Tomoaki AOKI
Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support
On Fri, 12 May 2023 07:05:37 -0700 (PDT) "Rodney W. Grimes" wrote: > > On Thu, 11 May 2023 23:08:30 +0200 > > Yuri wrote: > > > > > Warner Losh wrote: > > > > > > > > > > > > On Thu, May 11, 2023, 2:50 PM Rodney W. Grimes > > > > mailto:freebsd-...@gndrsh.dnsmgr.net>> > > > > wrote: > > > > > > > > > On Thu, May 11, 2023, 2:16 PM Yuri > > > <mailto:y...@aetern.org>> wrote: > > > > > > > > > > > Warner Losh wrote: > > > > > > > The branch main has been updated by imp: > > > > > > > > > > > > > > URL: > > > > > > > > > > > > > > https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > > > > > > > > <https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0> > > > > > > > > > > > > > > commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > > > > > > > Author:? ? ?Warner Losh > > > > > > > AuthorDate: 2023-05-11 20:04:12 + > > > > > > > Commit:? ? ?Warner Losh > > > > > > > CommitDate: 2023-05-11 20:06:03 + > > > > > > > > > > > > > >? ? ?stand/efi: Retire i386 support > > > > > > > > > > > > > >? ? ?Remove the i386 ifdefs and files. It never worked. > > > > > > > > > > > > > >? ? ?Sponsored by:? ? ? ? ? ?Netflix > > > > > > >? ? ?Reviewed by:? ? ? ? ? ? manu, tsoome, kevans > > > > > > >? ? ?Differential Revision:? https://reviews.freebsd.org/D40012 > > > > <https://reviews.freebsd.org/D40012> > > > > > > > > > > > > As this question seems to be asked a lot on the forums, does > > > > this mean > > > > > > we will never support the 32bit efi booting 64bit OS? > > > > > > > > > > > > > > > > Yes. It means we've given up on that. Such environments are rare > > > > these > > > > > days, as far as I know, so unless someone shows up with something > > > > that > > > > > works perfectly with a qemu testing recipe that we can roll it > > > > into out > > > > > test bed. Plus some kind of info on real hardware that does this > > > > that's > > > > > popular enough to justify inclusion. > > > > > > > > I have only ever seen 1 implementation of x86 32bit efi, and it was > > > > such a pile of turds I just scrapped the machine. > > > > > > > > > > > > That was my experience as well, so I biased my action towards just > > > > removing it. If it turns out my experience was somehow atypical and > > > > these are popular and very much robust, I'm open to learning about it. > > > > > > I just noticed that it was asked several times in the last few months > > > trying to use FreeBSD on not-so-modern and rather exotic hardware; I > > > don't think we really need that support, but I simply wasn't aware of > > > efi32 status before this commit, hence I asked :) > > > > Just a FYI. > > > > A subscriber (not me) tried ASUS EeeBook X205TA (manufactured "2015-04") > > through Mar.18, 2021 to Apr.13, 2021 without luck on freebsd-usrs-jp ML > > (in Japanese, started from [1], [2] for April). > > > > Atom CPU Z3735F @1.33GHz, 2GB RAM > > That is a 4 core 64 bit CPU, it most likely has a 64bit efi > implementation. Exactly. I'd found the info while discussing with the reporter on freebsd-uses-jp ML at Intel site. Note that neither boot1.efi nor loader.efi shipped with FreeBSD i386 distribution couldn't boot kernel successfully (built but not working). So I have no objection for discontinueing the support. > > Shipped with "Windows 8.1 with Bing (32bit)" installed. > > Probably a good choice to use a 32 bit OS on a machine > with only 2GB as there is no need for a 64 bit pointer. > This pretty much applies to any machine with 4GB or > less of memory IIRC, I've read somewhere describing that ASUS EeeBook X205TA has 32bit UEFI to boot 32bit Windoze, and supports 32bit UEFI boot only. I've found folowing pages now, different pages I read ATM, though. https://github.com/filirnd/x205ta https://forums.linuxmint.com/viewtopic.php?t=380177 > > > > > [1] > > https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-March/001728.html > > > > [2] > > https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-April/001746.html > > > > > > -- > > Tomoaki AOKI] > > > > > > -- > Rod Grimes rgri...@freebsd.org > -- Tomoaki AOKI
Re: git: c16e08e5f324 - main - stand/efi: Retire i386 support
On Thu, 11 May 2023 23:08:30 +0200 Yuri wrote: > Warner Losh wrote: > > > > > > On Thu, May 11, 2023, 2:50 PM Rodney W. Grimes > > mailto:freebsd-...@gndrsh.dnsmgr.net>> > > wrote: > > > > > On Thu, May 11, 2023, 2:16 PM Yuri > <mailto:y...@aetern.org>> wrote: > > > > > > > Warner Losh wrote: > > > > > The branch main has been updated by imp: > > > > > > > > > > URL: > > > > > > > > https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > > > > <https://cgit.FreeBSD.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0> > > > > > > > > > > commit c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > > > > > Author: Warner Losh > > > > > AuthorDate: 2023-05-11 20:04:12 + > > > > > Commit: Warner Losh > > > > > CommitDate: 2023-05-11 20:06:03 + > > > > > > > > > > stand/efi: Retire i386 support > > > > > > > > > > Remove the i386 ifdefs and files. It never worked. > > > > > > > > > > Sponsored by: Netflix > > > > > Reviewed by: manu, tsoome, kevans > > > > > Differential Revision: https://reviews.freebsd.org/D40012 > > <https://reviews.freebsd.org/D40012> > > > > > > > > As this question seems to be asked a lot on the forums, does > > this mean > > > > we will never support the 32bit efi booting 64bit OS? > > > > > > > > > > Yes. It means we've given up on that. Such environments are rare these > > > days, as far as I know, so unless someone shows up with something that > > > works perfectly with a qemu testing recipe that we can roll it > > into out > > > test bed. Plus some kind of info on real hardware that does this > > that's > > > popular enough to justify inclusion. > > > > I have only ever seen 1 implementation of x86 32bit efi, and it was > > such a pile of turds I just scrapped the machine. > > > > > > That was my experience as well, so I biased my action towards just > > removing it. If it turns out my experience was somehow atypical and > > these are popular and very much robust, I'm open to learning about it. > > I just noticed that it was asked several times in the last few months > trying to use FreeBSD on not-so-modern and rather exotic hardware; I > don't think we really need that support, but I simply wasn't aware of > efi32 status before this commit, hence I asked :) Just a FYI. A subscriber (not me) tried ASUS EeeBook X205TA (manufactured "2015-04") through Mar.18, 2021 to Apr.13, 2021 without luck on freebsd-usrs-jp ML (in Japanese, started from [1], [2] for April). Atom CPU Z3735F @1.33GHz, 2GB RAM Shipped with "Windows 8.1 with Bing (32bit)" installed. [1] https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-March/001728.html [2] https://lists.freebsd.org/pipermail/freebsd-users-jp/2021-April/001746.html -- Tomoaki AOKI]
Re: 1 year src-patch anniversary!
On Mon, 30 Jan 2023 03:54:48 +0100
"Julian H. Stacey" wrote:
> Jamie Landeg-Jones wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
> > to an admittedly trivial issue, but it's soon going to hit one year old,
> > and has not had any feedback. Not even "this is rubbish. close ticket"
> >
> > | jamie@catwalk:~ % stat 'so good they named it twice'
> > | stat: so good they named it twice: stat: No such file or directory
> >
> > As such, it's the oldest of my patches to be completely ignored, but then,
> > most of my fixes I haven't even submitted, because, what's the point?
> > I've instead spent time writing something so the patches are automatically
> > aplied to my src tree, and distributed to all my servers.
>
> I wrote a tool in 1993 I still use
> http://www.berklix.com/~jhs/bin/.csh/customise
> to apply trees of generic & personal diffs to src & ports, for multi releases
> http://www.berklix.com/~jhs/src/
> to apply diffs, where some are submitted, some committed
> for some versions, some diffs still needed for older versions, &
> some not submitted or committed.
>
> I guess many, especially non-commiters, maintain trees of uncommited
> diffs & there's probably other applicator scripts, numerous
> re-inventing of wheels for decades, 'cos send-pr /
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid
> commiters can't keep up with submissions.
>
> & non committers can't afford to wait months or years, remembering
> what's been seen commited to Release X.Y & what still needs to be
> kept to apply to other inc. older releases. Probably lots of
> re-invented wheels: trees of diffs & applicator scripts, but to
> different standards, not uniformly exportable, not immediately
> familiar to & usable by others.
>
> While retaining the model of "This generic src/ ports/ doc/ tree
> has been built from patches blessed by commiters as fit for all"
>
> FreeBSD hackers(especially non commiters who must wait for commits
> to reduce their heap of candidate diffs) would benefit from a unified
> set of tools & directory formats to allow individuals to maintain
> & export trees of candidate diffs etc to some common standards.
>
> It wouldnt obviate / replace send-pr &
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would
> be an optional normalied convenience, especially beneficial to those
> who are Not commiters but who have growing heaps of uncommited patches.
>
> Maybe a summer of code or other person might look at Jamie's & my
> applicator scripts, & diff tree shapes, not for our actual current diffs,
> but to design common unified standards to export trees of candidate diffs
> that can be applied by one common applicator tool ?
>
> Hacker who are not committers presumably accumulate an an ever
> growing heap of diffs, a burden best normalised & automated.
>
> > I know it's a volunteer effort, but I've been here 25 years, and whilst
> > I could (and should) take on more port-maintainership, any other offers
> > of help have fallen on deaf ears.
> >
> > *shrug* I miss Mark Linimon.
>
> Cheers,
> --
> Julian Stacey http://StolenVotes.UK/jhs/ Arm Ukraine, Zap Putin.
Just FYI:
Attached is the sh script I've been using for years to apply/revert
multiple patches at once, basically for patches uploaded on bugzilla.
I know it's far from perfect, but maybe handy for casual users who have
any problem with genuine base or ports and needs multiple patches
uploaded on bugzilla, phabricator or anywhere else.
The attachement itself should have been stripped by the ML server,
but maybe you can see it via "Original text of this message" link
at the bottom of the mail archive of this message.
--
Tomoaki AOKI
#!/bin/sh
# multipatch: Apply / revert multiple patches at once.
# Copyright (C) Mar. 16, 2017 by Tomoaki AOKI all rights reserved.
IGNORE_OPT="-p"
DRY_OPT="-C"
REV_OPT="-R -E"
DFL_OPT="-i"
OPTION=""
TMPFILE=/tmp/multipatch00
__usage() {
cat << EOF
Usage: multipatch (-fc | -f | -rc | -r | -h) filename
multipatch: Apply / revert multiple patches listed in filename.
The list file shall list one patchfile per line, lead by ignored depth.
Parameters:
-r : Revert listed patches.
-rc: Revert listed patches (dry run).
-f : Apply listed patches.
-fc: Apply listed patches (dry run).
-h: show this help
File format example:
1 ~/LocalPatches/patch1.diff
0 ~/LocalPatches/patch2.patch
where src filenames in patch1.diff is like a/sys/kern
Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87
On Thu, 12 Jan 2023 14:41:19 + Gary Jennejohn wrote: > On Thu, 12 Jan 2023 03:44:03 -0800 > David Wolfskill wrote: > > > On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote: > > > looks like we may need another 'unclean' workaround for this? > > > > > > Warner > > > > > > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn wrote: > > > ... > > > > I had this problem also. After deleting obj/usr the buildworld > > > > succeeded. > > > > > > > > > > > Empirically: > > rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic > > > > got through the issue on my build machine. (I expect that it will also > > do so on the others where I track head, but they are presently building > > lang/rust.) > > > > Perhaps an UPDATING entry would suffice? > > > > Didn't work for me when I decided to update my laptop, which had rather > old /usr/src contents. I ended up deleting obj/usr again. > > I installed the new world on my tower this morning. Now I see a new > problem. > > I don't know whether this new problem is related to the new tzcode, but > apps like gkrellm2 and xclock now display the time one hour earlier > than the actual time output by date(1), e.g. 10AM rather than 11AM. > > I had to set my /etc/localtime to GMT+0 to get the correct time output > even though I live in Germany and the correct value would be either > Europe/Berlin or CET. > > My laptop, which still has the old tzcode installed, did not exhibit > that weird error. > > -- > Gary Jennejohn Do you have /etc/wall_cmos_clock? Otherwise, FreeBSD base system thinks that the CMOS clock is set to UTC. A blank file (just `touch`ed to create) is enough. IIUC, your laptop has it, but your tower has none. -- Tomoaki AOKI
Re: What to do about a few lines in vfs_domount() never executed?
Tracking the commits, it was originally introduced to
sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by
dyson, submitted by h...@freebsd.org) and later centralized into
sys/kern/vfs_mount.c at r99264 [2].
But according to the comment above the codes, maybe it would be
intended to block userland programs or ports FS modules setting
MNT_EXPORTED.
If I'm not mis-understanding, it can be the case when
*vfs.usermount sysctl is non-zero,
*underlying FS (to be exported) allows it, and
*non-root user tries to mount the FS via NFS.
[1]
https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?revision=22521&view=markup&pathrev=99264
[2]
https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=22520&r2=22521&pathrev=99264&;
[3]
https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77
On Tue, 13 Dec 2022 14:19:39 -0800
Rick Macklem wrote:
> Hi,
>
> While working on getting mountd/nfsd to run in a vnet
> prison, I came across the following lines near the
> beginning of vfs_domount() in sys/kern/vfs_mount.c:
>
> if (fsflags & MNT_EXPORTED) {
> error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
> if (error)
>return (error);
> }
>
> #1 - Since MNT_EXPORTED is never set in fsflags, this code never
> gets executed.
> --> I am asking what to do with the above code, since that
> changes for the patch that allows mountd to run in a vnet
> prison.
> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
> because nothing in sys/kern/kern_priv.c checks
> PRIV_VFS_MOUNT_EXPORTED.
>
> I don't know what the original author's thinking was w.r.t. this.
> Setting exports already checks that the mount operation can be
> done by the requestor.
>
> So, what do you think should be done with the above code snippet?
> - Consider it cruft and delete it.
> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
> - Leave it as is. After the patch that allows mountd to run in
> a vnet prison, MNT_EXPORTED will be set in fsflags, but the
> priv_check() call will just return 0. (A little overhead,
> but otherwise no semantics change.)
>
> rick
--
Tomoaki AOKI
Re: CA's TLS Certificate Bundle in base = BAD
ks after the Washington Post exposed its connections to a US > military contractor, the Post reports. > > TrustCor Systems provided 'certificates' to browsers to Mozilla > Firefox and Microsoft Edge, which vouched for the legitimacy of said > websites. > > "Certificate Authorities have highly trusted roles in the internet > ecosystem and it is unacceptable for a CA to be closely tied, through > ownership and operation, to a company engaged in the distribution of > malware," said Mozilla's Kathleen Wilson in an email to browser > security experts. "Trustcor’s responses via their Vice President of CA > operations further substantiates the factual basis for Mozilla’s > concerns." > > According to TrustCor's Panamanian (!?) registration records, the > company has the same slate of officers, agents and officers as > Arizona-based Packet Forensics, which has sold communication > interception services to the U.S. government for over a decade. > > One of those contracts listed the “place of performance” as Fort > Meade, Md., the home of the National Security Agency and the > Pentagon’s Cyber Command. > > The case has put a new spotlight on the obscure systems of trust > and checks that allow people to rely on the internet for most > purposes. Browsers typically have more than a hundred authorities > approved by default, including government-owned ones and small > companies, to seamlessly attest that secure websites are what they > purport to be. -WaPo > > Also of concern, TrustCor's small staff in Canada lists its place of > operation at a UPS Store mail drop, according to company executive > Rachel McPherson, who says she told their Canadian staffers to work > remotely. She also acknowledged that the company has 'infrastructure' > in Arizona as well. > > McPherson says that ownership in TrustCor was transferred to employees > despite the fact that some of the same holding companies had invested > in both TrustCor and Packet Forensics. > > Various technologists in the email discussion said they found TrustCor > to be evasive when it came to basic facts such as legal domicile and > ownership - which they said was not appropriate for a company > responsible for root certificate authority that verifies a secure > 'https' website is not an imposter. > > The Post report built on the work of two researchers who had first > located the company’s corporate records, Joel Reardon of the > University of Calgary and Serge Egelman of the University of > California at Berkeley. Those two and others also ran experiments on a > secure email offering from TrustCor named MsgSafe.io. They found that > contrary to MsgSafe’s public claims, emails sent through its system > were not end-to-end encrypted and could be read by the company. > > McPherson said the various technology experts had not used the > right version or had not configured it properly. -WaPo > > In a previous case which illustrates the importance of trusting > root-level authorities - a security company controlled by the United > Arab Emirates, DarkMatter, applied in 2019 to have top-level root > authority from their status as an intermediate authority with less > independence. The request followed revelations that DarkMatter had > hacked dissidents and even some Americans - after which Mozilla denied > it root power. > > > "Received email from DDNS no-IP, they offering free TrustCor Standard > DV SSL certificate." > "Free, comes complete with spyveillance and exploit, lol." > "Imagine that even the most trusted CA's are actually rogue!" > > -- Tomoaki AOKI
Re: dmesg content lifetime
On Tue, 22 Nov 2022 19:13:18 +0100 Gary Jennejohn wrote: > On Wed, 23 Nov 2022 01:16:55 +0900 > Tomoaki AOKI wrote: > > > On Tue, 22 Nov 2022 09:47:10 -0600 (CST) > > Dan Mack wrote: > > > > > On Tue, 22 Nov 2022, Alexander Kabaev wrote: > > > > > > > On Tue, 22 Nov 2022 09:12:28 -0600 (CST) > > > > Dan Mack wrote: > > > > > > > >> It seems like dmesg content ages out over time. Is there a way to > > > >> leave the contents based on a fixed memory size instead? > > > >> > > > >> Dan > > > >> > > > > I think this is how it works: the kernel message bugger is of fixed > > > > size and kernel and syslog sequences (dmesg -a) share it. The other > > > > syslog users eventually puts enough content in there to displace all of > > > > kernel messages. If the kernel stays quiet, 'dmesg' then returns > > > > nothing, as by default it filters syslog entries that do not KERN > > > > facility out, see sbin/dmesg/dmesg.c. > > > > > > > > -- > > > > Alexander Kabaev > > > > > > > > > > Thank you Alexander, I did not know this. I'll USL (use-the-source-luke) > > > :-) > > > > > > Dan > > > > Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg > > to live longer. For example, recommended value by iwlwifi team is > > 1146880. Much larger than default. > > > > Note that this is actually a tunable and can be set only on boot time. > > > > Or look at /var/run/dmesg.boot. It doesn't get overwritten. > > -- > Gary Jennejohn It may be overwritten on reboot. And there are dmesg.[today|yesterday] on /var/log/, too. Rotated daily. -- Tomoaki AOKI
Re: ULE realtime scheduler advice needed
On Tue, 22 Nov 2022 22:38:04 +0100
Hans Petter Selasky wrote:
> On 11/22/22 20:28, mike tancsa wrote:
> > On 11/17/2022 11:47 PM, Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> I'm doing some work with audio and have noticed some problems with the
> >> ULE scheduler. I have a program that generate audio based on
> >> key-presses. When no keys are pressed, the load is near 0%, but as
> >> soon as you start pressing keys, the load goes maybe to 80% of a CPU
> >> core. This program I run with rtprio 8 xxx. The issue I observe or
> >> hear actually, is that it takes too long until the scheduler grasps
> >> that this program needs it's own CPU core and stops time-sharing the
> >> program. When I however use cpuset -l xxx rtprio 8 yyy everything is
> >> good, and the program outputs realtime audio in-time.
> >>
> >> Or is this perhaps a CPU frequency stepping issue?
> >>
> >> Any advice on where to look?
> >>
> > A long shot, but I am curious if by chance you have hwpstate_intel for
> > your cpu frequency driver. If so, does setting
> > dev.hwpstate_intel.0.epp=0 make any difference ?
> >
>
> Yes, I have four of those, set to 50 by default. Let me try.
>
> --HPS
FYI: I habitally run below manually (as root) when I'm on AC powerline.
sysctl -aN | fgrep dev.hwpstate | fgrep epp | while read OID ; do ; \
sysctl ${OID}=0 ; done
--
Tomoaki AOKI
Re: dmesg content lifetime
On Tue, 22 Nov 2022 09:47:10 -0600 (CST) Dan Mack wrote: > On Tue, 22 Nov 2022, Alexander Kabaev wrote: > > > On Tue, 22 Nov 2022 09:12:28 -0600 (CST) > > Dan Mack wrote: > > > >> It seems like dmesg content ages out over time. Is there a way to > >> leave the contents based on a fixed memory size instead? > >> > >> Dan > >> > > I think this is how it works: the kernel message bugger is of fixed > > size and kernel and syslog sequences (dmesg -a) share it. The other > > syslog users eventually puts enough content in there to displace all of > > kernel messages. If the kernel stays quiet, 'dmesg' then returns > > nothing, as by default it filters syslog entries that do not KERN > > facility out, see sbin/dmesg/dmesg.c. > > > > -- > > Alexander Kabaev > > > > Thank you Alexander, I did not know this. I'll USL (use-the-source-luke) > :-) > > Dan Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg to live longer. For example, recommended value by iwlwifi team is 1146880. Much larger than default. Note that this is actually a tunable and can be set only on boot time. -- Tomoaki AOKI
Re: ULE realtime scheduler advice needed
On Tue, 22 Nov 2022 13:15:33 +0100 Johan Hendriks wrote: > > On 21/11/2022 21:24, Hans Petter Selasky wrote: > > On 11/21/22 20:12, Mark Johnston wrote: > >> There were some bug fixes earlier this year to address problems where > >> high-priority threads were not getting scheduled quickly enough. If > >> you're using an old kernel, they might improve things: > > > > Are any of these fixes merged to stable/13 ? > > > > --HPS > > > It looks like it. > https://freshbsd.org/freebsd/src?q=sched_ule.c Or track PR on Bugzilla via commit logs on main (pointed by markj@) instead of Differential Revision on Phablicator. Phab shouldn't know about branches other than main this case. On Bugzilla, we can see each of them MFC'ed to stable/13 with second commit-hook. -- Tomoaki AOKI
Re: loader.conf and rootdev option for memory disk
But your previous post shows rootdev= there didn't work, and needed setting vfs.root.mountfrom=. OTOH, rootdev= is reported to work in efi/boot/freebsd/loader.env (with efi loader) on freebsd-users-jp ML (as it's Japanese ML, in Japanese) this year. So /boot/defaults/loader.conf (/usr/src/stand/defaults/loader.conf) should be fixed, and what should be set in loader.env should be documented. *Dedicated brand-new manpage or in boot.8 (or in loader.8 describing rootdev, or loader.conf.8 in contrast with itself). On Sat, 19 Nov 2022 22:31:42 +0100 Chlasták Miroslav wrote: > Look at the file /boot/defaults/loader.conf: > > … > ### Initial memory disk settings ### > #mdroot_load="YES" # The "mdroot" prefix is arbitrary. > #mdroot_type="md_image" # Create md(4) disk at boot. > #mdroot_name="/boot/root.img" # Path to a file containing the image. > #rootdev="ufs:/dev/md0" # Set the root filesystem to md(4) device. > … > > — > Mira > > > On 19 Nov 2022, at 21:58, Tomoaki AOKI wrote: > > > > IIUC, rootdev should be set in loader.env, if needed. > > `man 5 loader.conf` has nothing about rootdev variable. > > > > (It's undocumented, IIRC.) > > > > > > On Sat, 19 Nov 2022 19:57:47 +0100 > > Chlasták Miroslav mailto:m...@chlastak.cz>> wrote: > > > >> I have my device working for now - but the question is - Is the > >> documentation and example for “rootdev” right or not? > >> > >> — > >> Mira > >> > >>> On 18 Nov 2022, at 21:13, Warner Losh >>> <mailto:i...@bsdimp.com>> wrote: > >>> > >>> > >>> > >>> On Fri, Nov 18, 2022 at 12:57 PM Chlasták Miroslav >>> <mailto:m...@chlastak.cz> <mailto:m...@chlastak.cz > >>> <mailto:m...@chlastak.cz>>> wrote: > >>> Hi all, > >>> > >>> In the /boot/defaults/loader.conf are these options for memory disk > >>> settings: > >>> > >>> #mdroot_load="YES" # The "mdroot" prefix is arbitrary. > >>> #mdroot_type="md_image" # Create md(4) disk at boot. > >>> #mdroot_name="/boot/root.img" # Path to a file containing the image. > >>> #rootdev="ufs:/dev/md0" # Set the root filesystem to md(4) device. > >>> > >>> > >>> But - is this example for rootdev option still right? Because > >>> “ufs:/dev/md0” works fine on freebsd 12.1, but on freebsd 12.3 this does > >>> not work and generates error message: > >>> > >>> Can’t determine root device > >>> > >>> > >>> When I use this option with value “/dev/md0” or “md0” (even with this > >>> option commented out), so the machine boots correctly without any error. > >>> > >>> I think you want vfs.root.mountfrom= instead of rootdev= here. > >>> > >>> Warner > >>> > >>> — > >>> Mira > >> > > > > > > -- > > 青木 知明 [Tomoaki AOKI] > <mailto:junch...@dec.sakura.ne.jp>> > -- 青木 知明 [Tomoaki AOKI]
Re: loader.conf and rootdev option for memory disk
IIUC, rootdev should be set in loader.env, if needed. `man 5 loader.conf` has nothing about rootdev variable. (It's undocumented, IIRC.) On Sat, 19 Nov 2022 19:57:47 +0100 Chlasták Miroslav wrote: > I have my device working for now - but the question is - Is the documentation > and example for “rootdev” right or not? > > — > Mira > > > On 18 Nov 2022, at 21:13, Warner Losh wrote: > > > > > > > > On Fri, Nov 18, 2022 at 12:57 PM Chlasták Miroslav > <mailto:m...@chlastak.cz>> wrote: > > Hi all, > > > > In the /boot/defaults/loader.conf are these options for memory disk > > settings: > > > > #mdroot_load="YES" # The "mdroot" prefix is arbitrary. > > #mdroot_type="md_image" # Create md(4) disk at boot. > > #mdroot_name="/boot/root.img" # Path to a file containing the image. > > #rootdev="ufs:/dev/md0" # Set the root filesystem to md(4) device. > > > > > > But - is this example for rootdev option still right? Because > > “ufs:/dev/md0” works fine on freebsd 12.1, but on freebsd 12.3 this does > > not work and generates error message: > > > > Can’t determine root device > > > > > > When I use this option with value “/dev/md0” or “md0” (even with this > > option commented out), so the machine boots correctly without any error. > > > > I think you want vfs.root.mountfrom= instead of rootdev= here. > > > > Warner > > > > — > > Mira > -- 青木 知明 [Tomoaki AOKI]
Re: ULE realtime scheduler advice needed
I've lost track with, but IIRC, someone wrote here, or other ML, or even forums, kern.sched.preempt_thresh=224 was the default for PC-BSD. And found some discussion started at [1] on freebsd-stable ML in Apr. 2018. One more place is at forums [2]. Sorry, not read all of them to confirm. [1] https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088678.html [2] https://forums.freebsd.org/threads/general-freebsd-desktop-workload-optimization-thread.21853/ On Sat, 19 Nov 2022 10:28:50 +0100 Hans Petter Selasky wrote: > Hi Alexander, > > Thank you for the pointers. > > I will try it out. > > --HPS > > On 11/18/22 09:18, Alexander Leidinger wrote: > > Quoting Hans Petter Selasky (from Fri, 18 Nov 2022 > > 05:47:58 +0100): > > > >> Hi, > >> > >> I'm doing some work with audio and have noticed some problems with the > >> ULE scheduler. I have a program that generate audio based on > >> key-presses. When no keys are pressed, the load is near 0%, but as > >> soon as you start pressing keys, the load goes maybe to 80% of a CPU > >> core. This program I run with rtprio 8 xxx. The issue I observe or > >> hear actually, is that it takes too long until the scheduler grasps > >> that this program needs it's own CPU core and stops time-sharing the > >> program. When I however use cpuset -l xxx rtprio 8 yyy everything is > >> good, and the program outputs realtime audio in-time. > > > > I have something in my mind about ULE not handling idleprio and/or > > rtprio correctly, but I have no pointer to a validation of this. > > > >> Or is this perhaps a CPU frequency stepping issue? > > > > You could play with > > rc.conf (/etc/rc.d/power_profile): > > performance_cpu_freq="HIGH" > > performance_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx > > economy_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx > > > > Your system may provide other Cx possibilities, and ging to a lower > > number (e.g. C1) means less power-saving but faster response from the > > CPU (I do not expect that this is causing the issue you have). > > > >> Any advice on where to look? > > > > Potential sysctl to play with to change "interactivity detection" in ULE: > > https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html > > > > Bye, > > Alexander. > > > -- Tomoaki AOKI
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On Sun, 13 Nov 2022 09:53:00 -0800 Steve Rikli wrote: > On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.free...@xs4all.nl wrote: > > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ the > > system stays active. > > However . that is also the end the GUI in this case GNOME. > > > > Since I could not work which a machine hibernating every ^10 minutes^, I > > have disabled gdm for the moment. > > That does not take away that that is .. ridiculous !! > > Seems like you aren't alone in that opinion -- there are several threads > for multiple OSes about this same topic. Kirk's findings below match my > recollection -- this is Gnome default behavior nowdays. > > In any case, since we obviously can't use the Linux systemD settings to > control the behavior in FreeBSD, a few folks mentioned other workarounds > with things like dconf; e.g. this suggestion which came originally from > the Arch linux folks: > > https://twitter.com/_neelc/status/1487200568149831681 > > https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28) > > Something like: > > sudo -u gdm dbus-launch gsettings set \ > org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing' > > >From the threads, it sounds like part of the problem is this behavior and > settings are per-user, so making a system-wide change is hard. Not sure > how this workaround will play in your situation. > > My FreeBSD servers don't run a gui display manager; my Debian laptop > runs gdm3 display manager but I switched to Xfce for the window manager > around the time Gnome3 came out (too many changes for my taste). Fwiw > the Xfce Power Manager has controls for system power save / sleep mode > for "On battery" and "Plugged in", including "never". Found these. https://unix.stackexchange.com/questions/289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just-created-ad https://askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-dconf /etc/ in those should be read /usr/local/etc/ on FreeBSD. And possibly defaults of each application are stored under /usr/local/share/ or under /usr/local/lib/. BTW, I'm basically using x11/mate, a fork from Gnome2. It doesn't sleep by default on AC powerline. (Old installation succeeding Gnome2 settings. So current default could be different, though.) > > Cheers, > sr. > > > > There should be a way to disable ACPI in FreeBSD so that even gdm can not > > "kill" the machine !! > > I say ^kill^ because there is also another bug, the machine is not properly > > restarting form hibernation, > > Even not from S1. > > > > Louis > > > > -Original Message- > > From: Kirk McKusick > > Sent: Sunday, November 13, 2022 1:23 AM > > To: louis.free...@xs4all.nl > > Cc: freebsd-current@FreeBSD.org > > Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? > > (on FreeBSD14 CURRENT) > > > > > From: > > > To: > > > Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? > > > (on FreeBSD14 CURRENT) > > > Date: Thu, 10 Nov 2022 21:29:21 +0100 > > > > > > I am still desperately trying to stop FreeBSD from sleeping, but I > > > simply do not manage. > > > > > > It is really very annoying that I have to restart the machine every > > > 10 minutes, when I am working via SSH. > > > > > > So if any one has a solution, it would be very much appreciated! > > > > > > It should ….. be possible to kill / stop ACPI some how 〓 > > > > > > If absolutely not possible in the actual build 〓, a cron job > > > restarting the timer every 5 minutes perhaps !!??? > > > > > > It is possible perhaps … that GNOME is initiating this, despite that > > > the GUI powersetting is screenblank “NEVER”. > > > > > > Whatever is causing the problem, the settings should be such that ^no > > > whatever program^ should not be capable to initiate the sleepmode. > > > > > > Louis > > > > If you are using Gnome, Gnome suspends the machine after 20 minutes if > > there is no mouse or keyboard activity. I went into settings, but there is > > no way to adjust this feature. Some web searching brought me to this page: > > > > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 > > > > Apparently the 20-minute suspend was made unchangable (at least not without > > changing the source code for Gnome and rebuilding it). > > Apparently this change was made to comply with EU power regulations. > > Anyway, this ruled out Gnome for me. > > > > Kirk McKusick > -- Tomoaki AOKI
Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main - rc(8): Add a zpoolupgrade rc.d script)
On Wed, 9 Nov 2022 14:12:21 -0800 Mark Millard wrote: > On Nov 9, 2022, at 12:56, Warner Losh wrote: > > > On Wed, Nov 9, 2022 at 1:54 PM Patrick M. Hausen wrote: > > > > > Am 09.11.2022 um 21:51 schrieb Warner Losh : > > > Yes. For safety, boot loader upgrade is mandatory when you do a zpool > > > upgrade of the root filesystem. > > > It was definitely needed in the OpenZFS jump, and we've had one or two > > > other flag days since. > > > > That's a given and not a problem. What I fear from my understanding of this > > thread so far is > > that there might be a situation when I upgrade the zpool and the boot > > loader and the system > > ends up unbootable nonetheless. > > > > Possible or not? > > > > If all you do is upgrade, then no, modulo bugs that we've thankfully not > > had yet. > > I guess you mean FreeBSD upgrade, not zpool updgrade? > > For zpool upgrade after a main [so: 14] FreeBSD upgrade . . . > > As I understand it, com.delphix:head_errlog was not added to > the loader until after some folks had done a zpool upgrade > and then could not boot. The loader was updated in response > to the people's problem with trying to boot. > > Of course, this was main, not stable or releng/13.* or the > like. There is more control over the staging of updates > for them. Unfortunately, sometimes adding X-MFC-WITH is forgotton on follow-up commits, making the commit NOT MFC'ed to stable/* and fire there again. And unfortunately, even though X-MFC-WITH is added, sometimes MFC is missed. > It would be nice if UPDATING reported when a openzfs update > was adding new zpool feature(s) to main and if the loader > was ready for them yet. If not: Later adding an entry for > the loader being ready for the feature(s). +1. > > It's when you enable something on the zpool that you can run into trouble, > > but that's true independent of upgrade :) > > > > Warner > > Modulo bugs, try test systems first, etc. Of course. > > > > === > Mark Millard > marklmi at yahoo.com > > > -- Tomoaki AOKI
Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main - rc(8): Add a zpoolupgrade rc.d script)
On Wed, 9 Nov 2022 23:04:17 +0100 "Patrick M. Hausen" wrote: > Hi, > > > Am 09.11.2022 um 22:59 schrieb Alexander Leidinger > > : > > Quoting "Patrick M. Hausen" (from Wed, 9 Nov 2022 > > 22:47:28 +0100): > >> > >> I apologize, should have included that in the last mail. > >> This is a current FreeBSD 13.1-p2 hosting system we run. > >> [ List of features from an active root pool ] > >> Boots quite fine ;-) > > > > There are several in the list which are not in the list in zfsipl.c. So > > that list is not the full truth... > > Or whatever is missing is not critical to booting. The boot loader does not > need > read/write access to the zpool. It only needs to be able to locate and read > the kernel. > > Kind regards, > Patrick loader needs to read /boot/loader.conf, related scripts and kmods under /boot/ from boot pool, too. Not just kernel. Maybe, `zpool upgrade` would need some overhaul, with small change to stand/libsa/zfs/zfsimpl.c. *Move features_for_read[] alone to new, dedicated header that can be included from both stand/libsa/zfs/zfsimpl.c and any others (including zpool). *Let zpool to check whether the pool is bootable or not, and if bootable, only enable features included in the matrix, otherwise, enable all supported features on FreeBSD. I don't think ALL OS'es that have OpenZFS inported can always boot with all features enabled. So changes to zpool would be able to OS independent except the header defining features supported by its loader. There can be other matrixes for implemented (after boot) and default-to-be-enabled features. The OS-dependent matrixes would ease ZFS developers to determine which features are implemented / defaulted / bootable on specific OS. (Already there?) -- Tomoaki AOKI
Re: linsysfs on /usr/src/sys (linsysfs, local)
On Mon, 7 Nov 2022 03:03:25 + Graham Perrin wrote: > On 29/10/2022 21:30, Graham Perrin wrote: > > > Subject: poudriere jail update from source: syscall.mk does not exist > > > After updating to yesterday's > > aba921bd9e1869dae9ae4cc6e0c048f997401034, I aimed for a routine update > > of the jail that I used for poudriere. > > > > > > poudriere jail -u -J 1 -j main > > … > > ===> lib/libc (install) > > make[5]: "/usr/src/lib/libc/sys/Makefile.inc" line 9: Cannot open > > /usr/src/sys/sys/syscall.mk > > make[5]: Fatal errors encountered -- cannot continue > > make[5]: stopped in /usr/src/lib/libc > > *** Error code 1 > > … > > > bdrewery and others in IRC helped me to realise an offending mount. > > > With linux_enable: YES, > > root@mowa219-gjp4-8570p-freebsd:~ # mount | grep sys > linsysfs on /usr/src/sys (linsysfs, local) > root@mowa219-gjp4-8570p-freebsd:~ # exit > logout > % grep linsysfs /etc/fstab > # linsysfs /compat/linux/sys linsysfs > rw 0 0 > # linsysfs /compat/ubuntu/sys linsysfs > rw,late 0 0 > % > > > After linux_enable: NO and a reboot, > > % sysrc -f /etc/rc.conf linux_enable > linux_enable: NO > % mount | grep sys > % date ; uname -aKU > Wed 2 Nov 2022 19:06:01 GMT > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #24 > main-n258900-aba921bd9e18: Sat Oct 29 14:39:59 BST 2022 > grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > > amd64 1400073 1400073 > % sudo service linux onestart > grahamperrin's password: > kldload: an error occurred while loading module linux. Please check > dmesg(8) for more details. > /etc/rc.d/linux: WARNING: Unable to load kernel module linux > kldload: an error occurred while loading module linux64. Please check > dmesg(8) for more details. > /etc/rc.d/linux: WARNING: Unable to load kernel module linux64 > % mount | grep sys > linsysfs on /compat/linux/sys (linsysfs, local) > % sudo sysrc linux_enable="YES" > linux_enable: NO -> YES > % > > > With linux_enable: YES (re-enabled) and a reboot, the clobber of > /usr/src/sys recurred. Possibly because there is a symlink /sys pointing to /usr/sys? The symlink is there historically, but already doesn't appear on `man hier` or /etc/mtree/. I finally found the revision 2878 at Mon Sep 19 01:40:40 1994 UTC [1] stopped creating the symlink automatically using /etc/mtree/. If the installation is old, kept-on-updating one, it would be time to delete the symlink. [1] https://cgit.freebsd.org/src/commit/etc/mtree/BSD.root.dist?id=c27b58e1b62e792e35a27bc5fd261e04293b076e > > > > Resolved through an OS update on 3rd November: > > % uname -aKU > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25 > main-n259004-2c10be9e06d4: Thu Nov 3 00:14:52 GMT 2022 > grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > > amd64 1400073 1400073 > -- Tomoaki AOKI
Re: Seeking an idiot's guide to etcupdate/mergemaster
On Sat, 5 Nov 2022 20:12:04 -0700 bob prohaska wrote: > On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote: > > > > Your /etc/rc.d/ldconfig script seems to have not been updated > > by use of etcupdate or mergemaster or other such. (How much > > else is also out of date? How much of what you have for /etc/ > > and the like goes back to 2022-Jan-07 or before?) > > > > Alas, that is too true. The system was set up on July 2, 2020 > and I've never managed to make sense of either mergemaster nor > etcupdate. Far as I could tell it didn't matter, the host ran > correctly, until now. > > It's been transplanted to a new hard drive, which allows the > installation of a ports tree. Ports don't install because of > the stale /etc/rc.d/ldconfig file. > > Since no changes have been made to /etc/ apart from /etc/rc.conf > is it possible to simply let mergemaster or etcupdate install > the latest defaults? I have looked at the manpage for etcupdate > and didn't recognize any straightforward way to simply accept > all updates. This particular system is expendable, so I'd be > glad to try things that might not work well, or at all. > > Apologies if I'm being dumb (probably guilty) or lazy (definitely > guilty). The barrage of questions generated by etcupdate and > mergemaster is simply overwhelming. And, I suspect, largely > unnecessary. > > Thanks for reading! > > bob prohaska For a relatively casual way. If I'm facing the same situation, I will... 1. `mergemaster -UFiP` for now, then... 2. `etcupdate extract -B` for next upgrade. And on next upgrade, `etcupdate -p` before installing upgrade, and then `etcupdate -B` after install. You can add -n for dry-run before actual etcupdate. For some notes: mergemaster, the old and less maintained tool, uses current installation and updated tree. Old dedault state is not at all considered. So it could be used for already-updated states. etcupdate, the currently maintained tool, uses previous and updated defaults, and current installation (working environment). It compares differences between old and new default, check if the differences can be sanely applicable to currently working environment or not, and if it's sane, apply the diff automatically. If any conflict happenes, ask the admin (this case, you) for actions. So it requires previous default state, thus cannot use for this case, except you are sure what the actual previous revision was and can prepare the source tree (possibly obj tree, too?) and somehow create "current" tree ATM (will be turned over to "previous" tree on etcupdate run). See manpages for detail. -- Tomoaki AOKI
Re: RES: TP-LINK USB no carrier after speed test
On Tue, 27 Sep 2022 20:17:54 +0200 Hans Petter Selasky wrote: > On 9/27/22 15:22, Hans Petter Selasky wrote: (snip) > FYI: There is some experimental thunderbolt support at: > > https://github.com/hselasky/usb4 > > But I'm not sure if it supports the hardware you've got. > > --HPS Thanks for the hard work and info. As I stated on Bug 237666 [1], I have Titan Ridge TB3 bridge on my ThinkPad P52. The relevant part of HW probe is at comment 206 [2]. Are there any other info I can provide for Titan Ridge support? (Not yet tried the codes.) [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666#c206 -- Tomoaki AOKI
Re: security/clamav: /var/run on TMPFS renders the port broken by design
On Mon, 29 Aug 2022 10:31:28 +0200
Franco Fichtner wrote:
> Hi,
>
> > On 29. Aug 2022, at 8:24 AM, FreeBSD User wrote:
> >
> > Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var
> > reside on a memory
> > disk and the way NanoBSD handles /var, contradicts some claims that is is
> > 'unsupported' to put
> > /var on a volatile memory infrastructure.
>
> I fully agree with the situation that at least NanoBSD has always been a valid
> use case for this and don't see the need to "recycle" contents in /var/run and
> let alone assume software that state inside /var/run is not volatile.
>
> Milage varies for other /var related subdirectories of course, but people
> using
> a /var MFS type setup have managed the situation for many years anyway with
> all
> of its ups and downs.
>
> The situation is a bit sloppy on the ClamAV end and has been for a couple of
> releases assuming this and that and failing on tmpfs nodes, not bootstrapping
> required things in the first place, but let's just assume that is the case for
> other software as well now or in the future.
Uncertain about current default, but at least, at some point,
varmfs="AUTO" on /etc/defaults/rc.conf forcibly create and mount
mfs on /var, overriding existing contents, unless varmfs="NO"
exists on /etc/rc.conf[.local].
If the behaviour is unchanged until now, no port SHALL assume
non-volatile /var, and use usually-non-volatile {LOCALBASE}/var instead.
At least, security/rkhunter uses there.
For use-case writes to non-volatile fs is prohibited and volatile
fs'es are mandated to be cleared daily, the admin should create
script(s) to
1. stop all jobs writing to (allowed) volatile fs,
2. clear volatile fs'es,
3. then restart stopped jobs
on {LOCALBASE}/etc/periodic/daily.
> > what (fatal?) implications does it have to create some folders by port's
> > rc-script in /var/run
> > or whatever folder is needed to be on a volatile memory device for FreeBSD
> > base system's mtree
> > infrastructure?
>
> So the obvious "separation of concerns" solution isn't something that was
> being
> discussed here seeing that this is a ports/packages related issue:
>
> The fix in all cases is to upgrade/reinstall the package in question, so
> the knowledge of these required directories is buried inside the +POST_INSTALL
> script but you cannot easily re-run these scripts since there is no command
> option for it. Obviously this beats having a copy of the package lying around
> just to reinstall it on a reboot...
>
> In the past you were able to extract them from "pkg info --raw $packagename",
> and run them in the shell but that workaround is no longer feasible for LUA
> scripting was added since pkg uses internal definitions in the ports tree
> provided scripts.
>
> Whether or not someone will have to script something to rerun the
> +POST_INSTALL
> on reboot shouldn't stop from adding a pkg script run option to enable the
> former.
>
> Solutions not involving the actual ports scripts seem to be over-engineering
> when trying to record "unknown state" for a "reproducible outcome". ;)
>
>
> Cheers,
> Franco
>
--
Tomoaki AOKI
Re: Updating EFI boot loader results in boot hangup
On Wed, 17 Aug 2022 07:55:32 +0900 Tomoaki AOKI wrote: > On Mon, 15 Aug 2022 21:35:52 -0600 > Warner Losh wrote: > > > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura wrote: > > > > > From: Yasuhiro Kimura > > > Subject: Re: Updating EFI boot loader results in boot hangup > > > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST) > > > > > > > From: Yasuhiro Kimura > > > > Subject: Updating EFI boot loader results in boot hangup > > > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST) > > > > > > > >> I made regular update of my 14-CURRENT amd64 system from > > > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated > > > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in > > > >> boot hangup as following. > > > >> > > > >> > > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png > > > >> > > > >> If I restore previous loader file (that is, loader.efi of > > > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then > > > >> system boots successfully. > > > > > > > > I submitted the problem to FreeBSD Bugzilla. > > > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825 > > > > > > > > Best Regards. > > > > > > d98de744050 is committed. So I tested it with following steps. > > > > > > 1. Check out the commit. > > > 2. cd /usr/src/stand > > > 3. make > > > 4. make install > > > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd > > > 6. shutdown -r now > > > > > > And system boots successfully. But while efi loader is workding a lot > > > of messages are displayed as following. > > > > > > > > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png > > > > > > Would you be able to share camcontrol devlist output? Privately if need be. > > And have any of these disks ever held ufs filesystems?? > > > > Warner > > > > > > > --- > > > Yasuhiro Kimura > > Just a "me too" info. I have (usually not mounted for test) UFS on ada0. > (Now the UFS contains outdated [SVN era] root partition of main.) > > % camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ada0) >at scbus1 target 0 lun 0 (ses0,pass1) > at scbus2 target 0 lun 1 > (pass2,nda0) > > % gpart show nda0 > =>40 3907029088 nda0 GPT (1.8T) > 402008- free - (1.0M) > 2048 1126400 1 efi (550M) > 11284482048 2 freebsd-boot (1.0M) > 1130496 3770679296 3 freebsd-zfs (1.8T) > 3771809792 135219200 4 freebsd-swap (64G) > 3907028992 136- free - (68K) > > > % gpart show ada0 > =>40 3907029088 ada0 GPT (1.8T) > 402008- free - (1.0M) > 2048 1126400 1 efi (550M) > 11284482048 2 freebsd-boot (1.0M) > 1130496 3749707776 3 freebsd-zfs (1.7T) > 375083827220971520 4 freebsd-ufs (10G) > 3771809792 135219200 5 freebsd-swap (64G) > 3907028992 136- free - (68K) > > > -- > Tomoaki AOKI > Confirmed fixed at commit 6d645da0d49decc0352f27b8b5ff1983c611659d. Thanks! Sorry for the late report. I had been facing another, unrelated problem, fixed at commit 545db925c3d5408e71e21432895770cd49fd2cf3. -- Tomoaki AOKI
Re: Lots of port failures today?
On Fri, 19 Aug 2022 09:06:11 -0400 Charlie Li wrote: > Mateusz Guzik wrote: > > On 8/18/22, Mateusz Guzik wrote: > >> On 8/18/22, Larry Rosenman wrote: > >>> https://home.lerctr.org:/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s > >>> > >>> circa 97ecdc00ac5 on main > >>> Ideas? > >>> > >> > >> try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted > >> > > > > I'm pretty sure it will be fixed with URL: > > https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3 > > > Seems to be fixed with this commit, at least for graphics/jpeg-turbo, > whose configure failed with something about platform not supporting SIMD. > > -- > Charlie Li > …nope, still don't have an exit line. And so as base /usr/bin/xz (through pipe) and ports lang/ruby30. The former caused x11/linux-nvidia-libs to fail on extract, and the latter caused ports-mgmt/portupgrade (including portsclean) to fail on start. Both are fixed at the commit. Thanks! -- Tomoaki AOKI
Re: Updating EFI boot loader results in boot hangup
On Mon, 15 Aug 2022 21:35:52 -0600 Warner Losh wrote: > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura wrote: > > > From: Yasuhiro Kimura > > Subject: Re: Updating EFI boot loader results in boot hangup > > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST) > > > > > From: Yasuhiro Kimura > > > Subject: Updating EFI boot loader results in boot hangup > > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST) > > > > > >> I made regular update of my 14-CURRENT amd64 system from > > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated > > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in > > >> boot hangup as following. > > >> > > >> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png > > >> > > >> If I restore previous loader file (that is, loader.efi of > > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then > > >> system boots successfully. > > > > > > I submitted the problem to FreeBSD Bugzilla. > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825 > > > > > > Best Regards. > > > > d98de744050 is committed. So I tested it with following steps. > > > > 1. Check out the commit. > > 2. cd /usr/src/stand > > 3. make > > 4. make install > > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd > > 6. shutdown -r now > > > > And system boots successfully. But while efi loader is workding a lot > > of messages are displayed as following. > > > > > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png > > > Would you be able to share camcontrol devlist output? Privately if need be. > And have any of these disks ever held ufs filesystems?? > > Warner > > > > --- > > Yasuhiro Kimura Just a "me too" info. I have (usually not mounted for test) UFS on ada0. (Now the UFS contains outdated [SVN era] root partition of main.) % camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (ses0,pass1) at scbus2 target 0 lun 1 (pass2,nda0) % gpart show nda0 =>40 3907029088 nda0 GPT (1.8T) 402008- free - (1.0M) 2048 1126400 1 efi (550M) 11284482048 2 freebsd-boot (1.0M) 1130496 3770679296 3 freebsd-zfs (1.8T) 3771809792 135219200 4 freebsd-swap (64G) 3907028992 136- free - (68K) % gpart show ada0 =>40 3907029088 ada0 GPT (1.8T) 402008- free - (1.0M) 2048 1126400 1 efi (550M) 11284482048 2 freebsd-boot (1.0M) 1130496 3749707776 3 freebsd-zfs (1.7T) 375083827220971520 4 freebsd-ufs (10G) 3771809792 135219200 5 freebsd-swap (64G) 3907028992 136- free - (68K) -- Tomoaki AOKI
Re: Updating EFI boot loader results in boot hangup
Or multiple installation in the same computer. For me, main and stable/13 are installed in different drive. So I can boot into healthy installation, mount problematic ESP, and alter broken bootx64.efi with known-to-work one. Usually, to boot into healthy installation, choose boot drive on UEFI menu. On Fri, 12 Aug 2022 15:26:08 -0500 Larry Rosenman wrote: > > > boot off a memstick? > > On 08/12/2022 3:25 pm, Nuno Teixeira wrote: > > > The problem is if boot is failing, how to mount and rename it? > > > > I'm looking for a way, if possible, to boot directly bkp boot64x in > > case of failure. > > I was hoping to find it in loader(8) or uefi(8)... > > > > Larry Rosenman escreveu no dia sexta, 12/08/2022 à(s) > > 21:09: > > > > I would assume just rename the bootx64.old to bootx64.efi > > > > and/or put it in a different directory that EFI can see > > > > On 08/12/2022 3:03 pm, Nuno Teixeira wrote: > > > > I'm searching without success to load a bkp loader in case of boot > > failure. > > > > Upgrade process willl be like: > > --- > > mount -t msdosfs /dev/nvd0p1 /mnt > > cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old > > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi > > --- > > > > I can't find the right docs to load bootx64.old. > > Could you tell me what you did to solve your boot? > > > > Thanks > > > > Yasuhiro Kimura escreveu no dia sexta, 12/08/2022 > > à(s) 18:45: From: Nuno Teixeira > > Subject: Re: Updating EFI boot loader results in boot hangup > > Date: Fri, 12 Aug 2022 18:26:11 +0100 > > > >> Hello Yasu, > >> > >> Does it needes to update boot loader everytime that we upgrade > >> current? > > > > No, you need not. > > > >> The only time that I updated was a month ago because of zfs upgrade > >> and I need to practice how to boot > >> loader bkp file :) > > > > I update boot loader everytime because I'd like to do it :-). > > And sometimes problem hits upon me like this time and I contribute to > > debugging base system :-):-). > > > > --- > > Yasuhiro Kimura > > > > -- > > > > Nuno Teixeira > > FreeBSD Committer (ports) > > -- > 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 > > -- > > Nuno Teixeira > FreeBSD Committer (ports) > > -- > 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 -- Tomoaki AOKI
Re: from X to terminal needs an fflush
On Tue, 26 Jul 2022 10:30:25 -0700 Chris wrote: > On 2022-07-26 10:29, Chris wrote: > > On 2022-07-22 08:27, Ivan Quitschal wrote: > >> hi all > >> > >> Ive been trying to solve a problem which is happening to me but so far no > >> success. > >> problem is this: > >> > >> sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" > >> whatever > >> in order to get back to terminal, it *does* get back to terminal but the > >> screen > >> still shows like i was on X, therefore i have to do a F* twice in order to > >> see the > >> console , like an fflush was missing somewhere. > > If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8> > > to > TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8> ...and Alt+F<1-8> to switch vtys afterwards. To get back to X, Alt+F9. You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>. > > Sorry. > > accomplish your goal. Does doing it that way fix it for you? > > > > HTH > > > > --Chris > >> > >> im using the drm-devel-kmod git for i915kms.ko btw > >> > >> any ideas what could it be? > >> > >> thank you guys > >> > >> --tzk -- Tomoaki AOKI
Re: FreeBSD is a great operating system!
On Fri, 8 Jul 2022 12:56:59 +0200 Hans Petter Selasky wrote: > On 7/8/22 05:40, Turritopsis Dohrnii Teo En Ming wrote: > > Dear Hans Petter Selasky, > > > > Why do you say FreeBSD license is a killer? > > Because you can do anything you want with the operating system :-) > > --HPS Plus, unlike GPL, you don't need to make open-source what you modified. This should be a killer who uses NDA'ed codes in conjunction with BSD-licensed codes. In these cases, you SHALL make open-source under GPL whole NDA'ed code if you use GPL'ed codes. BSD-licensed codes does nothing harmful. -- Tomoaki AOKI
Re: vt newcons mouse paste issue FIXED
On Sat, 25 Jun 2022 11:29:43 +0200 Hans Petter Selasky wrote: > On 6/24/22 18:51, Tomoaki AOKI wrote: > > On Fri, 24 Jun 2022 17:29:26 +0200 > > Hans Petter Selasky wrote: > > > > Hi Tomoaki, > > Please retest: > https://reviews.freebsd.org/D35552 > > Pushing this after some local tests. > > --HPS Thanks! As I already commented on Phabricator, worked just as intended. *Trailing spaces only listed in switch() of tchar_is_word_separator() are deleted on non-last lines. *Space (tried U+3000 only, though) before U+2007, which is not listed and untouched, on non-last line is sanely kept. *Spaces at the end of last line are sanely kept. Some additional info not wrote in Phablicator: I've entered test texts using editors/leafpad and entered various space characters with character_pallette of japanese/mozc-tools. Then, switch to console and view the text with misc/lv and copy from there, close, open /ust/bin/ee, paste the buffer and save it. After all, switch back to Mate desktop and open the saved text with editors/leafpad to see the result. *ee has some problem handling non-ascii chars. Maybe on character counting. So not fit to check the result. Some, usually old, Japanese uses U+0020 and u+3000 to make tables and want u+3000 as non-breakable. But the needs are basically only on "within a line". Almost all of us wouldn't care about u+3000 at the end of line. Moreover, we Japanese are educated to insert single u+3000 between u+3002 (IDEOGRAPHIC FULL STOP) and next character at the same line, when in elementary school. (Many people forgets this, though.) This rule should be enough to handle u+3000 as breakable for this particular case. Thanks again in advance! Now I should say "Go for it!". -- Tomoaki AOKI
Re: vt newcons mouse paste issue FIXED
On Fri, 24 Jun 2022 17:29:26 +0200 Hans Petter Selasky wrote: > Hi Tomoaki, > > On 6/24/22 16:48, Hans Petter Selasky wrote: > > IDEOGRAPHIC (Full-width) SPACE > > According to this page: > > https://jkorpela.fi/chars/spaces.html > > There are multiple uni-code characters which are spaces. Should we > support them all? > > --HPS Nice page! Maybe not all. My guess based on "Sample" and "Width of the character" fields are as below. At the first column, 'Y': Should be treated as space / word separator 'N': Should NOT be treated as space / word separator 'U': Unknown for me. Need native speaker to determine. Maybe someone have objections, but basically I've considered breakable spaces as space characters. See also URL [1] below. Special cases: *Looking sample, U+1680 is shown as dash so considered 'N'. *Treated "QUAD" as just a graphical (non-semantic) use so considered as 'N'. *Considered U+205F as 'N', as I thought, for mathematical usage, unintended line break could cause fatal confusion. Code Name of the character Y U+0020 SPACE N U+00A0 NO-BREAK SPACE N U+1680 OGHAM SPACE MARK Y U+180E MONGOLIAN VOWEL SEPARATOR N U+2000 EN QUAD N U+2001 EM QUAD Y U+2002 EN SPACE (nut) Y U+2003 EM SPACE (mutton) Y U+2004 THREE-PER-EM SPACE (thick space) Y U+2005 FOUR-PER-EM SPACE (mid space) Y U+2006 SIX-PER-EM SPACE N U+2007 FIGURE SPACE Y U+2008 PUNCTUATION SPACE Y U+2009 THIN SPACE Y U+200A HAIR SPACE Y U+200B ZERO WIDTH SPACE N U+202F NARROW NO-BREAK SPACE N U+205F MEDIUM MATHEMATICAL SPACE Y U+3000 IDEOGRAPHIC SPACE N U+FEFF ZERO WIDTH NO-BREAK SPACE Maybe, the best would be looking into how unicode normalization treat them. But we Japanese would want U+3000 treated as space. [1] https://en.wikipedia.org/wiki/Non-breaking_space -- Tomoaki AOKI
