Lesson 5: Cross-Platform Technician Practical

Core path: 42 minutes

A real support queue does not tell you which operating-system objective applies.

You identify the platform, preserve the evidence, choose the platform-appropriate tool, and make the smallest justified correction.

Ticket A: unsupported OS

Evidence:

• endpoint still boots normally;
• vendor support has ended;
• current security/application updates are no longer available;
• one legacy application still requires the old environment.

Document the EOL risk and compare migration, replacement, or bounded virtualization/compatibility options. "It still works" does not close the support problem.

Ticket B: removable drive compatibility

Evidence:

• drive is healthy;
• one OS can read/write it;
• another endpoint cannot use the current filesystem as required;
• no hardware failure evidence exists.

Identify the filesystem/compatibility boundary before replacing the drive.

Ticket C: macOS application problem

Evidence:

• approved application arrives as a .pkg;
• device is organization-managed;
• current user cannot complete installation;
• MDM/corporate policy controls software deployment.

Follow the approved deployment path rather than bypassing management restrictions.

Ticket D: macOS storage issue

Evidence:

• Disk Utility detects an external disk;
• Finder does not show a mounted usable volume;
• important data may exist on the disk.

Preserve data. Investigate the volume/filesystem state before erase/initialization.

Ticket E: Linux name-resolution issue

Evidence:

• ip shows valid addressing;
• ping to a documentation IP succeeds;
• dig against the configured resolver fails;
• /etc/resolv.conf shows the wrong resolver in the supplied scenario.

Keep the diagnosis at the resolver/configuration boundary.

Ticket F: Linux permissions

Evidence:

• file exists;
• storage is healthy;
• user lacks required access under current ownership/permission state.

Use ls, chmod, chown, and group/ownership reasoning conceptually. Do not solve the problem with blanket world-writable permissions.

Ticket G: Linux disk-full symptom

Evidence:

df: root filesystem 98% used
du: one log/cache directory accounts for most growth

The next step is controlled space investigation/cleanup, not reinstalling the application blindly.

Ticket H: application requirement mismatch

Evidence:

• application requires 64-bit OS, 16 GB RAM, dedicated GPU, and 4 GB VRAM;
• endpoint has 8 GB RAM and integrated graphics only.

Record every failed requirement. An installer error is not the root architecture problem.

Ticket I: cloud productivity license

Evidence:

• user identity synchronizes successfully;
• sign-in succeeds;
• application/service reports no entitlement;
• required license is unassigned.

Stay at licensing assignment scope.

Ticket J: collaboration application

Evidence:

• videoconference service is reachable;
• camera works in another application;
• target app has camera permission disabled.

Use application/privacy evidence rather than replacing the camera.

Final practical record

Complete five tickets across at least three OS/platform families:

platform:
filesystem/application/service involved:
user-visible symptom:
last proven-good boundary:
platform-appropriate tool or evidence:
strongest theory:
data/policy risk:
controlled correction or escalation:
verification:
remaining uncertainty:

Core 2 Operating Systems checkpoint

Weeks 11–12 should now let you explain and support:

OS family + lifecycle
→ Windows installation/editions/tools/settings/networking
→ macOS features/tools
→ Linux commands/configuration/components
→ filesystem compatibility
→ application requirements/distribution/impact
→ cloud productivity identity/licensing/synchronization
→ verify + document

The next repair block is security. We do not move forward until Weeks 13–15 are repaired against their exact objective sets.

Robotnix service-diagnosis simulation
Everything here is local simulated state. Type 'help' for the evidence path.

$ systemctl --user status sensor-api
● sensor-api.service - Sensor API
   Active: failed
   Result: exit-code

$ journalctl --user -u sensor-api
sensor-api[511]: config error: PORT must be a number
systemd[1000]: sensor-api.service: Main process exited, status=1/FAILURE

$ cat service.env
PORT=abc

$ cp service.env.fixed service.env
Copied known-good bounded configuration.

$ systemctl --user restart sensor-api
sensor-api restarted.