Planning an installation¶

Practical 2.3 planning-an-installation-annex.pdf · PDF

On Your first VM with virt-manager every number was given to you: 2 CPUs, 4096 MiB, 10 GiB. Who says those were the right ones?

Next week you install three operating systems. Before you click a single "Next", you will decide every number yourself — and prove it with the manufacturer's own documentation. A technician who installs first and reads later ends up in the story below.

The check nobody did¶

Windows 11 was released on 5 October 2021. For the first time, Windows refused to install on PCs that were perfectly fast: it asked for a small security chip called TPM 2.0 and a list of recent CPUs. Four years later, on 14 October 2025, Microsoft ended support for Windows 10. Offices found out that week that part of their PCs could not move to Windows 11.

The information had been public for four years, on one web page. Nobody had read it.

If you had been the technician of an office with 40 PCs in 2021, what should you have done? An inventory, and a check of every PC against the requirements. That is a plan.

The seven questions of a plan¶

Every installation plan answers the same seven questions. They are the sections of the Practical sheet:

Requirements: minimum is not enough¶

The minimum requirements are the least hardware with which the system starts. The recommended requirements are what you need to work comfortably.

A plan uses the recommended figures unless there is a reason not to.

The figures come from the official documentation — not a blog, not a forum, not an AI answer. In Practical 2.3 you find them yourself, in pairs, starting from these pages:

For each system you write down the CPU and architecture, minimum and recommended RAM, disk, firmware and any special hardware — plus the address of the page and the date you read it. Requirements change between versions.

Two traps waiting in those pages:

• Debian's table has two rows, No desktop and With desktop. deb-lab has a desktop. A careless reader copies the wrong row.
• A documentation page may say which release its figures were measured on, and warn that other releases differ slightly. That is honest documentation, not a mistake — which is exactly why you write down the date.

Will it fit? Architecture, firmware, drivers¶

Architecture¶

The Debian and Ubuntu ISO names end in amd64. That is the 64-bit instruction set of Intel and AMD PCs. AMD designed it — hence the name — but Intel CPUs use it too. Linux also calls it x86_64: two names, same thing.

A phone or a recent Mac uses arm64: a different language for the CPU. An amd64 system does not start on an arm64 CPU, and the other way round. This is the first line of any plan.

The architecture is the instruction set — the language — a CPU understands. A system built for one architecture does not run on another.

Firmware and partition table¶

From The boot process:

Windows 11 demands UEFI. In virt-manager the firmware is a choice in the VM's settings, made before installing and not changed later. The course plan: the two Linux VMs (deb-lab, ubu-srv) use virt-manager's default, BIOS; win11 uses UEFI. You will see both.

Drivers¶

A requirement nobody writes: does the system have a driver for this Wi-Fi card, this graphics card? On a real PC, a live image is the cheapest test: boot it and see if the Wi-Fi works. In a VM the hardware is virtual and well known — with one exception you will meet when you install Windows 11.

Installation media in one breath¶

The next page goes deeper: how to check the file you downloaded and put it on a USB stick.

What can my host lend?¶

Every VM borrows from the host. In this course the host is the class server, so that is what you measure. Open a terminal on your PC (Ctrl+Alt+T) and log in to it with the user and password from your slip:

ssh <user>@<server>                     # the prompt changes to <user>@si
nproc                                   # CPU threads of the host
free -h                                 # RAM: columns "total" and "available"
df -h ~/.local/share/libvirt/images     # free space where your VM disks live: column "Avail"
uname -m                                # architecture: x86_64 is the same as amd64
exit                                    # back to your PC

Then do the sum on paper. The three VMs of the course ask for:

• All three at once? On a single PC with 16 GB of RAM: yes, 10 for the guests and 6 for the host. With 8 GB: no — one at a time, or deb-lab plus ubu-srv. The host needs RAM for itself too.
• And on the class server? It has dozens of threads and tens of GiB of RAM, but it is the host of the whole class: multiply your 10 GB by the number of students. That is why the rule in class is shut down the VMs you are not using — the server is shared.
• Do you need 109 GB free today? No: qcow2 disks grow as the guest writes. But the plan must say what happens if they all fill up.

Cutting the disk: the partition plan¶

A partition is a piece of a disk that the system treats as a separate disk.

Back in the kitchen: one big pantry, or shelves with labels? With shelves, if the "user files" shelf overflows, it does not bury the "system" shelf.

The course's decision for a first install: everything in one partition plus swap — the installer's guided option. Separate /home, sizes, file systems and LVM come in Unit 4. But the plan still has to say so: "guided, whole disk, one partition" is a decision, written down.

Here is what the two plans look like:

flowchart LR
    subgraph DEB ["deb-lab · 25 GB · BIOS"]
        direction LR
        D1["<b>/</b> (root)<br>almost all the disk"] --- D2["<b>swap</b><br>small, at the end"]
    end
    subgraph WIN ["win11 · 64 GB · UEFI"]
        direction LR
        W1["<b>EFI System<br>Partition</b><br>small, first"] --- W2["<b>C:</b><br>the rest"]
    end

Windows also creates two small partitions of its own (a reserved one and a recovery one). You will see them in Unit 4.

The plan¶

The last part of Practical 2.3 is the plan table for the three VMs. Some answers are fixed by the course:

• VM names: deb-lab, ubu-srv, win11
• User: student, with the lab password your teacher gives
• Network: virbr0 (NAT) — in the wizard, Bridge device... with device name virbr0
• After the install: update, then take a snapshot called clean

The rest comes from your own research and measurements:

For the ISO row, write the exact file name. The ISOs are on the server, not on your PC: log in with ssh and ls /srv/isos shows them. The test of a good plan: a classmate could build the three VMs from your table without asking you anything.

Type it as practical-2.3-surname.md with the lab report template and keep the paper sheet: you install from it next week.

Key takeaways¶

• An installation plan answers seven questions: what, where, from what, how to cut the disk, what is already there, who, and after.
• Minimum = it starts; recommended = you can work. Figures come from the official documentation, with the page and the date read.
• First line of any plan: the architecture. amd64 (= x86_64) does not run on arm64.
• BIOS goes with MBR; UEFI with GPT and an EFI System Partition. Windows 11 needs UEFI; the course's Linux VMs use BIOS.
• Measure the host — the class server, over ssh — with nproc, free -h, df -h, uname -m. RAM is the limit; vCPUs are shared turns.
• A simple partition plan: / (root) plus swap, and an EFI System Partition only with UEFI.

Quick check¶

Next: your plan names an ISO file. How do you know the file you downloaded is the real one? Verify an ISO and make boot media.