Is there any wisdom re: order of things to install ?

drsnx60

drsnx60

Hi I tend to install Freebsd rather often now to keep up with new S/W releases.
I usually do :

Install from media without SRC or PORTS
install GIT. Grab fresh copies SRC and PORTs for apropriate version.
Buildworld & Buildkernel for actual CPU type
Install Xorg.
Install / configure Rocky Linux 9 emulator
build and install Nvidia packages . ( never bought any AMDGPU )
setup /boot/loader.conf and /etc/rc.conf and /etc/X11/xorg.conf
start Xorg - TWM
build/install GNOME
start Xorg - GNOME

build/install KDE6/PLASMA6
start Xorg - KDE6

Build/install MATE + Libreoffice , any other things to play with ,

This process seems to usually work well.

Are you able to share any wisdom - shine any light , on this shedule ?
What is your process like ?
 
I do things differently...

I'm on all-AMD hardware, but that would not affect the order in which I like to do it...

Install from media, with SRC, but not PORTS.
Buildworld & Buildkernel - only started doing that recently, because of a weird bug with Spectacle on Wayland. It's frankly still not resolved, and I frankly can skip that step.
Grab a fresh copy of ports into /usr/ports. I go with ports, and turn on all the flags that make config gives me.
Build nano
Build GCC/LLVM/Rust
Build Graphviz.
Build FFMPEG
Build drm-kmod. Well, for the iGPU that's on my Ryzen 5 7600, I have some special instructions to follow for a successful install
Set up /etc/rc.conf to load amdgpu
Build Xorg, and see if TWM works. If it works, great, that means I can build KDE 6.

Build x11/plasma6-plasma.
Set up /etc/rc.conf and /etc/fstab

Start Plasma 6.

Takes me about 3 days to do that. More if the hardware I use is not very powerful.
 
drsnx60 said:
Buildworld & Buildkernel for actual CPU type
Click to expand...
Why bother? How much difference do you think this will make?

The only reason to buildworld/buildkernel yourself is when you're running -STABLE (or -CURRENT). And/or you want to strip out a lot of stuff (src.conf(5)). Other than that, just go with freebsd-update(8) or give PkgBase a shot.

drsnx60 said:
setup /boot/loader.conf and /etc/rc.conf and /etc/X11/xorg.conf
Click to expand...
Hehe, old school 😁 We moved away from /etc/X11 a long time ago. Even that monolithic xorg.conf is a thing of the past. Just add a couple of config snippets in /usr/local/etc/X11/xorg.conf.d/ if needed. Most of the time you don't to configure anything at all.
 
Today its probably mostly the set of SIMD instructions available to use for the compiler that is affecting the output binaries.
While later CPU generations have AVX512 SIMD, earlier X86-64 chip does not. So the freebsd binaries/packages in there online
repositories need to have only a limited set of SIMD included. The fairly recent implementation of SIMD in libc means
that there must be a base-level implemented in the precompiled kernel/userland.
 
I compile to turn on software features that I usually see as 'missing' in pre-compiled packages.

I normally don't really care if it's AVX512 or earlier instruction sets. It would take having a good handle on where they make a difference. As an example, if VLC package is pre-compiled without the ability to turn on subtitles, I ditch the pre-compiled package, because I do want to be able to turn on subtitles.

Pre-compiled packages have their options turned on or off largely to optimize for large-scale automation like pkg-autoremove or pkg-upgrade.. After reading the horror stories of messed-up installations, my conclusion was to stick to ports, and do my own compilations, even if it takes awhile.
 
I usually just install the standard kernel, my hardware is pretty generic, I don't compile custom kernel. Then I install xorg and windowmaker, a bunch of the usual X programs, cli tools, compilers, vim, libreoffice, mupdf, mpv, mpd, firefox. I check that I've got accelerated graphics and it's not running the vesa server, if it is running vesa I have to mess around with drm-kmod etc until i get accel working. Similarly I check that sound is working correctly, both speakers and headphones. I have working copies of rc.conf, loader.conf, sysctl.conf etc set up that I copy over and customise. I usually like setting up a lagg interface so that I get transparent failover between wired ethernet and wifi. Most of the install is done from packages, not source, although there are a few things I get from git, like latest version of yt-dlp. I put 14.2 on from scratch recently and didn't have any pkg horror stories. Perhaps its because I don't use more complex desktop environments like gnome and kde, so there's less complex dependencies to get mixed up. Or maybe I just got lucky.
 
Last edited:
I have a general initial recipe to follow before window managers or major applications. It is personal, but a good guide for the basics:
Code: 
1.  Personal account gets wheel group membership

pw groupmod <me> -m wheel

2.  Modify /etc/sudoers (I am in group wheel)

%wheel ALL=(ALL) NOPASSWD:ALL

3.  Packages

# The package management tool (skip this to keep quarterly)

sed -i '' s/quarterly/latest/g /etc/pkg/FreeBSD.conf
pkg install pkg
# Patch it
freebsd-update fetch install
shutdown -r now
pkg upgrade

4.  Install static and dynamic Korn shell

cd /usr/ports/shells/pdksh
make clean
make rmconfig
make # choose static
make install
# move static ksh to /bin/ksh, and add to /etc/shells
make clean
make rmconfig
make deinstall
make install # dynamic
make clean

5.  Root Account Changes

I add to ~root/.ssh/authorized_keys the public key for the root account
on my ZFS server which authorises the execution of backups pulled from
the ZFS server root account.  I then test the ssh login manually, as the
~root/.ssh/known_hosts file must be updated.

6.  Personal Home Directory

I copy (scp) in the all of the important .files in my home directory.

7.  Secure Shell Setup

cd /etc/ssh
cp -p ssh_config ssh_config.orig
cp -p sshd_config sshd_config.orig
cat >>ssh_config <<'EOF'
ForwardX11 yes
PubkeyAcceptedKeyTypes=+ssh-dss
EOF

cat >>sshd_config <<'EOF'
# FreeBSD 14.x changes X11 defaults
X11Forwarding yes
# We need to allow root login for rsnapshot backup server
PermitRootLogin prohibit-password
# We want login via ssh with keys only...
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAcceptedKeyTypes=+ssh-dss
EOF

service sshd restart

8.  Install Packages

pkg install <giant list here>

9.  Modify /etc/*.conf, and /usr/local/etc/*.conf

Always /etc/rc.conf, and others, as required

Reboot generally required after this

10. Configure important apps

e.g. sendmail, cups, ntp, ...
 
astyle said:
I compile to turn on software features that I usually see as 'missing' in pre-compiled packages.

I normally don't really care if it's AVX512 or earlier instruction sets. It would take having a good handle on where they make a difference. As an example, if VLC package is pre-compiled without the ability to turn on subtitles, I ditch the pre-compiled package, because I do want to be able to turn on subtitles.

Pre-compiled packages have their options turned on or off largely to optimize for large-scale automation like pkg-autoremove or pkg-upgrade.. After reading the horror stories of messed-up installations, my conclusion was to stick to ports, and do my own compilations, even if it takes awhile.
Click to expand...

The usual complaint is the defaults turn-on too much, adding "bloat". Personally it's a long time since I've seen a serious omission that wasn't off for a good reason (such as a bug). A lot of port options are just optional dependencies that can be added manually anyway. Also some port options are misleading and not as important as they might seem. I don't understand why you think they are chosen for the benefit of "large-scale automation like pkg-autoremove or pkg-upgrade" - where did that come from?

I've found everything to go a lot more smoothly since switching to packages.

I only rarely do clean installs, the last was 3 or 4 years ago when I switched to ZFS, before that I moved the installation to new drives more often than I reinstalled.
 
I myself have been using a slew of setup_scripts. I have a bunch in a directory which I can launch one-at-a-time or in batch (via rcorder for example) depending on the need. So, in the case of a fresh install, I mount an "/opt/" directory from my NFS Server, edit an "environment file" (typically not necessary) and launch a script which uses `rcorder` to get a list of scripts to launch in order.

In the case of an update (to "the gateway IP" for example), I can just launch the scripts I need at the time.

My scripts are separated into "setup" and "package" like:
Code: 
doas_package.sh*
doas_setup.sh*
sshd_package.sh*
sshd_setup.sh*
...

In the case of "sshd_package.sh", I don't actually have a package to install so it is just a placeholder.

The other types of things are just "setup" scripts that do basic configs:

Code: 
jail_setup.sh*
ntpd_setup.sh*
resolv_setup.sh*
skel_cshrc_setup.sh*
skel_nexrc_setup.sh*
...

What a setup script looks like:
Code: 
#!/bin/sh

# PROVIDE: jail_setup
# REQUIRE: resolv_setup
# BEFORE:
# KEYWORD:

desc="Sets up a ZROOT for jails."

mkdir -p /opt/info
touch /opt/info/environment

. /opt/info/environment

: ${ZROOT:="zroot/jails"}
: ${ZROOT_MOUNT:="/usr/local/jails"}                   # Location where jails will be created.
: ${ZROOT_MEDIA:="zroot/jails/media"}                  # Media will contain the compressed userland files.
: ${ZROOT_TEMPLATES:="zroot/jails/templates"}          # Templates will contain the templates when using Thin Jails.
: ${ZROOT_CONTAINERS:="zroot/jails/containers"}        # Containers will contain the jails.

sysrc -f /opt/info/environment ZROOT=${ZROOT}
# ... more sysrc calls ...

jail_setup() {
        # Setup jail directories.
        zfs create -o mountpoint=${ZROOT_MOUNT} ${ZROOT}
        zfs create ${ZROOT_MEDIA}
        zfs create ${ZROOT_TEMPLATES}
        zfs create ${ZROOT_CONTAINERS}

        # Get a userland.
        # ...

        # Set up a bridge for VNET.
        # ...

        # Support stuff.
        # ...
        # etc.
 
bob2112 said:
The usual complaint is the defaults turn-on too much, adding "bloat". Personally it's a long time since I've seen a serious omission that wasn't off for a good reason (such as a bug). A lot of port options are just optional dependencies that can be added manually anyway. Also some port options are misleading and not as important as they might seem. I don't understand why you think they are chosen for the benefit of "large-scale automation like pkg-autoremove or pkg-upgrade" - where did that come from?

I've found everything to go a lot more smoothly since switching to packages.

I only rarely do clean installs, the last was 3 or 4 years ago when I switched to ZFS, before that I moved the installation to new drives more often than I reinstalled.
Click to expand...
In my opinion, the defaults turn on way too little. If I turn everything on, a lot of good stuff gets compiled early on, and I don't have to bother adding stuff manually later. For example, sound options - a LOT of them ar just turned off in the defaults, and then I see tons of complaints about how ALSA is not working, or PortAudio, or Jack... if I compile 'em all, everything works fine, no complaints, and I don't have to hunt down extra stuff and install it by hand.

Besides, with the pkg debacle that happened recently (there's a separate thread (Thread pkg-2-0-0-problems.96540) about that), I actually think to myself that my decision to stick with ports was a smart idea. And I've been with ZFS since 2017, because it was a no-brainer for me, I could just stop partitioning and forget all about it. And if I want to fine-tune some limits on my filesystem, I can do it after installation, no problem. Yep, I give my whole SSD to ZFS, those two were meant for each other ;)
 
drsnx60 said:
Today its probably mostly the set of SIMD instructions available to use for the compiler that is affecting the output binaries.
While later CPU generations have AVX512 SIMD, earlier X86-64 chip does not. So the freebsd binaries/packages in there online
repositories need to have only a limited set of SIMD included. The fairly recent implementation of SIMD in libc means
that there must be a base-level implemented in the precompiled kernel/userland.
Click to expand...

The compiler's own ability to use SIMD instructions out of plain C code is very limited. I share the view that unless you are very I/O heavy you probably won't get much of an advantage from compiling a kernel, unless there are #ifdef'ed hand-written assembler instructions with SIMD.
 
Agreed, when I wanted to use SIMD in the past, I had to write assembler to access them. Same with things like memory barrier primitives, writing fast spinlocks, rdtsc, etc. I refuse to say whether I used inline asm because I know the shrieks of outrage and howls of pain that will follow, so you'll just have to guess! 😅
 
astyle said:
In my opinion, the defaults turn on way too little. If I turn everything on, a lot of good stuff gets compiled early on, and I don't have to bother adding stuff manually later. For example, sound options - a LOT of them ar just turned off in the defaults, and then I see tons of complaints about how ALSA is not working, or PortAudio, or Jack... if I compile 'em all, everything works fine, no complaints, and I don't have to hunt down extra stuff and install it by hand.

Besides, with the pkg debacle that happened recently (there's a separate thread (Thread pkg-2-0-0-problems.96540) about that), I actually think to myself that my decision to stick with ports was a smart idea. And I've been with ZFS since 2017, because it was a no-brainer for me, I could just stop partitioning and forget all about it. And if I want to fine-tune some limits on my filesystem, I can do it after installation, no problem. Yep, I give my whole SSD to ZFS, those two were meant for each other ;)
Click to expand...

Note the date on that pkg bug thread, 20 days after the 2025Q1 branch was created, so it wouldn't have affected anyone on quarterly packages - presumably this was not a coincidence. The ports system works though pkg so it's also vulnerable to its bugs.

If you maintain your packages through pkg, adding a package like pulseaudio is a one-off, set and forget, operation - much less trouble IMO than going though numerous port menus on a regular basis.
 
blackbird9 said:
Agreed, when I wanted to use SIMD in the past, I had to write assembler to access them. Same with things like memory barrier primitives, writing fast spinlocks, rdtsc, etc. I refuse to say whether I used inline asm because I know the shrieks of outrage and howls of pain that will follow, so you'll just have to guess! 😅
Click to expand...
Seems like people who actually know enough assembler to be able to productively use it - they have strong opinions about what's correct usage, and little self-discipline/social awareness.
 
bob2112 said:
Note the date on that pkg bug thread, 20 days after the 2025Q1 branch was created, so it wouldn't have affected anyone on quarterly packages - presumably this was not a coincidence. The ports system works though pkg so it's also vulnerable to its bugs.

If you maintain your packages through pkg, adding a package like pulseaudio is a one-off, set and forget, operation - much less trouble IMO than going though numerous port menus on a regular basis.
Click to expand...
There's still people having trouble with pkg, and creating threads because they don't know how to do research: Thread pkg-8-an-error-occured-while-fetching-package-no-error.96761. Check the date of creation and last post there.

And - I'd rather spend 3 days compiling and going through port menus, and be done after that for a couple years easy. No need to research missing features and how to enable/configure them - all because I had the brains to turn the port flags on at the start.
 
One thing I've started doing over the last few years is setting up local unbound to perform DoT encrypted dns queries. I followed the 'may contain traces of bolts' blog howto here...
... which dates from freebsd 12. I noticed recently there are a few other web howtos on how to do this, all somewhat different. I wonder if anyone has worked out a 'definitive' way to set that up. Perhaps this should be another thread...
 
Is there any wisdom re: order of things to install ?
I don't think there are any such recommendations. Everyone has their own procedures and schedules. There is a mainstream and individuality. There are paradigms in architecture, security, process management, etc.
In short: your schedule is completely different from mine. I am moving away from X, I absolutely do not need emulation of any Linux products. Also, the fact that I work without DoT does not bother me yet...
Well, and minimization, refusal of monstrosity in any form (when there is no extra money for hardware). And the most important thing is the availability of money. With a lot of money, some directions can change (you can buy a hardware firewall, gateway, etc. for your apartment). Then all these hand-made home-made security scripts will have no chance of survival. Something like that.
 
astyle said:
There's still people having trouble with pkg, and creating threads because they don't know how to do research: Thread pkg-8-an-error-occured-while-fetching-package-no-error.96761. Check the date of creation and last post there.

And - I'd rather spend 3 days compiling and going through port menus, and be done after that for a couple years easy. No need to research missing features and how to enable/configure them - all because I had the brains to turn the port flags on at the start.
Click to expand...
Yes I realize that I need to research Audio compile options more diligently at some point. ALSA, OSS,NAS, PULSEAUDIO,SNDIO,JACK ........ to build a coherent setup. presently
i dont know which of these exclude each other or coexist . A chart on how allthese hang together would be useful. I cant se any evidence of a consistent policy in the ports either for which audiostack is prefered or default.
 
drsnx60 said:
I realize that I need to research Audio compile options more diligently at some point. ALSA, OSS,NAS, PULSEAUDIO,SNDIO,JACK ........ to build a coherent setup.
Click to expand...
This is an important point, worth to open a separate thread. I doubt hat the ports tree have consistent default port options for packages?
 
drsnx60 said:
ALSA, OSS,NAS, PULSEAUDIO,SNDIO,JACK ........ to build a coherent setup. presently
i dont know which of these exclude each other or coexist .
Click to expand...
Thing is - none of them exclude each other!

They compile just fine!

And the ports that depend on those sound systems - the apps are not broken, either. I just select 'em all wholesale, and will probably add 'em to /etc/make.conf at some point.
 
I build world + kernel locally as I do not like freebsd-update[1]. But I build hardly any package locally. I also track {stable,current}x{amd64,arm64} changes and build these things locally fairly regularly. So I have one local .git tree, git worktrees for stable & master.

[1] Apart from all the zillion files freebsd-update downloads, local kernel/world building is a required skill if you want to debug or contribute to kernel/userland code.
 
drsnx60 said:
I usually do :

Install from media without SRC or PORTS
install GIT. Grab fresh copies SRC and PORTs for apropriate version.
Buildworld & Buildkernel for actual CPU type
Install Xorg.
Install / configure Rocky Linux 9 emulator
build and install Nvidia packages . ( never bought any AMDGPU )
setup /boot/loader.conf and /etc/rc.conf and /etc/X11/xorg.conf
start Xorg - TWM
build/install GNOME
start Xorg - GNOME

build/install KDE6/PLASMA6
start Xorg - KDE6

Build/install MATE + Libreoffice , any other things to play with ,
Click to expand...

Looks fine to me!

I'd want the GUI as soon as possible so I'd install Xorg, then directly build or install the DE.
  • Xorg
  • Graphics driver (with Intel it's just drm-515-kmod install)
  • DE (I use pkg Xfce but not sure about building it)
loader/rc/xorg confs get edited from within the DE (nice to know the DE/graphics work before tweaking stuff :p), then other apps/games get set-up (I'd do RL9 Linux before stuff like LibreOffice).

Things more-complex to set-up I'd like to do early to make sure they can be set-up (if something fails and I did something early in the set-up, I can nuke and reinstall with less concern vs trying to preserve a large set-up with everything already installed). If I have to track down a change after a large set-up, the change might affect something else previously set-up, so I'd rather complex stuff be tuned on a fresh install as soon as possible, and less-important stuff configured around the larger stuff's config (like Xorg and DDX; if I set-up modesetting at 74Hz with games initially and later find Intel DDX better at 73Hz, I'd have to go through every game and Xfce's conf again to reset monitor confs/window positions).
 
I tend to use Intel hardware with integrated GPU (amd64). The main installation is the same for server and workstation, never compiled FreeBSD from source (only once many years ago to try it out).
  • Install from USB stick, with SRC no PORTS
  • Copy my system install sh script in root home and run it. The script create a directory in /usr/local/SYSENV (call SYSENV whatever you want). The SYSENV directory tree is as follow:
    Code: 
    /usr/local/SYSENV
       |-- bin
       |-- etc
       |-- include
       |-- lib
       |-- man
       --- share
    The script modify /etc/csh.login and source my tcsh global config located in /usr/local/SYSENV/etc/shells/common.tcshrc do the same for sh shell creating a symlink of file /usr/local/SYSENV/etc/shells/common.shrc in /etc/profile.d.
    The script also initialize pkg (bootstrap) and set the package repository to latest, install git from packages, create the /usr/ports directory and initialize the ports tree with git.
    Many other things happens in the script but give me a full base configured system.
  • Install misc/mc
From there servers and workstations are diffrent. All needed installed from ports
 
You must log in or register to reply here.
Back
Top