Difficulty with my latest current build

Greetings,

I recently rebuilt world with current and ran into a difficulty when I rebooted. I got several notifications say: limits: setrlimit pipebuf: Invalid argument. This message arose when trying to start cupsd, sshd, cron, syslogd, ntpd. I am now unable to get out of this. No access to the internet, my mouse does not work. can't print, and so forth. Any idea what has happened and is there any easy way to fix this? I have an amd64 computer newly built and that was working great until this last build. The current version of the OS is FreeBSD 15.0 dated Wed. June 12 2024. I am not sure how I got that version since I have been regularly updating (daily) the sources though GIT. I hope I can fix this without having to wipe the OS off and install a new version. Below is two screenshots of the latest boots.

I have had a previous problem with newly built kernels not booting. I have been booting though older, working kernels for the last couple of rebuilds. Perhaps this is related. The first screenshot shows the error message for this problem. It indicates that something is out-of-date, but I have no idea what. Anyway, I appreciate any guidance that I get on resolving these issues,

Best wishes,
Neal

IMG_20241002_095231sm.jpg
IMG_20241001_105741-sm.jpg
 
 
IMO we should discourage buildworld/buildkernel pointing users to freebsd-update and binary packages wherever possible.
 
IMO we should discourage buildworld/buildkernel pointing users to freebsd-update and binary packages wherever possible.
Why? That's one of the core values of FreeBSD, the freedom to explore. We can instead, direct tinkerers to the right place to look for answers.

ndelmonico

As mentioned in the article that SirDice provided, -CURRENT branch is not something you want to use for production or reliability. You could at least install a -STABLE branch to avoid issues like these (but no guarantee though).

What config files have you edited?
 
For the original issue, you want to disable 3rd party modules (such as from ports) from being loaded during boot anytime you are upgrading from source; this is not restricted to CURRENT and should be normal practice for STABLE and RELEASE versions. If you do not need a module booted early by placing it in /boot/loader.conf then it should be loaded by /etc/rc.conf later to minimize the chance of harder to fix boot issues. First screenshot looks like it was already properly in /etc/rc.conf and you forgot to 'temporarily' remove the module from the kld_list= variable; I usually keep 2 lines and uncomment one or the other to boot with only base provided modules vs base+ports provided modules. Once you have rebooted successfully you can rebuild+reinstall any problematic/incompatible modules; I just do them all as I don't know how to preemptively know its an issue unless /usr/src/UPDATING entries gave me a clue.

Alternatively you could add a line to /etc/src.conf to have the ports with kernel modules (and their dependencies) rebuilt during the build. An example:
PORTS_MODULES=x11/nvidia-driver-390 emulators/virtualbox-ose-kmod graphics/drm-kmod sysutils/openzfs-kmod. This is not without its own issues so watch out for bugs like PR 259702 which until fixed requires either manually answering through all make config dialogs (portupgrade/portmaster can help), not building with 'any' -j setting (-j1 is a setting and will fail too), or splitting the build step into 2 parts with the second setting PORTS_MODULES and removing the -j setting. First workaround keeps correct build performance but is a step that cannot be skipped, 2nd will slow down the build (amount increases with the number of cores in the machine), 3rd also increases build times but only during the port build process but if the port also (re)builds large things like llvm or gcc then remember those too may now be running without a desired -j. Of course, you can ignore these if you just manually rebuild+reinstall the ports after world+kernel are rebuilt+reinstalled but your steps likely are now back to the first paragraph.
Why? That's one of the core values of FreeBSD, the freedom to explore. We can instead, direct tinkerers to the right place to look for answers.
Because freebsd-update and pkg are for installing precompiled packages. If buildworld/buildkernel customizations and version differences are not compatible with the originally compiled packages then incompatibilities are brought in with such mixed steps. The way to properly use those with custom builds is to custom build the freebsd-update and pkg repos against the custom built world+kernel.
 
… -CURRENT branch is not something you want to use for production or reliability. …

1728160402222.png


… 15.0 dated Wed. June 12 2024. I am not sure how I got that version since I have been regularly updating (daily) the sources though GIT. …

Boot in single user mode, then:

bectl list -c creation

What's listed?

panic: malloc_init: type dmabuf with unsupported version 2020110501


… No access to the internet, …

You could boot from an installer, get an Internet connection and switch the already installed system to pkgbase. I switched to pkgbase for CURRENT in February, it's smooth.
 

Attachments

  • 1728160361470.png
    1728160361470.png
    24.4 KB · Views: 234
Back
Top