FreeBSD 13 annoyances?

decuser

decuser

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 :).
 
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:beer: is on me now.

I created ~/.inputrc and put this:
Code: 
set enable-bracketed-paste off
This disables it by default for all programs using readline.
 
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 :)
 
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.
 
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
Click to expand...
-->
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:

hw.usb.usbhid.enable=1
usbhid_load="YES"
Click to expand...
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.
 
Last edited:
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 :p
The desktops use mainly i3 (and some xfce) so the typical KDE beast-problems are also something I just completely bypass.
 
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
Click to expand...
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.
 
_martin said:
I created ~/.inputrc and put this:
Code: 
set enable-bracketed-paste off
This disables it by default for all programs using readline.
Click to expand...
I wanted to hit thanks twice on this :). This works for sudo -s sessions initiated from the user's bash shell and, and, and!
 
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. ?
 
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.
 
I think there is something wrong with NFS with FreeBSD 13.0, my Linux client seems do hang/freeze when there is some IO.
 
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.
 
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.
 
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?
 
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.
 
You must log in or register to reply here.
Back
Top