Linux Installation and Package Management

Let’s start at the very beginning. When you install Linux, you are essentially copying a set of files from an installation medium (like a USB stick or a DVD) onto your computer’s hard drive. But you cannot just dump everything in one big pile. Hard drives are divided into sections called partitions. Think of a partition like a room in a house: the ‘root’ partition (‘/’) is the main living room where the operating system lives, ‘/home’ is a bedroom for user files, and ‘swap’ is like a utility closet used as overflow memory. Partitioning is crucial because if one partition fills up (say, with personal documents), it won’t crash the entire system — it just affects that room.

Now, once Linux is installed, you will need to install more software. On Linux, software is distributed in packages. A package is a compressed archive that contains the program files, configuration files, and a manifest (a list of what’s inside). There are two major package formats you must know for LPIC-1: .deb (used by Debian and Ubuntu) and .rpm (used by Red Hat, Fedora, and CentOS). Each format needs its own package manager to handle installation, updates, and removal.

Package managers solve a huge headache: dependency resolution. A dependency is a piece of software that another program needs to run. For example, a web browser might depend on a library called libfoo. When you install the browser, the package manager automatically finds and installs libfoo too. Without a package manager, you would have to track down libfoo yourself, install it, and hope it doesn’t depend on something else — this was famously called ‘dependency hell’.

For Debian-based systems, the primary package manager is apt (Advanced Package Tool). You use commands like: - apt update to refresh the list of available packages from online repositories (software sources). - apt install <package-name> to install a package. - apt remove <package-name> to uninstall. - dpkg -i <file.deb> to install a .deb file manually.

For Red Hat-based systems, you use dnf (or yum on older versions). Commands include: - dnf check-update to see what can be updated. - dnf install <package-name> to install. - dnf remove <package-name> to remove. - rpm -ivh <file.rpm> to install an .rpm file manually.

Both package managers rely on repositories — centralised servers that hold thousands of packages. When you run apt update, your system downloads a list of what’s available in those repositories. This replaces the old, painful method of downloading software from websites manually and hoping it works.

Why does this replace older methods? Before package managers, installing software on Linux meant compiling from source code. You would download the source code of a program, run a compiler (a program that turns human-readable code into machine instructions), and then handle dependencies yourself. It was slow, error-prone, and required deep knowledge. Package managers automate this process, making installation as simple as a single command.

In summary: installation is about setting up the foundation (partitioning) and then adding software in a structured, safe way using package managers. The exam tests your ability to understand these processes, the commands, and the differences between Debian and Red Hat package management.

Imagine you are a junior systems administrator at a small e-commerce company. The company runs its website on a Debian-based Linux server. One day, the development team says they need a new version of PHP (a programming language) to support a new feature. Here’s what you actually do:

First, you log into the server via SSH (a secure remote connection). You check what version of PHP is currently installed using dpkg -l | grep php. You see it’s version 7.4, but you need version 8.0. Before installation, you must make sure the correct repository is available. Debian’s default repositories might not have PHP 8.0, so you add a third-party repository (a specific server maintained by the PHP team). You do this by editing the file /etc/apt/sources.list or adding a new file in /etc/apt/sources.list.d/. Then you run apt update to fetch the latest package lists.

Now you install PHP 8.0 using apt install php8.0. The package manager automatically picks up dependencies — it installs new libraries and modules PHP needs. But here’s a real-world trap: the old PHP 7.4 might still be present, causing conflicts. You might need to purge the old version with apt purge php7.4. You then restart the web server (like Apache or Nginx) for the changes to take effect.

Next, imagine you need to install a proprietary tool that only comes as an .rpm file, but your server is Debian-based. You cannot use apt for that. You must use a tool called alien to convert the .rpm to a .deb, or you install the .rpm manually with rpm -ivh (though this can cause dependency issues). In practice, you search for a .deb version first.

Finally, you test the new PHP by running a simple script to ensure it works. You document the changes in a change log for your team. This whole process — from identifying the need to testing — takes about 15 minutes, but if you hadn’t understood package management, you could have broken the server for hours.

Key tools used in this scenario: - apt and dpkg for Debian systems. - yum and rpm for Red Hat systems. - repositories, both official and third-party. - commands like apt list --upgradable to check for updates.

The lesson: real-world package management is about solving problems quickly without breaking production systems. You repair broken packages with dpkg --configure -a, you pin package versions to prevent unwanted upgrades, and you use virtual packages when dependencies are missing.