LPI BSD Specialist common mistakes
LPI BSD Specialist · Understand the traps and how to avoid them.
On a FreeBSD install, the candidate selects Auto (UFS) partitioning and then cannot answer questions about swap size, /var sizing, or separate /tmp, because they never opened the manual partition editor.
The installer's guided path hides the partition editor, so candidates who have only practised the default flow have no mental model of slices versus partitions, or of where swap and /var live. The exam asks about layout decisions that only appear in manual mode.
What to do instead
Practise the full manual path in a VM: create a GPT scheme, add a freebsd-boot partition, a swap partition, and separate UFS partitions for /, /var, /tmp, and /usr. Then repeat with ZFS and note where the pool root is mounted and how swap is created as a zvol or file. Be able to state the trade-off: separate /var and /tmp limit damage from log growth and world-writable files.
The candidate runs pkg install on a system where pkg has never been bootstrapped, or mixes pkg with a ports tree built against different options, and then treats the resulting library mismatch as a package bug.
FreeBSD ships without the pkg manager binary on minimal installs; the first pkg invocation must fetch and install it. Candidates also assume ports and packages are interchangeable, when a port built with non-default options can conflict with the packaged dependency set.
What to do instead
Know the sequence: run pkg bootstrap (or let the first pkg command prompt for it), then pkg update, then pkg install. Know that pkg upgrade -y updates installed packages and that pkg audit -F checks for known vulnerabilities. For ports, use portsnap fetch extract or git on /usr/ports, and remember that mixing requires care; prefer one method per system.
The candidate edits /etc/rc.conf to start a service and then also runs the service's start script directly, or edits the vendor default file instead of the local override.
BSD init is not systemd; there are no unit files and no systemctl enable. Candidates coming from Linux expect an enable step separate from configuration, and they do not know that /etc/defaults/rc.conf holds defaults that must not be edited.
What to do instead
Learn the rule: settings go in /etc/rc.conf (or /etc/rc.conf.d/), never in /etc/defaults/rc.conf. Enable a daemon with a line such as sshd_enable="YES", then apply it with service sshd start or /etc/rc.d/sshd start. Use sysrc sshd_enable=YES to edit safely. Check with service -e to list enabled scripts.
The candidate creates a filesystem with newfs on a whole disk device such as /dev/ada1 instead of on a partition, or forgets to add the new entry to /etc/fstab and wonders why the mount disappears after reboot.
BSD disk naming (ada, da, nda, vtbd) plus slice and partition suffixes (s1, s1a, p2) is unfamiliar, and the habit of formatting whole devices carries over from other systems. Also, mount succeeds at runtime without fstab, so the omission is invisible until reboot.
What to do instead
Always confirm the target with gpart show before writing. For MBR use /dev/ada0s1a; for GPT use /dev/ada0p2 or a label such as /dev/gpt/data. After newfs, mount it, then add a line to /etc/fstab using the label or UUID, and test with mount -a and a reboot. Verify with df -h and tunefs -p for the filesystem parameters.
The candidate answers questions about disk labels, GEOM, or ZFS by guessing Linux equivalents (LVM, mdadm, ext4 tools) rather than using BSD terms and commands.
Most study material online is Linux-centric, so candidates map concepts onto LVM volume groups or mdadm arrays and then pick answers that name those tools. BSD storage is built on GEOM providers, gpart, glabel, gmirror, gstripe, and ZFS pools.
What to do instead
Build a small vocabulary card set: GEOM provider and consumer, gpart schemes (GPT, MBR), glabel for persistent names, gmirror and graid for redundancy, gstripe for striping, and zpool/zfs for the ZFS stack. Practise creating a gmirror on two disks and a zpool with a mirror vdev, and note the commands to check status (gmirror status, zpool status).
The candidate configures a static IP by editing /etc/resolv.conf only, or sets the address in rc.conf but never sets the default router, then reports that the network is broken because DNS fails or external hosts are unreachable.
Name resolution and routing are separate concerns, and rc.conf needs several coordinated variables. Candidates also forget that resolv.conf is often regenerated by dhclient or by a local resolver, so manual edits vanish.
What to do instead
Learn the trio: ifconfig_em0="inet 192.0.2.10/24" for the address, defaultrouter="192.0.2.1" for the gateway, and nameserver lines in /etc/resolv.conf. Apply with service netif restart and service routing restart, or reboot. Verify with ifconfig, netstat -rn, and ping to both the gateway and an external address before testing names.
The candidate edits /etc/ssh/sshd_config or /etc/hosts.allow and then tests without reloading the daemon, or tests from the same host and concludes the change worked.
BSD daemons read configuration at start; there is no automatic reload. Testing locally bypasses the very filters being changed, and hosts.allow versus hosts.deny precedence is easy to get backwards.
What to do instead
After editing, run service sshd reload (or restart) and check with sockstat -4 -l that the listener is present. Test from a second host or a second session before closing the first. For TCP wrappers, remember the first matching rule in hosts.allow wins, then hosts.deny, then the default; keep an allow rule for your own management address at the top.
The candidate uses Linux-style flags out of habit, such as ps aux, ls --color, sed -i without a suffix, or tar with GNU long options, and then marks the correct BSD behaviour as a distractor.
Muscle memory from Linux and GNU coreutils is strong, and BSD userland derives from different traditions. Some flags collide rather than merely being absent, which makes the wrong answer look plausible.
What to do instead
Drill the differences that appear on exams: ps aux works on FreeBSD but ps -ef is the portable form; sed -i requires a backup suffix on BSD (sed -i '' ...); ls --color is not standard, use LSCOLORS or CLICOLOR; tar uses bundled flags (tar -xzf) and bsdtar reads most formats; grep -r exists but find | xargs is the traditional idiom. Check man pages on a BSD VM rather than trusting memory.
The candidate assumes user accounts, groups, and password databases follow the Linux layout, editing /etc/shadow or expecting useradd with the same defaults.
BSD keeps hashed passwords in /etc/master.passwd and generates /etc/passwd and the .db files from it with pwd_mkdb. Tools like vipw and adduser behave differently, and hand-editing the wrong file silently breaks logins.
What to do instead
Use adduser for interactive creation or pw useradd for scripting, and pw groupmod to manage groups. If editing by hand, use vipw (which locks and rebuilds the databases) rather than a plain editor on /etc/master.passwd. Verify with getent passwd and by logging in. Remember that /etc/passwd is generated and should not be the source of truth.
The candidate is asked about boot behaviour or kernel modules and answers from Linux assumptions, naming grub or modprobe instead of the BSD loader and kldload.
The FreeBSD boot chain (boot0/boot1, loader, kernel) and the module system (kldload, kldstat, /boot/loader.conf) are distinct from GRUB and initramfs, and candidates who have never watched a verbose boot have no concrete model.
What to do instead
Walk the chain once in a VM: read /boot/defaults/loader.conf, add a module with kldload if_tap, list it with kldstat, and make it persistent with a line in /boot/loader.conf. Know that /etc/rc.conf controls services after boot while loader.conf controls kernel and module loading before it. Practise booting with the loader prompt and loading a kernel by name.