CliDeck
PlatformLog in
Workspace

Linux Console Capture Storage: Check Blocks and Inodes

Serial Console
#capture-space#operational-evidence#runbooks#remote-operations#Serial Console#serial-console
← Back to Blog

Short answer

Before a Linux console capture, check the filesystem containing the actual output directory with df, including both available blocks and inodes. Use du only to estimate an approved directory's current usage. Free space is a snapshot, not a guarantee that the next capture will complete.

Scope and prerequisites

The examples use GNU coreutils on Linux. The current GNU manual describes version 9.12; confirm the installed tools and options on your host. BusyBox, macOS and other implementations can differ.

The path ./captures is an illustrative existing output directory. Substitute the approved directory the capture process actually uses. These commands inspect storage; they do not delete files, change quotas, create directories or start a real serial session.

1. Identify the real capture destination

Check the capture tool's output setting and determine whether it writes additional files elsewhere. A shell working directory is not enough evidence when a service or application uses another path.

Resolve links, mounts and synchronization destinations with the owner. If the expected capture directory does not exist, stop and establish the approved location rather than checking a nearby directory and assuming the result applies.

Run the inspection in the same host or container context as the writer where appropriate. A workstation's free space says nothing about a capture produced on another machine.

2. Check available blocks

For the existing capture directory, run:

df -h -- ./captures

GNU df reports the filesystem containing the supplied path. Preserve the filesystem, mount location, available capacity and units. Its human-readable option uses powers of 1024; do not treat the abbreviated display as an exact byte measurement.

Record the capture time and compare available space with the expected capture duration and retention plan. Leave room for other authorized writers and normal system activity. A generous-looking value can become obsolete while another process writes to the same filesystem.

An error or inaccessible path is an incomplete check. Do not replace it with an unrelated filesystem result just to mark the preflight complete.

3. Check inodes separately

Run:

df -i -- ./captures

This view reports inode usage instead of block usage. Filesystem behavior varies, so preserve the returned fields and any unsupported or unavailable result.

A workload that creates many small files can require a different review from one large transcript. Keep the planned file pattern in the preflight notes. Passing the block-space check alone does not settle the inode question on filesystems where it matters.

4. Estimate the approved directory

If the existing directory is reasonably sized and inspection is authorized, run:

du -sh -- ./captures

This summarizes directory space usage rather than filesystem-wide availability. It can take time on a large tree and produce incomplete results when entries cannot be read. Preserve errors; do not suppress them and present a partial total as complete.

The two tools answer different questions, so their numbers need not match. Avoid turning that difference into a deletion plan. A cleanup operation requires the owner to identify the approved files and retention obligations separately.

If collection must continue for an extended period, schedule bounded rechecks in the runbook. A preflight does not verify sustained write performance, quota availability, remote storage health or eventual transcript integrity.

5. Close the capture with evidence

After the approved capture, confirm that the intended file exists, the tool reports completion and the transcript covers the expected interval. Repeat the storage checks when required by the retention plan. Do not claim success only because the session displayed commands.

For access review, see file and directory permissions. For an authorized handoff, use SHA-256 integrity checks.

Verification note: acceptance criteria

On the actual Linux host and writer context, verify the resolved destination, successful block and inode inspections, expected growth allowance and handling of inspection errors. Confirm the completed capture separately; missing options, quota uncertainty or unexplained write failures remain exceptions. These are verification criteria, not a claim of a real console capture or measured storage performance.

Who this is for

This guide is for network engineers, field technicians, remote hands, lab engineers, and system administrators who need to connect to, troubleshoot, log, or verify a serial console session on switches, routers, firewalls, appliances, servers, and other devices with console ports.

When to use this

Use this guide when:

  • You need direct console access to a switch, router, firewall, appliance, server, or lab device.
  • SSH or management-plane access is unavailable, unreliable, or not yet configured.
  • You need to troubleshoot a USB serial adapter, COM port, baud rate, or terminal session.

When not to use this

Do not use this guide when:

  • Do not use this guide as a substitute for vendor documentation, site policy, or a verified device-specific runbook when the operation is risky.
  • Do not continue if the console output suggests you are connected to the wrong device.

Quick checklist

  • Identify the device and console connector
  • Use the correct console cable or adapter
  • Find the correct serial port or COM port
  • Start with the expected baud rate and 8N1 settings
  • Press Enter to confirm the prompt
  • If output is unreadable, check baud rate and line settings
  • If the port will not open, check permissions, drivers, and whether another program is holding the port
  • Save useful session notes or logs when the work matters

Traditional cable vs CliDeck workflow

A traditional USB serial cable is still the simplest option for quick local work. CliDeck becomes useful when the console session needs browser access, notes, runbooks, sharing, logs, remote hands support, or a portable controller workflow.

Console Server Go can work like a wired USB serial adapter when connected by USB, but it also adds SSH Console on SSH-enabled firmware builds, browser Workspace, live sharing, 24h+ battery operation, OLED status, and magnetic rack mounting.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Identify the device, connector, cable, adapter, and host operating system.
  • Find the correct serial port or COM port and confirm permissions or drivers.
  • Open the session with the expected baud rate and line settings, usually 8N1 unless documented otherwise.
  • Press Enter and verify the prompt before running commands.
  • Save notes or logs when the session supports a change, recovery, handoff, or evidence workflow.

Verification checklist

  • The detected serial port or COM port matches the connected adapter.
  • Baud rate, data bits, parity, stop bits, and flow control match the device expectation.
  • The terminal shows a readable prompt after pressing Enter.
  • No other terminal application is holding the port.
  • Useful notes or logs are saved when the work matters.

Common mistakes

  • Using the wrong cable or adapter for the console connector.
  • Opening the wrong COM port or /dev/cu.* device.
  • Assuming unreadable output means hardware failure before checking baud rate and 8N1 settings.
  • Leaving another terminal application attached to the port.

CliDeck workflow fit

A traditional USB serial cable is still the simplest option for quick local work. CliDeck becomes useful when the console session needs browser access, notes, runbooks, sharing, logs, remote hands support, or a portable controller workflow.

Console Server Go can work like a wired USB serial adapter when connected by USB, but it also adds SSH Console on SSH-enabled firmware builds, browser Workspace, live sharing, 24h+ battery operation, OLED status, and magnetic rack mounting.

FAQ

Is a USB serial cable still enough?

Yes, for simple local work where one engineer is sitting next to one device. CliDeck is more useful when the console session needs sharing, runbooks, browser Workspace, remote hands support, logs, or longer operational context.

What should I check first when serial output looks like garbage?

Check the baud rate, data bits, parity, stop bits, flow control, cable type, and whether the device is actually using the expected console port.

Can CliDeck help with serial console work?

Yes. CliDeck Workspace helps organize terminal sessions, notes, runbooks, and logs. Console Server Go adds portable rack-side access, and Net Controller supports larger batch workflows.

Related guides