Lab: prepare and patch a disposable Linux machine

Before you begin

Complete the four preceding bites first. You need a Mac with OrbStack installed, network access to download the distribution and packages, and space for a small learning machine and a recovery copy. Run one track at a time on the 16 GB host. This guide has not been executed against your OrbStack installation.

Establish the baseline

1. Create sk-foundations with the documented Ubuntu Noble command, if you have not already done so.
2. Record Mac/OrbStack version, machine identity, userspace release, CPU architecture, running kernel, and init system.
3. Inside the Linux home directory create study-baseline.txt with one non-secret observation.
4. Exit to the Mac, stop the machine, and check that the proposed backup name is unused. Clone it using orb clone sk-foundations sk-foundations-before-patch. Check orb clone --help first if the installed release differs.
5. Start only the original and follow the patch bite's preview and interactive upgrade sequence.

Stopping before the copy gives this simple file fixture a clear boundary. A clone is a convenient local recovery copy, not an off-host backup. OrbStack also documents export/import for backup and transfer; verify restoration before relying on it for valuable data.

Keep a before/after comparison you can read

Before stopping the original for its recovery copy, inside its Linux home run:

printf 'Pre-patch learning fixture\n' > ~/study-baseline.txt
dpkg-query -W -f='${Package} ${Version}\n' bash coreutils > ~/study-packages-before.txt
cat ~/study-baseline.txt
cat ~/study-packages-before.txt

Use these course-specific filenames only if they are unused, or inspect and choose new names first. The inventory is a text record; it is not itself a package backup. After the upgrade, compare the new dpkg-query output with that record. Your answer may be “these two packages did not change while other packages did” or “no upgrades were proposed.” Read the actual transaction instead of requiring a predetermined version difference.

When checking the clone, expect it to contain the baseline file and saved inventory from before the change. Verify those exact contents. A clone merely appearing in orb list does not demonstrate that its files are recoverable.

Compare and recover

After patching, record package versions, the APT transaction, service state, and remaining actions. Stop the original and start the backup copy. Verify the baseline file and pre-change package inventory there. This tests access to a known copy without claiming that an in-place package downgrade works.

Stop the backup when finished. Keep sk-foundations for the remaining modules. Remove the backup only after deciding that the maintenance result and evidence are sufficient; verify its exact name before deletion. Never remove all OrbStack data for this exercise.

Checkpoint and revision

• What is shared between OrbStack machines, and what is specific to each userspace?
• Which package versions actually changed? If none changed, why is that valid evidence?
• Which recovery action did you test, and what data consistency does it establish?
• Why does this not replace a full-VM bootloader or kernel-update lab?

Expected reasoning: the clone preserves the simple stopped-machine fixture, while the underlying kernel remains an OrbStack-managed shared component. Record differences from the expectation rather than inventing a successful patch.

Handy revision: identify, stop/copy, preview, patch, verify, rehearse recovery, retire only the copy.

Continue to Cloud concepts — public, private, and hybrid. Keep the Linux machine for the filesystem and permissions module that follows.

Sources

Primary references: OrbStack cloning and exports↗; APT reference↗.