Penguin Pages

Penguin Pages is built as a plain static website with separate HTML, CSS, and JavaScript files. The goal is to keep it readable, fast, easy to host, and easy to edit without needing a build system.

The design follows an old Linux documentation mirror style: simple boxes, small text, practical links, and direct reference material.

• Keep the site lightweight and static.
• Use real project links and official documentation where possible.
• Keep tabs organized by Linux topic.
• Keep the style consistent with early Linux reference pages.
• Avoid unnecessary frameworks, tracking, and heavy page effects.

Start with the boot parameters and virtual filesystems, then move to modules and logs. Most kernel troubleshooting begins with dmesg, /proc/cmdline, loaded modules, and the exact hardware or filesystem involved.

• docs.kernel.org - current rendered kernel documentation.
• kernel.org documentation index - documentation mirrored from kernel source.
• git.kernel.org - official kernel git browser.
• Bootlin Elixir - searchable Linux source browser.

# list loaded modules
lsmod

# inspect a module
modinfo i915

# load and unload manually
sudo modprobe loop
sudo modprobe -r loop

# show kernel ring buffer
sudo dmesg -T
                

# clone mainline from kernel.org
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux

# or clone the GitHub mirror
git clone https://github.com/torvalds/linux.git
cd linux

# check current version
make kernelversion
                

# start from the running distro kernel config
cp /boot/config-$(uname -r) .config

# update config for the new tree
make olddefconfig

# optional terminal config menu
make menuconfig

# build kernel and modules
make -j$(nproc)

# install modules and kernel
sudo make modules_install
sudo make install
                

Many distributions handle bootloader updates differently. Keep an older working kernel in your boot menu.

# apply a patch
patch -p1 < ../some-kernel.patch

# inspect changes
git diff

# build after patching
make olddefconfig
make -j$(nproc)
                

For serious kernel work, use git branches, keep patches small, and read the kernel development process documentation.

Work in order. Check firmware entries, bootloader config, kernel files, initramfs contents, root filesystem UUIDs, and service logs. Random reinstalling usually hides the real problem.

# from a live USB, adjust partitions first
sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

# example GRUB EFI reinstall
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Linux
grub-mkconfig -o /boot/grub/grub.cfg
                

Before editing config files, collect basic facts: what changed, which service failed, which log mentions it, which package owns the file, and whether the problem happens for a fresh user account.

Prefer commands that show state before commands that change state. Read with lsblk , findmnt , ip , ss , journalctl , and systemctl status before editing files or restarting services.

Use a source browser first, then clone the tree later. Follow one subsystem at a time. For example, a filesystem path usually touches fs/ , headers in include/ , and shared code in kernel/ or mm/ .

# configure
make menuconfig

# build with all cores
make -j$(nproc)

# install modules and kernel
sudo make modules_install
sudo make install

# update bootloader if your distro does not do it automatically
sudo grub-mkconfig -o /boot/grub/grub.cfg
                

First identify the GPU, kernel driver, session type, and userspace graphics libraries. Most desktop issues make more sense after checking whether the session is X11 or Wayland and whether hardware acceleration is active.

Choose a desktop environment when you want a complete session with panels, settings, file manager integration, portals, notifications, and login polish. Choose a window manager when you want a smaller, keyboard-focused setup and are willing to assemble more pieces yourself.

For a normal install, ext4 is the quiet dependable choice. Btrfs is useful for snapshots and compression. XFS is strong for large files and server workloads. ZFS is excellent when storage integrity and pools matter more than being built into the mainline kernel.

Service management is mostly dependency order, supervision, logging, and failure handling. Learn how your init system starts services, where it stores service definitions, and how to inspect logs for the current boot.

systemctl status sshd
journalctl -u sshd -b
rc-service sshd status
sv status /var/service/*
s6-rc -a list
dinitctl list
                

Patch regularly, expose fewer services, use SSH keys, limit sudo access, check listening ports, and know where authentication logs are stored. Security starts with fewer surprises.

Start at the bottom. Confirm the card exists with ALSA, then check the desktop sound server, then check the session manager and selected output device. Many audio problems are routing problems, not driver problems.

aplay -l
alsamixer
pactl info
wpctl status
pw-top
systemctl --user status pipewire wireplumber pipewire-pulse
                

Use a container when you want isolated userspace on the same kernel. Use a virtual machine when you need a separate kernel, stronger machine boundaries, firmware testing, or another operating system entirely.

sudo chroot /mnt
machinectl list
podman ps
docker ps
lxc-ls --fancy
virsh list --all
qemu-system-x86_64 --version
                

Observe, isolate, test, document. Avoid changing five things at once. A fix you cannot explain is hard to trust and harder to repeat.

This glossary is for quick orientation while reading the rest of the site. It keeps definitions short so you can get back to the command output, manual page, or source file you were looking at.

Pick a distro based on hardware support, package freshness, release model, documentation, driver needs, and how much maintenance you want. The best distro is the one whose tradeoffs match the machine and the job.

This page favors official documentation, source browsers, manuals, and long-lived project sites. Forum posts and random scripts can be useful, but primary docs should be checked first.