A reproducible Linux setup needs a named target. This walkthrough targets Ubuntu 26.04 LTS, not every Linux distribution. It records the packages, selected user configuration, manual decisions, bootstrap order, and verification needed for one course environment.
The repository will not recreate hardware, firmware, disk layout, encrypted data, online accounts, or every historical application. It should restore required capability on the named target and explain its limits.
Define the exact target
Record:
Target: Ubuntu Desktop 26.04 LTS
Architecture:
Device ownership and management:
Courses and required projects:
Required deb packages:
Required snaps or other application systems:
Language-project dependency files:
Selected user configuration:
Files and settings intentionally excluded:
Verification outcomes:
Canonical’s Ubuntu 26.04 LTS release notes identify the release and its support window. A future Ubuntu release, flavor, minimal image, server install, Debian system, or Fedora system is a different target and may need different package names, defaults, services, and configuration.
Create a small source repository
ubuntu-student-setup/
├── README.md
├── packages/
│ ├── apt-manual.txt
│ └── snap-list.txt
├── config/
│ ├── gitconfig.example
│ └── bashrc.course
├── scripts/
│ ├── bootstrap.sh
│ └── verify.sh
└── docs/
├── manual-steps.md
└── recovery-plan.md
Create only artifacts the setup needs. The README should state the Ubuntu release, prerequisites, expected elevation, operation order, package sources, configuration destinations, secret boundaries, verification, rollback, and known omissions.
Do not copy your complete home directory. Dotfiles can contain tokens, command history, private hosts, usernames, paths, and application state.
Curate the APT package list
On the target system:
apt-mark showmanual
Ubuntu’s
apt-mark manual
defines showmanual as the list of packages marked manually installed. This is
an inventory input, not a ready bootstrap manifest. It can include packages
installed by the base image, installer, hardware enablement, or old experiments.
For each retained entry, record:
Package:
Purpose:
Course or project:
Required or optional:
Repository expected:
Verification:
Remove unexplained entries from the target manifest, not from the current computer. Do not pin exact package build versions unless a real course constraint requires it. Ubuntu’s repositories normally choose compatible versions for the target release; historical builds may no longer be available.
APT and Snap are separate inventories. If Snap is installed:
snap list
Snap’s official
snap list documentation
explains version, revision, publisher, and tracking-channel fields. Curate
application snaps and record the channel when it materially affects behavior.
Do not assume snap list captures application data or account access.
Record Flatpak, language-project dependencies, editor extensions, and manually installed software separately, using their own documented inventories. Do not merge them into fake APT package names.
Preserve selected configuration
Prefer small, explained fragments over a framework dump:
- a Git configuration example with identity placeholders;
- a course-specific Bash fragment;
- editor settings needed for the course;
- project dependency and lockfiles in their projects; and
- manual instructions for settings that should not be automated.
For every file, document:
Source path:
Destination path:
Purpose:
Managed by package or user:
Secret review completed:
Merge or replace:
Verification:
Use .example files for private values. Keep SSH private keys, tokens,
passwords, recovery keys, browser profiles, cloud credentials, and institutional
configuration out of Git. Back up necessary secrets through an approved,
separate recovery method.
Write inspectable bootstrap steps
bootstrap.sh should be a readable sequence, not a remote script piped into a
shell. Begin with stop checks:
#!/usr/bin/env bash
set -u
# 1. Verify Ubuntu 26.04 LTS and expected architecture.
# 2. Stop on a managed device without authorization.
# 3. Show the curated package list.
# 4. Ask the user to inspect the APT transaction.
# 5. Place or merge each reviewed configuration deliberately.
# 6. Run read-only verification.
Do not implement installation from the uncurated apt-mark output. Do not add
repositories, import signing keys, overwrite dotfiles, or use unattended
confirmation without an explicit reviewed requirement.
Make repeated runs understandable. A second run should report satisfied checks or propose the same bounded changes, not append duplicate shell configuration.
Make verification read-only
verify.sh should inspect outcomes:
Ubuntu release and architecture match
Required commands resolve from expected paths
Git, compiler, runtime, and build-tool versions meet course constraints
Selected configuration fragments are present once
Practice repository builds or tests
No secret value is printed
Test scripts with a syntax checker before execution:
bash -n scripts/bootstrap.sh
bash -n scripts/verify.sh
Then rehearse against a disposable Ubuntu 26.04 LTS virtual machine or other authorized spare environment when possible. A container can test some package and shell logic, but it does not reproduce desktop applications, systemd, hardware, login sessions, or boot behavior.
Produce a reproducibility result
## Ubuntu 26.04 setup rehearsal
- Test environment:
- Manifest commit:
- Packages proposed:
- Packages deliberately omitted:
- Configuration applied:
- Manual steps completed:
- Verification passed:
- Verification failed:
- Secrets excluded:
- Target-specific limitation:
- Next correction:
Correct the source repository when the rehearsal exposes a missing prerequisite. Do not patch only the test machine and call the documentation reproducible.
Common mistakes
- Claiming one manifest reproduces all distributions.
- Exporting every manually marked package without curation.
- Treating package lists as file backup.
- Copying all dotfiles, history, and credentials.
- Mixing APT, Snap, Flatpak, and language packages without ownership.
- Piping an unreviewed network script into a shell.
- Overwriting existing configuration instead of inspecting and merging.
- Testing only on the original machine.
Do this now
First record the exact Ubuntu target and curate the required package manifest for one course. Verify the manifest before adding configuration. A secret-free configuration example, bootstrap stop checks, and a disposable rehearsal are later stages. Do not reinstall the computer.
Log what you learned
The Ubuntu setup repository and rehearsal result are the learning log. Add configuration, bootstrap, and rehearsal evidence only after each later stage runs.
Next, use these artifacts in a non-destructive Linux recovery rehearsal.