# FreeBSD 13 annoyances?



## decuser (Apr 13, 2021)

Anybody got any Freebsd 13 annoyances, yet? 

BTW, so far, I'm loving 13, so this isn't a knock on the release - it's beautiful. However, things are different and different is... well, different... and often annoying, so I have an example:

One of the first things I noticed with my shiny new system is that after I installed bash, *bracketed-paste is now on by default*. Oh, fine, it's a bash annoyance, not really a FreeBSD 13 annoyance, still, it didn't happen until I upgraded to FreeBSD 13, so I'm lumping the baby in with the bath water. What this means is that when you paste in bash (over ssh, or otherwise) your paste is highlighted. It's confusing, ugly, and, well downright annoying.

To get rid of it, `bind 'set enable-bracketed-paste off'`. Maybe you have a better fix, do tell.

What else has changed... for good or bad, that's surprising - please keep it light .


----------



## tingo (Apr 13, 2021)

Better fix - don't use bash.


----------



## _martin (Apr 13, 2021)

This was bothering me so much in gdb, for few weeks now actually. My google-fu was not good enough, I gave up for a while. Thank you for mentioning the _bracketed-paste _ terminus technicus. 
With that I was able to get rid of it in gdb. It seems this behavior is coming from a readline as a default "feature".
I first thought it was due to the iTerm2 update but later I experienced the same issue in PuTTY sessions. It is freakishly annoying and distacting. So the next is on me now.

I created ~/.inputrc and put this:

```
set enable-bracketed-paste off
```
This disables it by default for all programs using readline.


----------



## decuser (Apr 14, 2021)

How about this... the default KDE install on FreeBSD 13 tries to login to a Wayland session, but fails with a black screen. After choosing Plasma instead of Plasma (Wayland), everything "just works". I think it was this way with 12.2, but it's been a while since I did that install. Either way, it's annoying and it's FreeBSD 13


----------



## obsigna (Apr 14, 2021)

After updating to FreeBSD 13.0-RELEASE, I had an issue with clear_tmp_enable="YES" and Postgresql startup. It seems that with 13 the /tmp driectory becomes cleared after Postgresql has been started, and its freshly created unix domain sockets (by default in /tmp) are just cleared away as well. For now I leave clear_tmp_enable="NO".

`rm -rf /tmp; mkdir -pm 1777 /tmp` in /etc/rc.shutdown.local seems to do what I want.


----------



## a6h (Apr 14, 2021)

I haven't installed it yet, but I'm more interested in: Thread lldb-is-the-trouble.79755


----------



## zirias@ (Apr 14, 2021)

decuser said:


> Oh, fine, it's a bash annoyance, not really a FreeBSD 13 annoyance


And as ports are a completely independent tree from base/src, you'd have this on _any_ FreeBSD version.

Some real annoyances I have: PR 254282, PR 254343.
Actually, bugs. But as I have workarounds for both, "annoyance" fits as well


----------



## sidetone (Apr 14, 2021)

I haven't installed FreeBSD 13.0 yet, but according to the release notes,


> A new  usbhid(4) driver uses drivers from the  hid(4) framework for USB HID devices instead of  ukbd(4),  ums(4), and  uhid(4).  usbhid(4) is enabled by adding hw.usb.usbhid.enable=1 to /boot/loader.conf and adding usbhid to kld_list="" in /etc/rc.conf. b62f6dfaed3d


-->


> *hid: Replace USBHID_ENABLED kernel config option with loader tunable*
> usbhid(4) is disabled by default to avoid conflicts with existing USB HID
> drivers. To enable it place following lines to /boot/loader.conf:
> 
> ...


usbhid(4) is in FreeBSD 12.2 and FreeBSD 13.0. The difference is that: in 13.0, usbhid doesn't use the uhid(4), ukbd(4) and ums(4) drivers. In 13.0, usbhid has to be enabled for it to be used, because the driver architecture it uses conflicts with uhid. At this moment, there's no manpage for the "hid" framework mentioned. The online man pages are still at 13.0-current.

It seemed that uhid had a lot of limitations for hardware use, but after reading this, it's possible that additional drivers were needed for additional hardware relating to keyboards, gamepads and other input devices, rather than a full replacement driver. Other hid related drivers in ports tried to cover separate drivers in base of uhid, ukbd and ums.


----------



## _martin (Apr 14, 2021)

Zirias said:


> And as ports are a completely independent tree from base/src, you'd have this on _any_ FreeBSD version.


True. Also it's not a bash problem, it's a readline problem. So anything linked against it will behave the same.


----------



## jbo (Apr 14, 2021)

I have upgraded four machines so far: A laptop, a playground server and two "real" servers.
I did not encounter any annoyances yet. Upgrades went smoothly on all machines too.

However, I am in the lucky position that most of my FreeBSD servers run fairly standard stuff, no weird hardware, no weird configurations - I like to keep things as simple as possible and that usually pays off during upgrades 
The desktops use mainly i3 (and some xfce) so the typical KDE beast-problems are also something I just completely bypass.


----------



## sidetone (Apr 14, 2021)

joel.bodenmann said:


> However, I am in the lucky position that most of my FreeBSD servers run fairly standard stuff, no weird hardware, no weird configurations - I like to keep things as simple as possible and that usually pays off during upgrades


This doesn't say much. It won't matter, unless you rebuild a custom base through src.conf or change file systems. Making a custom base easily causes problems whether upgrading or not. Ports usually get reinstalled anyway after a release upgrade or fresh install.


----------



## decuser (Apr 14, 2021)

_martin said:


> I created ~/.inputrc and put this:
> 
> ```
> set enable-bracketed-paste off
> ...


I wanted to hit thanks twice on this . This works for sudo -s sessions initiated from the user's bash shell and, and, and!


----------



## sidetone (Apr 14, 2021)

https://freebsdfoundation.org/blog/freebsd-release-13-0-highlights/ showed up in my phone feed.


----------



## mickey (Apr 14, 2021)

It appears that the kernel options _TERMINAL_NORM_ATTR_ and _TERMINAL_KERN_ATTR_ as documented in vt(4) are b0rken in FreeBSD 13. Now booting a custom kernel just feels sad.


----------



## jmos (Apr 15, 2021)

My update from 12.2 to 13.0 was unusually bumpy: My "/boot/loader.conf" tried to load the old NVIDIA module - I simply forgot that before rebooting… But: Recompiling didn't help (!) - it still didn't boot. Finally I had to delete my old entry 'nvidia_load="YES"' in "/boot/loader.conf", and for it a "nvidia-modeset" in the "kld_list" had to be added to "/etc/rc.conf".

Another change from "/boot/loader.conf" to "/etc/rc.conf" belonged to FUSE: The previous entry 'fuse_load="YES"' was now effectless, only a further addition of "fusefs" to the "kld_list" entry brought SSHFS back.

Edit: Notebook & VMs worked out of the box - just on my desktop computer I ran into trouble.


----------



## olav (Apr 15, 2021)

I think there is something wrong with NFS with FreeBSD 13.0, my Linux client seems do hang/freeze when there is some IO.


----------



## rm1984 (Apr 15, 2021)

PEFS works no more!


----------



## SirDice (Apr 15, 2021)

jmos said:


> The previous entry 'fuse_load="YES"' was now effectless, only a further addition of "fusefs" to the "kld_list" entry brought SSHFS back.


The original fuse module was renamed to fusefs(5). On 12.x both fuse and fusefs loaded the fusefs(5) module (it accepted both names). On 13.0 the old fuse name was removed.


----------



## mickey (Apr 15, 2021)

Building devel/doxygen and multimedia/gstreamer1 from ports failed on FreeBSD 13 for some obscure reason somehow related to the use of devel/bison. Building succeeds however when you redirect output to a file. Very strange.


----------



## hakova (Apr 17, 2021)

In my two-day experience with FreeBSD 13.0 some cron jobs stopped sending email. Please see this forum link for details.Yes, it is annoying. Otherwise, smooth upgrade without issues and I love the beautiful console font.


----------



## tux2bsd (Apr 17, 2021)

Want to edit /etc/motd , well... not without extra faffing around now.


----------



## tingo (Apr 18, 2021)

tux2bsd said:


> Want to edit /etc/motd , well... not without extra faffing around now.


Simply edit /etc/motd.template?


----------



## scottro (Apr 18, 2021)

Like jmos, my Nvidia module didn't load. That and/or my Linux module stopped it from booting after the first `freebsd-update install`. I booted into single user mode, disabled both of them, and from there it was fairly smooth. Upgraded all packages, as freebsd-update instructed me, and then it would boot with modules enabled. I don't remember that happening when I updated from 11.x to 12.x but I could be wrong. 
Quite awhile ago, I reinstalled using ZFS (I'd been using UFS), not for redundancy but only to take advantage of its boot environment feature for situations like this.  When I first had the problem,I was in a bit of hurry, so I just reverted to the preupgrade boot environment. Afterwards, once I fixed it, the next worry was upgrading ZFS. As it's not a mirror or ZRAID, and is on legacy BIOS, I didn't have to worry about changes in installing boot  code or the warnings about EFI changes. I just ran `zpool update -a` and all was fine. 

On my laptop, which is more for testing, I had installed 13 back when it was CURRENT---If I remember correctly, 12.x wouldn't run X properly, (a T495 that uses drm-kmod's amdgpu). 
So, aside from  the module hiccup, which was quite an annoyance because I had been in a hurry and was expecting a smooth upgrade, it was pretty easy.  At work, our various servers will be staying on 12.x for awhile, though as they aren't using Nvidia or Linux modules, there shouldn't be problems there.


----------



## Veno (Apr 20, 2021)

I am planning to upgrade server with zfs root running 12.2 to 13.0 
Any precautions I should take care of? Or should I follow the standard route upgrading with freebsd-update?


----------



## SirDice (Apr 20, 2021)

Go through /boot/loader.conf and disable everything you don't really need to boot the system. Especially kernel modules installed from ports/packages could interfere during the upgrade process. Do the same with /etc/rc.conf, disable everything you don't strictly need. Again, this will prevent any issues during the upgrade process. Make sure you have console access if you're doing this remotely (IPMI, KVM, whatever), there's always a chance something goes wrong and you'll need to have access to the console. 

I know the "official" documentation says to reboot after the first `freebsd-upgrade install`, you can skip that step. Go right ahead with the second `freebsd-update install`. Once that's finished run `pkg upgrade` to reinstall everything. Make sure to update your boot partition and/or efi loaders. Now is a good time to reboot for the first time. If everything went well it should come up nicely. Run the third and final `freebsd-update install`. Enable the things you disabled before again and reboot a final time to see if everything comes up as it should.

If you're running ZFS let everything run for a couple of days until you're satisfied everything is in order. Then upgrade your pools. Double check those boot partitions and/or efi loaders.


----------



## Veno (Apr 20, 2021)

This is what I have in /boot/loader.conf:

```
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
opensolaris_load="YES"
zfs_load="YES"
```

Since my root partition is on zfs pool if I disable everything will the system boot ?


----------



## SirDice (Apr 20, 2021)

Veno said:


> Since my root partition is on zfs pool if I disable everything will the system boot ?


Probably not. Like I said, only disable non-essential things. This is all essential, so don't disable those. You can remove the `opensolaris_load="YES"` though, it was never required (if a module depends on a another module it will get loaded automatically).

With non-essential I mean things like graphics drivers, virtualbox, etc. You don't _need_ those to boot the system.


----------



## Argentum (Apr 20, 2021)

Veno said:


> I am planning to upgrade server with zfs root running 12.2 to 13.0
> Any precautions I should take care of? Or should I follow the standard route upgrading with freebsd-update?


Just did it yesterday - *the last one *of my 3 desktop machines. ZFS had no problems. Today I have also *upgraded the pool *and everything is working. Built *world*, *kernel*, removed graphics/drm-fbsd12.0-kmod, *installed graphics/drm-fbsd13-kmod* after that and *replaced all EFI bootloaders*.

Everything is working. Did not even rebuild all the ports yet. Just the first one *ports-mgmt/pkg*. After that I am able to use ports-mgmt/portupgrade. My desktop with all the applications is working. 

Do not perform `zpool upgrade -a` before you have at least one new bootloader present.


----------



## SirDice (Apr 20, 2021)

Argentum said:


> removed graphics/drm-fbsd12.0-kmod, installed graphics/drm-fbsd13-kmod


If you previously had graphics/drm-kmod installed this will automatically be done with a `pkg upgrade`.


----------



## Argentum (Apr 20, 2021)

SirDice said:


> If you previously had graphics/drm-kmod installed this will automatically be done with a `pkg upgrade`.


I know. I am just such an old school guy...


----------



## T-Daemon (Apr 20, 2021)

Veno said:


> I am planning to upgrade server



Besides what SirDice in post # 25 suggested check also /etc/fstab. Are there base system or third-party application filesystem mounts (i.e. network , clustered, fuse file systems). Those can interrupt the boot process if the necessary kernel module is missing (disabled in /boot/loader.conf or /etc/rc.conf), or the network connection gets lost. 

Those mounts should made sure in case they can't be mounted the system ignores them and continue to boot (`failok` - fstab(5)).


----------



## scottro (Apr 20, 2021)

If I'd read SirDice's advice before upgrading, I could have saved myself some trouble, especially the part about disabling modules.  Plus upgrading packages before the first reboot, which would have also solved the problem.  You ought to put something like this in the faqs and howtos, if you have the time and inclination.


----------



## Argentum (Apr 20, 2021)

Veno said:


> I am planning to upgrade server with zfs root running 12.2 to 13.0


Servers are usually easier to maintain than desktops. If you have kernel bound loadable modules, you should rebuild/install them after upgrade. Upgrade the UEFI loader in boot partitions before you commit `zpool upgrade -a`. Wait with pool upgrade until everything is working and you can be sure that you are not going to move back to 12.2.


----------



## SirDice (Apr 20, 2021)

scottro said:


> I could have saved myself some trouble, especially the part about disabling modules. Plus upgrading packages before the first reboot, which would have also solved the problem. You ought to put something like this in the faqs and howtos, if you have the time and inclination.


I've upgraded so many systems over the years it more or less became standard practice for me. If I have some time I'll try and whip up something, with some additional notes. I see quite a few people getting caught with the renaming of fusefs(5) for example too.


----------



## SirDice (Apr 20, 2021)

grahamperrin said:


> Nit: `freebsd-update` (not `freebsd-upgrade` …)


Muscle memory. Fingers type faster than my brain can keep up.


----------



## Peacekeeper2000 (Apr 20, 2021)

Hmm, I remember that I read something about "delete opensolaris_load="YES" " when you use zfs - it anyhow works on my box without removing. But how about "zfs_load="YES" " - is that still needed ?


----------



## Argentum (Apr 20, 2021)

Peacekeeper2000 said:


> Hmm, I remember that I read something about "delete opensolaris_load="YES" " when you use zfs - it anyhow works on my box without removing. But how about "zfs_load="YES" " - is that still needed ?


I can see from /usr/src/sys/amd64/conf/NOTES that there is a section


```
#####################################################################
# ZFS support

# NB: This depends on crypto, cryptodev and ZSTDIO
options         ZFS

#####################################################################
```

Assume that ZFS can be compiled into kernel, but this is not included in GENERIC. Have no idea if or how this option works.


----------



## grahamperrin@ (Apr 20, 2021)

Peacekeeper2000 said:


> … something about "delete opensolaris_load="YES" "



See for example <https://old.reddit.com/r/freebsd/comments/mrvv77/-/gutb8rn/>



Peacekeeper2000 said:


> … "zfs_load="YES" " - is that still needed ?



Yes and no; see my comment in Reddit.


----------



## SirDice (Apr 20, 2021)

Peacekeeper2000 said:


> it anyhow works on my box without removing.


Before 13.0 (9.x, 10.x, 11.x, 12.x) it was a dependency of zfs.ko. So it's normally automatically loaded when you load zfs.ko. That's why it doesn't matter if you add it or not, it's going to get pulled in anyway. On 13.0 zfs.ko doesn't depend on opensolaris.ko anymore at all, so it's useless to load it (for ZFS at least, it has some other uses too).


----------



## Argentum (Apr 20, 2021)

SirDice said:


> 13.0 zfs.ko doesn't depend on opensolaris.ko anymore at all, so it's useless to load it (for ZFS at least, it has some other uses too).


Just asking out of my curiosity - what are the other use cases of _*opensolaris*_? Did not find much documentation about that.


----------



## SirDice (Apr 20, 2021)

Argentum said:


> what are the other use cases of _*opensolaris*_?


It used to be an ABI layer just like linux(4) but for Solaris executables. There was a time we had a System V R4 and iBCS2 ABI compatibility. That SRV4 layer kind of morphed into opensolaris.ko and it's primary use was for ZFS. To be honest I'm not sure if it supports much else nowadays.


----------



## grahamperrin@ (Apr 20, 2021)

SirDice said:


> … an ABI layer …



Was that the SPL? 

(<https://openzfs.org/wiki/Reduce_code_differences> is outdated but I recall it from my Mac OS X days.)


----------



## bookwormep (Apr 21, 2021)

There was more of a surprise, than annoyance; when blacklisted certificates were listed during the upgrade to 13.0-RELEASE. I went back to the man pages and found a command recently added called 
`certctl(8)`. This is really a welcome surprise, since management of certificates seems pretty basic for system security. Also briefly read blacklistd man page to enhance understanding of functionality.


----------



## grahamperrin@ (Apr 21, 2021)

Did you upgrade from 12.1? certctl(8) _first appeared in FreeBSD 12.2_.

blacklistd(8)


----------



## SirDice (Apr 21, 2021)

grahamperrin said:


> Was that the SPL?


FreeBSD initially took it directly from OpenSolaris:




__





						src - FreeBSD source tree
					






					cgit.freebsd.org
				




This happened 6 years before OpenZFS even existed.


----------



## sidetone (Apr 24, 2021)

I like that when the kernel build is complete, it tells you how many seconds it took, the number of CPU's it used, and the time/date.


----------



## striker2150 (Apr 28, 2021)

Veno Wait some time with upgrading to a newer zpool version. FreeBSD 12.2 cannot read FreeBSD 13.0 zpools if there sould be a need for downgrading.


----------



## Mayhem30 (Apr 29, 2021)

SirDice said:


> Make sure to update your boot partition and/or efi loaders.



I don't use UFS, so does this even apply to me?

If so, are there any instructions on how to do this?


----------



## Emrion (Apr 29, 2021)

Mayhem30 said:


> I don't use UFS, so does this even apply to me?
> 
> If so, are there any instructions on how to do this?


Whatever you use, you should do that. 
You have here for efi booting.
And concerning legacy BIOS booting, you can look in gpart(8), command bootcode.

But, it's tricky for a beginner. Someone should write a howto...
If you want suited instructions for you, post the output of `gpart show`.


----------



## Mayhem30 (Apr 29, 2021)

I meant to say that I do use UFS.

I don't think I have EFI .. it's been so long so I created the partitions. Anyway to check?

Home backup server :


```
$ gpart show
=>       34  976773101  ada0  GPT  (466G)
         34       1024     1  freebsd-boot  (512K)
       1058  968883200     2  freebsd-ufs  (462G)
  968884258    7888876     3  freebsd-swap  (3.8G)
  976773134          1        - free -  (512B)
```


Live server :

```
$ gpart show
=>       63  500118128  mirror/gm0  MBR  (238G)
         63          1              - free -  (512B)
         64  500118120           1  freebsd  [active]  (238G)
  500118184          7              - free -  (3.5K)

=>        0  500118120  mirror/gm0s1  BSD  (238G)
          0  490733568             1  freebsd-ufs  (234G)
  490733568    8388608             2  freebsd-swap  (4.0G)
  499122176     995944                - free -  (486M)


$ gmirror list
Geom name: gm0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 2
ID: 2236105550
Type: AUTOMATIC
Providers:
1. Name: mirror/gm0
   Mediasize: 256060513792 (238G)
   Sectorsize: 512
   Mode: r2w2e5
Consumers:
1. Name: ada0
   Mediasize: 256060514304 (238G)
   Sectorsize: 512
   Mode: r1w1e1
   State: ACTIVE
   Priority: 0
   Flags: DIRTY
   GenID: 0
   SyncID: 2
   ID: 4267686746
2. Name: ada1
   Mediasize: 256060514304 (238G)
   Sectorsize: 512
   Mode: r1w1e1
   State: ACTIVE
   Priority: 1
   Flags: DIRTY
   GenID: 0
   SyncID: 2
   ID: 2938659242
```


----------



## Emrion (Apr 29, 2021)

Indeed, you don't have efi booting.

Concerning the home backup server, it's simple:
`# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0`

The said live server is based on a MBR scheme and I ain't accustomed with this scheme for FreeBSD (not to mention the UFS mirror). I can't answer for now.


----------



## Mayhem30 (Apr 29, 2021)

Thank you.

As for the live server, I found my notes on how I created the gmirror. Does this help?


```
gmirror label -v gm0 /dev/ada0 /dev/ada1
gpart create -s MBR mirror/gm0
gpart add -t freebsd -a 4k mirror/gm0

gpart create -s BSD mirror/gm0s1
gpart add -t freebsd-swap -a 4k -s 4g -i 2 mirror/gm0s1
gpart add -t freebsd-ufs -a 4k -i 1 mirror/gm0s1

gpart bootcode -b /boot/mbr mirror/gm0
gpart set -a active -i 1 mirror/gm0
gpart bootcode -b /boot/boot mirror/gm0s1

newfs -t -U /dev/mirror/gm0s1a
mount /dev/mirror/gm0s1a /mnt
```


----------



## Emrion (Apr 29, 2021)

Reading the man pages and the handbook, verifying that on a 13.0-RELEASE installed on a MBR scheme, I have just to point you there where you'll find what you need:

`# gpart bootcode -b /boot/mbr mirror/gm0
# gpart bootcode -b /boot/boot mirror/gm0s1`

I have to say that MBR is obsolete and advise you to make a new server with a GPT scheme. And, if you want a RAID1, you can do that with the guided installation if you choose zfs as root file system.


----------



## Mayhem30 (Apr 30, 2021)

Thank you. The reason I used MBR instead of GPT was because of this :



> gmirror(8) stores one block of metadata at the end of the disk. As GPT partition schemes also store metadata at the end of the disk, mirroring entire GPT disks with gmirror(8) is not recommended. MBR partitioning is used here because it only stores a partition table at the start of the disk and does not conflict with the mirror metadata.



I've seen lots of people have issues with zfs, so that's why I stayed away from it.


----------



## djmasa (Apr 30, 2021)

So I upgraded one of my systems from 12.2-RELEASE to 13.0-RELEASE doing the standard procedure like always. After doing the first 'freebsd-update install' command to install the kernel, and rebooting after that, the system comes up with the new kernel, 13.0-RELEASE. When running freebsd-update install again to upgrade the rest of the system I get:


```
root@server:~ # /usr/sbin/freebsd-update install
src component not installed, skipped
Cannot identify running kernel
root@server:~ #
```


So obviously, it's having a problem determining the current running kernel. doing a sysctl -n kern.bootfile returns /boot/kernel/kernel

all of that seems normal. I go look in the root file system and find.. no boot directory. what the heck?
the system was installed with 12.x via the auto-zfs system from the installer, so it created the zfs structure for the system. 
the system shows the usual bootfs as i've always seen it for zfs root systems as:

```
root@server:~ # zpool get bootfs zroot
NAME   PROPERTY  VALUE               SOURCE
zroot  bootfs    zroot/ROOT/default  local
root@server:~ #
```

It can't find the kernel, but yet it loaded it AND it loaded modules (including zfs.ko), but yet the system can't locate them anywhere. So now i'm stuck between a halfway upgraded system where the kernel is 13, the userland is 12.2, and I can't get freebsd-update to upgrade the userland to 13 because it won't see it. I tried running with the --currently-running 13.0-RELEASE option and it still won't run.

So far, for me, 13.0-RELEASE isn't starting off well. Does anyone have any ideas on how to fix this messed up scenario? I'm afraid of doing a rollback because I don't know what it will (or won't) do.


----------



## Samuel Venable (Apr 30, 2021)

There's the fact that now xorg gives me a black screen whenever I startx, and all I did was update to 13.0. Shouldn't have to find some fancy new config to keep X from breaking after a system update, but I do. Haven't found a solution yet.


----------



## vometia (Apr 30, 2021)

Mayhem30 said:


> I've seen lots of people have issues with zfs, so that's why I stayed away from it.


As much as I find "well it works for me!" type comments quite annoying... er, it works for me.   I've used it for years now with no incidents (other than the early days when the ARC(?) config could be a bit picky; and RAIDZ2 being really slow for general use: don't do that unless you have lots of annoying little HDDs and you're _really_ short of space) and it's come to my rescue on quite a few occasions.  tbf UFS could've also come to my rescue if it'd likewise been configured with snapshots etc so ymmv and one might argue it's personal preference.

The one thing I'm wary of is that it seems it's not well integrated with the paging system so putting swap volumes on ZFS seems to not be recommended; so I still have separate partitions for swapping (which are part of gmirror sets, which may or may not be sensible...)

Oh, and the other thing is that caution about upgrading pools.  I'm always a bit nervous about the risk of forgetting to also update the loader in my EFI partitions, something which would be quite bad; as such I've written a wrapper for zpool to remind me, though it's anyone's guess whether or not it can save me from my own randomness.  Yeah I know I could have a separate UFS /boot partition, which I used to do, but I found "but that's clumsy and ugly" took priority over pragmatism.


----------



## mark_j (Apr 30, 2021)

vometia said:


> The one thing I'm wary of is that it seems it's not well integrated with the paging system so putting swap volumes on ZFS seems to not be recommended; so I still have separate partitions for swapping (which are part of gmirror sets, which may or may not be sensible...)


This should be resolved sooner rather than later. See this bug.
In reality, swap on ZFS is no more problematic than mounting anything else. It's worked forever on Solaris. 

Let's not forget the system administrator's adage: Don't expand swap, just buy more RAM.


----------



## vometia (Apr 30, 2021)

mark_j said:


> Let's not forget the system administrator's adage: Don't expand swap, just buy more RAM.


Memories of trying to cram 30-50 users into 8-16MB.  It's hard to shake off that feeling of "I must have swap!" even if it does coexist with "argh, 4KB of my 64GB of swap is being used, what has gone so terribly wrong?!!  I am teh worst sysadmin evar!!1"


----------



## SirDice (Apr 30, 2021)

djmasa said:


> all of that seems normal. I go look in the root file system and find.. no boot directory. what the heck?
> the system was installed with 12.x via the auto-zfs system from the installer, so it created the zfs structure for the system.
> the system shows the usual bootfs as i've always seen it for zfs root systems as:


Did you do an encrypted install? In that case your /boot probably lives on a separate boot pool. Make sure that's mounted, there seems to have been a period where this didn't happen automatically.


----------



## Argentum (Apr 30, 2021)

Samuel Venable said:


> There's the fact that now xorg gives me a black screen whenever I startx, and all I did was update to 13.0. Shouldn't have to find some fancy new config to keep X from breaking after a system update, but I do. Haven't found a solution yet.


Looks very much like you did not update graphics/drm-kmod. Personally, I have 2 desktops and 1 laptop, all running 13.0 with Xorg and MATE. No problems, but after upgrade, the kernel bound modules should be rebuilt.


----------



## SirDice (Apr 30, 2021)

Argentum said:


> No problems, but after upgrade, the kernel bound modules should be rebuilt.


Just use the packages. There's no reason to build from ports for this. But you do need to check if it's been properly upgraded from graphics/drm-fbsd12.0-kmod to graphics/drm-fbsd13-kmod (which should automatically happen with a `pkg upgrade`). Especially if you perhaps used pkg-lock(8) to lock certain packages.


----------



## Argentum (Apr 30, 2021)

SirDice said:


> Just use the packages. There's no reason to build from ports for this. But you do need to check if it's been properly upgraded from graphics/drm-fbsd12.0-kmod to graphics/drm-fbsd13-kmod (which should automatically happen with a `pkg upgrade`). Especially if you perhaps used pkg-lock(8) to lock certain packages.


Yes, there seem to be two schools - one who build everything from source by themselves and another who use pre-built binary packages. But the essence here is the same - 12.0 kmod should be replaced by 13.0 kmod. One way or another.


----------



## astyle (Apr 30, 2021)

mickey said:


> Building devel/doxygen and multimedia/gstreamer1 from ports failed on FreeBSD 13 for some obscure reason somehow related to the use of devel/bison. Building succeeds however when you redirect output to a file. Very strange.


I'm building as much as I can from ports, compiling with as many options enabled as practical. I had trouble with building devel/doxygen, too. Turns out I ran into a weird circular dependency: graphics/graphviz->lang/ruby27->devel/doxygen->graphics/graphviz.
After an hour of googling, I found an obscure Nabble page that suggested the following:

Build lang/ruby27 (and all subsequent dependent ports) without the options that depend on devel/doxygen or graphics/graphviz.
Next, along the same lines, build devel/doxygen without the options that depend on graphics/graphviz. At this point, depending on lang/ruby27 is OK, because it was built.
And then finally, come back and build graphics/graphviz.
My annoyance is Wayland. I compiled all the necessary packages, it launches from Konsole (under Xorg) into its own window. That window runs KDE on Wayland just beautifully, with all settings just fine. But running the exact same command from SDDM - just crashes. I have to ssh in from another computer, and restart SDDM. I did see on Gentoo forums that it may be helpful to run Wayland on another TTY/PTY/VTY... Figuring out how to do that on FreeBSD took some time, but it looks like vidcontrol() is an option to play with.


----------



## tuxador (Apr 30, 2021)

astyle said:


> I'm building as much as I can from ports, compiling with as many options enabled as practical. I had trouble with building devel/doxygen, too. Turns out I ran into a weird circular dependency: graphics/graphviz->lang/ruby27->devel/doxygen->graphics/graphviz.
> After an hour of googling, I found an obscure Nabble page that suggested the following:
> 
> Build lang/ruby27 (and all subsequent dependent ports) without the options that depend on devel/doxygen or graphics/graphviz.
> ...


https://euroquis.nl//kde/2021/04/30/wayland.html soon plasma will be fully functional with Wayland.
Anyway sddm must be disabled.


----------



## vometia (May 1, 2021)

In spite of random comments earlier I've been happy with FBSD 13 so far.  The only "problem" was the old classic of a filesystem running out of space after I'd upgraded, which took me an indecently long time to realise (though I'm not sure why it didn't actually say so!) but overall it feels more solid and noticeably faster than FBSD 12.

Bit of a strange one last night though which is that it decided to reboot itself for no apparent reason.  Not a crash, it was a clean reboot as I can see from the state of my zpools (one lives on a manually activated geli partition so it would've been unhappy if it'd had the rug pulled from under it) and I can see just far enough back through the recovered dmesg buffer that it was a clean reboot.  I just have no idea why.  Nothing in the logs, no emails, nothing interesting in process accounting nor any other clues.

It's _possible_ it was something to do with that zpool.  I've just acquired a new backup drive, a weatherproof USB thing, and I've created two pools on it, a small recovery pool with root/boot filesystem and a big backup pool which as I mentioned lives on a manually-started geli partition.  I've been using the same scheme for years without any problem so I suspect it's unlikely and I'm only mentioning it in case any of it sounds at all familiar to anyone; I don't expect anyone to offer a thoughtful critique of my backup strategy, at least not here!  The only thing that seemed out of the ordinary is a (very) small number of "CCB request completed with error" messages regarding my new drive which at a glance don't seem congruent with what smartctl has to say.  I was in the process of doing a full refresh when the reboot occurred, i.e. four zpools active, two on the server itself (main pool, four-HDD RAID10 plus spare, online backup pool on a single drive), the other two on the removable USB drive as mentioned, geli, zfs send & recv active at the time.  Didn't seem to be doing anything especially interesting; it'd finished its daily periodic stuff 10 minutes before and had just started the weekly, apparently being in the middle of rebuilding the locate database.

I'm not even sure offhand what there is that can do a controlled reboot.  The UPS monitor can trigger a halt if it's almost out of power but it wasn't that (it wasn't a halt, there was no power cut and the UPS seems happy enough) so I'm a bit mystified.  I haven't enabled crash dumps but as it wasn't a crash that wouldn't help anyway.

Weird.


----------



## ralphbsz (May 1, 2021)

vometia said:


> Memories of trying to cram 30-50 users into 8-16MB.  It's hard to shake off that feeling of "I must have swap!" even if it does coexist with "argh, 4KB of my 64GB of swap is being used, what has gone so terribly wrong?!!  I am teh worst sysadmin evar!!1"


Many years ago I was a user of an IBM 3084 mainframe. One half of it was used for user workload (logged-in users using TSO, editing and compiling, and minor batch jobs). Because we were running some old software that could not be ported for XA (31-bit addressing), we had to run the machine with 24-bit 370 addressing, meaning we had only 16 MiB of physical memory. We used the second half of the machine to replace two 370/168s, one of which was exclusively for batch workloads, the second one for industrial control (and it was the highly specialized industrial control software that forced us to stay in 24-bit mode). At peak times, the machine had ~500 logged-in users, and that overloaded it so badly that response times were considered unacceptable: compiles of 1000-line programs took several minutes. At peak times, the machine was heavily swapping. And since supplies of fast 3380 disks was still low, it was swapping to 3350 disks. That was probably a good thing, since we had a handful of 3350s that had additional fixed heads installed (so a small number of disk tracks are always accessible, without arm movement), and those cylinders were used for swapping. Alas, each of those cylinders only gave a few MB of fast swap.

Now, you have to imagine this: A 16 MiB machine with 500 users (32 KiB per user!) was still capable of functioning, and compiling! Alas, it got slowed down by having to swap, even though it probably had dozens of MB of swap that didn't require disk seeks.

The solution was to throw money at it. Not just a little bit of money, but a ton of money. We bought a RAM disk from a Japanese manufacturer, which had the unimaginably large capacity of 144 MB, and was used for swap only. That capacity may seem laughable, but in those days the largest disk you could buy had a capacity of 2.5 GiB, and cost nearly $100K. With that additional swap disk, performance became bearable.

So swapping is not necessarily bad, if you are swapping to a sufficiently fast device. A million $ fast device. For comparison: The list price (in 1982 dollars) of the CPU was $8.7M.


----------



## vometia (May 1, 2021)

ralphbsz said:


> Many years ago I was a user of an IBM 3084 mainframe. [...]


That makes interesting reading; thanks!  I had some experience of a similar system, a 3090 of some description ("of some description" as I'm not 100% sure beyond that: it was over 30 years ago.  I stood next to it once and was transfixed by the typically IBM big clunky power switch) which I think had three CPUs and "some" memory: 64MB?  May have been 32+32MB (main+expanded) and a herd of 3380s and 3390s, but I was just Jane Random User who was trusted with TSO access and promptly ran up the department's bill.  A lot.  It supposedly had up to 2,000 users although "interactive" may be the wrong word to use; I think the vast majority were doing transactional stuff on CICS, TOPICS or the home-grown VISTA email & forums.  It's hard to let that latter one pass without comment as I still haven't seen an email system that comes close to it in terms of functionality.  They migrated to PROFS for some reason which was perplexing as it seemed a step backwards, though VM (on another 3090; MVS had a machine to itself) was a much nicer system to use than MVS which made me lose the will to live.

Anyway, it was remarkably quick, all things considered.  Not so much at the wrong end of a piece of wet string sharing 9.6 Kbits with another couple of dozen people but that was hardly the mainframe's fault.  Having said that, remote users preferred to dial into those Unix systems and through that overly-contended SDLC rather than the mainframe's own modem rack as the response times were better: I guess curses works better over very low-speed links (our modems had a max speed of 2,400 baud IIRC; the mainframe's may have been even less) than 3270 does.

Probably the slowest system I recall using was a Vax 11/785 at college.  It wasn't a bad machine in itself, though not sure how much memory it had, but up to 100 students all trying to do compilations at the same time was a bit much for the poor thing.  That said, it coped much better than the Suns we had in one of the labs that would grind to a complete standstill with as few as half a dozen users, though as they weren't all that different to the minicomputers I mentioned I have to wonder if they had some configuration "issues".

Also system names: a bit of a lack of imagination going on all round.  Those minicomputers were Philips P9070s, and the IT group was called ISA.  So our minicomputer was called P9070ISA. D:  The college's Vax ran VMS and was called VMS1, later joined by... you guessed it, VMS2 and VMS3.  The Vax with Unix was called unix1.  Lower-case, of course.  I thought they'd actually used some imagination by calling their PDP10s BLUE and ORANGE until I realised it's because they were coloured blue and orange.  In fact they were mostly beige, it was just that uncommonly interesting-looking strip across the top that had anything worth being called a colour (though BLUE being a KL10 had flashing lights and was therefore A Proper Computer™ but I've only seen it from the back).  The most "interesting" name belonged to the MVS box (well actually series of boxes: I recall it was quite long with a knobbly bit for the 3rd CPU) with the unmemorable name GBMTCP19, so unmemorable that I can somehow remember it 30 years later.


----------



## grahamperrin@ (May 1, 2021)

Emrion said:


> point you there



Side note:

<https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/geom-mirror.html> is an outdated edition.

Instead:

<https://docs.freebsd.org/en/books/handbook/geom/#geom-mirror>


----------



## grahamperrin@ (May 1, 2021)

djmasa said:


> Does anyone have any ideas on how to fix this messed up scenario?



Yes, but let's take your problem to a separate topic; you can ping me from there.


----------



## Sebastian (May 2, 2021)

djmasa said:


> So I upgraded one of my systems from 12.2-RELEASE to 13.0-RELEASE doing the standard procedure like always. After doing the first 'freebsd-update install' command to install the kernel, and rebooting after that, the system comes up with the new kernel, 13.0-RELEASE. When running freebsd-update install again to upgrade the rest of the system I get:
> 
> 
> ```
> ...



I have this bug on every major upgrade since years and could never figure out why this happens. I always get scared if I read the


```
root@server:~ # /usr/sbin/freebsd-update install
src component not installed, skipped
Cannot identify running kernel
root@server:~ #
```

But the workaround is .


```
zpool import -f bootpool
```


----------



## djmasa (May 2, 2021)

Sebastian said:


> I have this bug on every major upgrade since years and could never figure out why this happens. I always get scared if I read the
> 
> 
> ```
> ...



Thanks for your help, Sebastian. I don't know why I didn't think about that, but it worked. I'm gonna have to commit this one to memory. What a scary situation. Glad it wasn't for a server that was important!


----------



## astyle (May 3, 2021)

tuxador said:


> https://euroquis.nl//kde/2021/04/30/wayland.html soon plasma will be fully functional with Wayland.
> Anyway sddm must be disabled.


I do follow that blog, the guy is a FreeBSD committer. What I found out after my playing with the software is that Plasma is plenty functional with Wayland. The issue is really launching it. Somebody did figure out how to launch xorg on FreeBSD, what needs to be run first, second, and so on. The first command needs get a whole constellation of details to get right - the command itself, the args passed to it, where it's launched from (which TTY, or something different, FreeBSD-specific), what hardware drivers and devices to look for, what permissions are applicable, at what point in the boot process should it get launched, and all those ducks need to be lined up. And that's frankly my frustration - looks great, plenty functional, but startup is awkward at best.


----------



## grahamperrin@ (May 3, 2021)

X.Org



astyle said:


> … to launch xorg on FreeBSD, what needs to be run first, second, and so on. The first command needs get a whole constellation of details to get right …



That's extraordinary. 
It might have been truer years ago, but nowadays: things should largely look after themselves.


----------



## astyle (May 3, 2021)

grahamperrin said:


> X.Org
> 
> 
> 
> ...


Yeah, and it looks like in case of Wayland, that got taken a bit too far - everybody expects someone else to take care of a problem, and end result, nobody takes care of the problem. Somebody needs to get those FreeBSD-specific Wayland launch ducks lined up, and to put in some effort into maintaining that code. Code won't maintain itself, y'know.


----------



## vometia (May 4, 2021)

Another minor irritation about FBSD13 (and again ZFS related) is that the zfs startup script* now seems to mount things in an arbitrary order: it used to be alphabetical which made it easier to find stuff in a df listing as I use quite a lot of datasets.  Yes I know I could just use df on the dataset or directory in question but that's why it's "mildly irritating" rather than "actually dysfunctional"!

In the meantime I've just put my ZFS stuff in fstab and I guess that also works well enough as a long-term solution too if it needs to be... even if it is mildly irritating!

* Edit: more correctly the line that says zfs mount -a, so it's not actually the script's fault as I inadvertently implied.


----------



## huskers (May 14, 2021)

Installing qtile through pkg starts with a black screen. When tried to compile using ports fails due to conflict between python 7 and python 8

Downloaded the latest code from GitHub, same issue. Fails to install python8 due to conflict with python7. I have installed release 13 a fresh install using pkg. No port compilation except for the above.


----------



## astyle (May 14, 2021)

huskers said:


> Installing qtile through pkg starts with a black screen. When tried to compile using ports fails due to conflict between python 7 and python 8
> 
> Downloaded the latest code from GitHub, same issue. Fails to install python8 due to conflict with python7. I have installed release 13 a fresh install using pkg. No port compilation except for the above.


I have done lang/python37 and lang/python38 side-by-side, no conflicts. I guess the diff is having those things installed first... Semantic difference between prerequisite and a dependency seems to have finally reared its ugly head.


----------



## huskers (May 15, 2021)

On compilation, it tries to install cairo python package from 3.8 when 3.7 is already installed.


----------



## grahamperrin@ (May 16, 2021)

huskers said:


> … qtile …





huskers said:


> On compilation, it tries to install cairo python package from 3.8 when 3.7 is already installed.



Which repository do you use for packages? Run:

`grep url /etc/pkg/FreeBSD.conf`

See <https://www.freshports.org/graphics/py-cairo/>

Following a build using poudriere: 


```
% pkg rquery -r poudriere '%o %v' qtile py37-cairo py38-cairo
x11-wm/qtile 0.14.2
graphics/py-cairo 1.18.1_1,1
% pkg rquery -r poudriere '%o %v' py37-cairo
%
```


----------



## Aeterna (May 21, 2021)

VM related:
- broken evdev support - if enabled in firefox scrolling up works as "Go back one page button"  - only solution is to re-compile kernel with evdev disabled. Outstanding issue since evdev introduction
- broken virtualbox support for file sharing.   Outstanding issue since 12.0 (or earlier)
- broken terminal switching: switching between GUI and any terminal and - back renders GUI unresponsive.   Outstanding issue since 11.4
general:
broken software - audacious, libreoffice (tentative - maybe I am missing something)
broken kernel options TERMINAL_KERN_ATTR and TERMINAL_NORM_ATTR


----------



## Emrion (May 21, 2021)

Aeterna said:


> VM related:
> - broken evdev support - if enabled in firefox scrolling up works as "Go back one page button"  - only solution is to re-compile kernel with evdev disabled. Outstanding issue since evdev introduction


Not the only solution. I use xmodmap. See here: https://forums.freebsd.org/threads/gnome3-weird-scroll-wheel-behaviour.78532/#post-491139

I have no problem with terminal switching (I mean under VirtualBox).


----------



## Aeterna (May 21, 2021)

Emrion said:


> Not the only solution. I use xmodmap. See here: https://forums.freebsd.org/threads/gnome3-weird-scroll-wheel-behaviour.78532/#post-491139
> 
> I have no problem with terminal switching (I mean under VirtualBox).


your evdev solution works. thank you. However as I am always building custom kernel, I will just disable evdev in the kernel as before. 
Nevertheless this is a bug

terminal switching works with 3D acceleration disabled. When 3D acceleration is enabled terminal switching fails.
So this a bug also


----------



## kpedersen (May 21, 2021)

I can add a couple of annoyances:

The /etc/motd has changed and now has this slightly over-engineered "template" approach. There is probably a reason for this. Perhaps in the future they plan to add # packages installed, cpu utilization, etc. This is a feature of Ubuntu that I remember being a little tacky. I prefer my logins to be deterministic so if anything changes, I can spot it quickly.


(This came in a little before 13 if I recall). By default the skel .profile runs `fortune` so I get some random message from i.e Dru Lavigne. Again, I prefer deterministic logins so it is easier to spot if there are problems. Also, does anyone else find any of these "tips" useful? It is surely just clutter.
Luckily pretty minor but I guess the real question is, why do people want so much noise when they log into an ssh server?


----------



## ralphbsz (May 21, 2021)

kpedersen said:


> By default the skel .profile runs fortune so I get some random message from i.e Dru Lavigne. Again, I prefer deterministic logins so it is easier to spot if there are problems. Also, does anyone else find any of these "tips" useful? It is surely just clutter.


Go back about 40 years, late 70s and early 80s. This is the time the first Unix machines hit the wider public, come out of being in a small handful of research labs. On one hand, you have serious computers, made for example by IBM (and the seven dwarves) and Digital (and it's dwarves: Data General, Prime, ...). Those are used by serious business people and engineers. The machines are very expensive, it would be wasteful to use them for something merely amusing. The people who use them typically wear white lab coats, are controlled by people who wear suit and tie, or (on the engineering side for minicomputers) have pocket protectors and slide rules.

Now contrast that with Bell Labs and Berkeley. Look at the pictures of Dennis and Ken and check their hair style. Just saying "Berkeley" is enough to make it counter-culture land. People here have a biting sense of humor, and love amusements. Spending precious engineering effort and disk space + CPU time on implementing "fortune" is exactly a symbol of that. Symbols matter: it demonstrates that Unix is not MVS or VMS.

Now fast forward 40 years. The counter-culture movement has won. You can't go work in suit and tie any more in a computer or engineering job, unless you do so ironically. We run most of the computers in the world (Linux has >90% market share among servers) using an OS designed by a drunk college student (yes, I've gone to "99 bottles of beer" with Linus, he does get drunk, at least he did back then). Today, running "fortune" is only a deep bow of to two cultures, which both stopped being relevant decades ago, but they are still part of our history.


----------



## kpedersen (May 21, 2021)

ralphbsz said:


> Today, running "fortune" is only a deep bow of to two cultures, which both stopped being relevant decades ago, but they are still part of our history.


Heh, I do kind of get that and suppose I can see this "trinket" in a different kind of light. Though I still wonder why just as recently as FreeBSD 12.x was it suddenly decided to be added to the default .profile script?

Do you really think it was added there as a culture symbol? Something like "No kids, you can't have Docker, you get `fortune` instead. Be happy!".


----------



## grahamperrin@ (May 22, 2021)

With the fortune stuff not enabled by default (correct me if I'm wrong), I never thought of it as clutter.

Some content is outdated, but overall: it has helped me enormously.


----------



## datasmurf (May 22, 2021)

I enjoy the classic FreeBSD fortunes a lot. Missing them.


----------



## kpedersen (May 22, 2021)

grahamperrin said:


> With the fortune stuff not enabled by default (correct me if I'm wrong), I never thought of it as clutter.


Yes, it does seem to be enabled by default now (since FreeBSD 12.x). Of course when it was just a couple of kb program in /usr/bin doing nothing, it wasn't annoying, I was happy to let it be. Now I just have to remember to comment it out from dotfiles in /usr/share/skel.

Obviously not a critical issue but I guess I am more intrigued about why it was suddenly added to the default .profile so recently. Just seems like an odd choice. It also seemed like FreeBSD was moving away from that kind of stuff.


----------



## grahamperrin@ (May 22, 2021)

Enabled for new users but not for root. 2015: 









						Step 1 of eliminating the "games" distribution: Move binaries to /usr… · freebsd/freebsd-src@11d9aa6
					

…/bin;  update paths; and include everything in the "base" distribution.  The "games" distribution being optional made sense when there were more games and we had small disks; b...




					github.com
				






> > … keep fortune, factor, morse, number, primes, and random, since there is evidence that those are still being used. …



<https://cgit.freebsd.org/src/diff/share/skel/dot.login?id=11d9aa670723f508821f2bf6980a555360783a80>

<https://cgit.freebsd.org/src/diff/share/skel/dot.profile?id=11d9aa670723f508821f2bf6980a555360783a80>


----------



## kpedersen (May 22, 2021)

grahamperrin said:


> Was it sudden or recent?
> 
> From <https://cgit.freebsd.org/src/commit/?id=11d9aa670723f508821f2bf6980a555360783a80> (2015):


It was made part of the standard base in 2015 (rather than in the games dist) which is what that link is detailing. And this I absolutely agree with, it was odd having a games package which was almost less than 1MB.

However I can't seem to find why it was decided it would improve FreeBSD by adding it to run in the default .profile. So likely someone thought "oh, goody, its in base now!, lets overly consume it and add it to the profile scripts just because we can!". This is disappointing that this idea got through review. Developers just can't help themselves it seems.

I do like the program, it is actually very useful when intentionally controlled and run with custom tips (i.e to tell staff / students how to utilize site specific services). Just weird that it has been pushed on us in such an arbitrary way.

However, perhaps this is almost a good demonstration of why we don't want graphical GUI tools to be added to base, because they will probably also end up bizarrely in startup scripts and clutter up the experience more. I am also fairly convinced that when we get this new pkg base in, people will have all kinds of crazy ideas about pulling in even more random trinkets. Perhaps they will start adding vim into the default install because "it is a package just like nvi now, so why not? Has more features right?"


----------



## zirias@ (May 22, 2021)

kpedersen said:


> I am also fairly convinced that when we get this new pkg base in, people will have all kinds of crazy ideas about pulling in even more random trinkets.


Frankly, I expect the opposite. "pkg base" is already integrated (you'll find it in the Makefiles, for example), it just isn't the way how base is distributed. It's unclear to me when this will come (or whether it will come at all) – but _if_ this is some day the way to distribute base, it will change two things for users:

You _need_ `pkg` in any case and
You can decide which parts of base to install without building it yourself
For developers, this means the decision of what should be part of base will (slightly) change. The only remaining consideration will be: Does it make sense to have this in our tree, maintain it ourselves, support it with our release cycle and release engineering? I expect, with only this question to be answered, quite a few things might be _removed_ from base.


----------



## kpedersen (May 22, 2021)

Yeah, thats fair. I will just need to wait and see (I will reserve my incessant whining for then 



Zirias said:


> quite a few things might be _removed_ from base.


Agreed, I think at this point they might have a big rethink on all the programs. I am in two minds on this, in some ways I like simplicity and minimalism. But in other ways I don't find a completely sterile DIY environment like many Linux distributions provide very productive.
For me, I hope they adhere strictly to POSIX, SUS and don't do weird things like Debian did like removing ed.

At the same time, I find nc very useful and yet it is in neither POSIX or SUS. So in theory that would be a candidate for removal.


----------



## grahamperrin@ (May 22, 2021)

See the two (2015) links that I added to the foot of my previous post.

Originally (2001):









						Automatically exec bash at startup if it exists^U Turn on the display of · freebsd/freebsd-src@9f1f5e8
					

tips from the freebsd-tips database at login time.




					github.com
				






> > … Turn on the display of tips from the freebsd-tips database at login time.


----------



## kpedersen (May 22, 2021)

grahamperrin said:


> See the two links that I added to the foot of my previous post.


Ah I missed that. It makes sense. So FreeBSD's default profile (and login) *always* used to run fortune *if it existed*. Now because it has been moved into base (rather than the optional games dist that I generally would skip) it is always installed (and thus run).

OK, that does explain it. Mystery solved. Thanks!


----------



## Emrion (May 23, 2021)

Aeterna said:


> your evdev solution works. thank you. However as I am always building custom kernel, I will just disable evdev in the kernel as before.
> Nevertheless this is a bug
> 
> terminal switching works with 3D acceleration disabled. When 3D acceleration is enabled terminal switching fails.
> So this a bug also


I have never seen the purpose to enable 3D acceleration in a VM. But I have done it this time to test.
In VirtualBox, to do so, you are obliged to use VMSVGA as graphic adapter.
Running `glxgears` under 13.0-RELEASE, this increases the FPS from about 800 to 1100. Well...

That being said, I have yet no problem to switch between terminals. So, if it is a bug, it's more specific than you believe.


----------



## Aeterna (May 23, 2021)

Emrion said:


> I have never seen the purpose to enable 3D acceleration in a VM. But I have done it this time to test.
> In VirtualBox, to do so, you are obliged to use VMSVGA as graphic adapter.
> Running `glxgears` under 13.0-RELEASE, this increases the FPS from about 800 to 1100. Well...
> 
> That being said, I have yet no problem to switch between terminals. So, if it is a bug, it's more specific than you believe.


no, you are not obliged to run VMSVGA to get 3D working (I am getting black screen with VMSVGA/Slim/xfce4 so this is not an option for me).
VboxSVGA runs fine with 3D and 258MG Video RAM (if you want this).
I see:
6009 frames in 5.0 seconds = 1201.728 FPS


----------



## Emrion (May 23, 2021)

I forgot to say it was under virtualbox-ose-additions-legacy. Because nothing works otherwise.
My virtualBox run under Windows 7, it's the last version: 6.1.22. I assure you, 3d enabled = VMSVGA. Maximum video ram = 128 Mio. Your VMs are under Linux?


----------



## Aeterna (May 24, 2021)

Emrion said:


> I forgot to say it was under virtualbox-ose-additions-legacy. Because nothing works otherwise.
> My virtualBox run under Windows 7, it's the last version: 6.1.22. I assure you, 3d enabled = VMSVGA. Maximum video ram = 128 Mio. Your VMs are under Linux?


yes, I use Slackware.
These options should be available irrelevant of the host OS, they just are hidden:
1) setup VMSVGA with 3D acceleration (important, otherwise you will not get 3D acceleration)
2) go to the screen as in my screenshot
3) click on Video memory value (e.g. 128MB) and move slider to the right
4) click on Graphic controler value (VMSVGA) change to VboxSVGA
5) you should se benign error/exclamation mark stating "Invalid settings detected" when editing settings. Don't worry about this.
6) remember that you will have to set VboxSVGA/3D acceleration each time you edit settings (memory settings are fine).

that is all.


----------



## Emrion (May 24, 2021)

As you said, "should". There is no means to have 3d acceleration without VMSGA in my case. You can select VBoxSVGA but when you reopen the settings of the VM, it has returned to VMSVGA.


----------



## Aeterna (May 24, 2021)

Emrion said:


> As you said, "should". There is no means to have 3d acceleration without VMSGA in my case. You can select VBoxSVGA but when you reopen the settings of the VM, it has returned to VMSVGA.


...but but this is exactly what I said:

6) remember that you will have to set VboxSVGA/3D acceleration each time you edit settings (memory settings are fine).

I don't this as a problem because once all is set up I don't need to edit VM clients setting. However if there is a need for editing, I will have to apply VboxSVGA 3D settings again (as I explained in my post above)


----------



## Emrion (May 24, 2021)

After several tries, I eventually managed to get the VBoxSVGA with 3d acceleration.
And always no trace of the bug you mentioned.


----------



## Aeterna (May 24, 2021)

good that VboxSVGA works with 3D.

Bug may be related to virtualbox-ose-client (versions?). I can easily switch terminals in linux VM clients and even in OpenBSD in VM (without virtualbox support)


----------



## grahamperrin@ (May 25, 2021)

Emrion said:


> … VMSVGA as graphic adapter.
> Running `glxgears` under 13.0-RELEASE, this increases the FPS from about 800 to 1100. …



Off-topic from FreeBSD 13:

VMSVGA is known to cause problems with emulators/virtualbox-ose-additions.
Instead, with *VBoxSVGA*:


----------



## grahamperrin@ (Jul 14, 2021)

decuser said:


> … default KDE install on FreeBSD 13 tries to login to a Wayland session, …



Is this still true? 

In any case: the Quick start warns to not choose Wayland.


----------



## astyle (Jul 14, 2021)

My standing annoyance that was since 6.0, never resolved (not even in 13-RELEASE) is upgradeability of KDE...  I want to upgrade in-place, but current systems are not very warm to the idea.  Frustrating how Frameworks ports are spread all over /usr/ports, and Plasma5 ports are organized the same.  Making a meta-port is one thing, but upgrading invites dependency hell if I miss a dependency. I just don't have the time or motivation to hunt down every single one...


----------



## grahamperrin@ (Jul 14, 2021)

astyle said:


> … KDE... I want to upgrade in-place …



Sorry, I don't understand.


----------



## astyle (Jul 14, 2021)

grahamperrin said:


> Sorry, I don't understand.


Well, I only have one FreeBSD machine... no $ to build more physical machines. Ahhhh... just read my profile, I had a conversation with SirDice about that annoyance, it will help you understand.


----------



## grahamperrin@ (Jul 14, 2021)

I still don't understand what's meant by _in-place_ upgrade.


----------



## sidetone (Jul 14, 2021)

grahamperrin said:


> I still don't understand what's meant by _in-place_ upgrade.


I think astyle means an easy upgrade that doesn't ask for complicated and overly changed dependencies. An upgrade which relies on simply updating things that are needed, and not breaking things, or asking for complicated sets of deinstalls and reinstalls.


----------



## grahamperrin@ (Jul 16, 2021)

grahamperrin said:


> … what's meant by _in-place_ upgrade.



▶ <https://forums.FreeBSD.org/threads/78594/post-522772>


----------



## monwarez (Jul 23, 2021)

After testing the upgrade to 13-RELEASE I just had two issue:
- nfsv4 and kerberos does not seems to woks (I know there is nfs with tls, but I am using a client with 12.2 and the server with 13.0 to test the upgrade)
- The tools that I use for backup does not seems to work properly when the client is 12.2 and the server is 13.0 (but work with the opposite). The tools is sysutils/zrepl -> It seems that since I use it inside a jail, my zfs inside the jail does not work well with OpenZFS
I used zfs boot environment to test it, and for the moment I will stay on 12.2 at least for my "server"


----------

