Steam Frame Stuck on Boot Logo — How I Fixed It via SSH (SteamOS / ext4)

My Steam Frame got stuck on the boot logo. SteamOS never reached its graphical interface, and rebooting didn't help.

Fortunately, the headset was still connecting to Wi-Fi and receiving an IP address. Since I had previously enabled SSH, I could log in remotely and investigate.

Here's exactly how I diagnosed and fixed the issue without a factory reset or reinstalling SteamOS.

Important: This guide covers a specific problem involving a corrupted ext4 filesystem on the /home partition. Not every Steam Frame boot failure has the same cause. Filesystem repairs can result in data loss. Back up important data before repairing whenever possible.

1. Connect to Steam Frame using SSH

From another computer on the same network:

ssh steamos@YOUR_STEAM_FRAME_IP

Replace the IP address with your headset's actual address. SSH must have been enabled and configured before the issue occurred.

2. Check the boot logs

journalctl -b -p err --no-pager -n 100

My logs contained:

fsck failed with exit status 4.
Failed to start File System Check on /dev/disk/by-partsets/shared/home.
sddm-helper: Failed to create session

Exit status 4 means filesystem errors were left uncorrected. The failure to check /home was preventing the normal startup of the graphical session.

3. Identify the /home partition

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS

On my 1 TB Steam Frame:

NAME      SIZE FSTYPE LABEL      MOUNTPOINTS
sda     952.3G
├─sda1    256M vfat   esp
├─sda2     64M vfat   efi-A
├─sda3     64M vfat   efi-B
├─sda4     10G btrfs
├─sda5     10G btrfs             /
├─sda6    256M ext4   var-A
├─sda7    256M ext4   var-B      /var
└─sda8  931.4G ext4   home

The affected partition was /dev/sda8.

You can confirm it using:

readlink -f /dev/disk/by-partsets/shared/home

Do not blindly copy the device name. Verify the correct partition on your own device.

4. Verify that /home is not mounted

findmnt /home
findmnt -S /dev/sda8

Both commands returned nothing in my case. The /home filesystem was not mounted.

This matters because you must not run a repairing e2fsck against a mounted filesystem.

5. Investigate the automatic fsck loop

I noticed that the fsck.ext4 process kept appearing with different process IDs.

ps -eo pid,ppid,stat,etime,args | grep '[f]sck'

Then I checked the systemd units:

systemctl list-units --all 'systemd-fsck*'

The relevant unit was:

systemd-fsck@dev-disk-by\x2dpartsets-shared-home.service

I inspected its journal:

journalctl -b \
  -u 'systemd-fsck@dev-disk-by\x2dpartsets-shared-home.service' \
  -n 60 --no-pager

The error was clear:

Directory inode 1436211, block #0, offset 0:
directory corrupted

UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)

fsck failed with exit status 4.

The automatic filesystem check could not repair this particular directory corruption, and systemd kept attempting to start it again.

6. Stop the automatic checker

Before starting a manual repair, I needed to prevent the automatic fsck service from accessing the partition.

sudo systemctl stop 'systemd-fsck@dev-disk-by\x2dpartsets-shared-home.service'

Then temporarily mask the service:

sudo systemctl mask --runtime 'systemd-fsck@dev-disk-by\x2dpartsets-shared-home.service'

The runtime mask is temporary and will not survive a reboot. If the unit cannot be stopped or masked, resolve that before proceeding.

Verify that no checker is accessing /dev/sda8:

findmnt -S /dev/sda8
sudo fuser -vm /dev/sda8
ps -eo pid,ppid,stat,args | grep '[f]sck'

There should be no filesystem mounted from /dev/sda8 and no fsck process using it.

7. Repair the ext4 filesystem

Warning: Repair can modify directory entries and other filesystem metadata. If the data is irreplaceable, consider making a disk image first. Check for storage I/O errors before attempting repair.

For example, inspect kernel messages:

sudo dmesg | grep -Ei 'I/O error|EXT4-fs error|sda.*reset|ufs' | tail -60

With /dev/sda8 confirmed unmounted and unused, I ran the interactive checker:

sudo e2fsck -f /dev/sda8

I deliberately did not use the automatic -y option, so I could review the proposed repairs.

First, several extent-tree optimization questions appeared:

Inode 1618257 extent tree (at level 1)
could be narrower. Optimize<y>?

I accepted these optimizations.

Then the checker reached the actual damaged directory:

Pass 2: Checking directory structure

Directory inode 1436211, block #0, offset 0:
directory corrupted

Salvage<y>?

I accepted the salvage operation. This allowed e2fsck to repair the corrupted directory structure.

Note: Salvaging a directory can discard invalid directory entries. Other repair prompts may have different consequences, so review them individually.

8. Run another verification pass

After the repair completed, I ran e2fsck again:

sudo e2fsck -f /dev/sda8

This time it finished cleanly:

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

home: 341980/11923200 files (0.6% non-contiguous),
43305945/244166139 blocks

No further filesystem inconsistencies were reported.

9. Restore normal SteamOS startup

If you masked the fsck service, unmask it:

sudo systemctl unmask 'systemd-fsck@dev-disk-by\x2dpartsets-shared-home.service'
sudo systemctl reset-failed

Mount /home:

sudo systemctl start home.mount
findmnt /home

Only after confirming that /home mounted successfully, I rebooted the device:

sudo reboot

Result: My Steam Frame booted normally again. The SteamOS graphical interface returned, and I did not need to factory-reset the headset or reinstall the operating system.

10. What actually caused the problem?

Once SteamOS was working again, I examined the previous boot's kernel logs:

journalctl -b -1 -k --no-pager |
  grep -Ei 'ext4|jbd2|I/O error|sda|uas|scsi|reset|timeout'

Interestingly, I discovered that the same directory had already been problematic long before the boot failure.

The first errors appeared around 12:30:

EXT4-fs warning (device sda8):
ext4_dirblock_csum_verify:
inode #1436211: comm steamweb:zcfq0:
No space for directory leaf checksum.
Please run e2fsck -D.

EXT4-fs error (device sda8):
__ext4_find_entry:
inode #1436211: comm steamweb:zcfq0:
checksumming directory block 0

The errors appeared again around 21:14. The same inode was involved each time.

The process accessing the problematic directory was steamweb, a Chromium-based component of Steam.

This does not necessarily mean Steam caused the corruption. It only means Steam encountered the damaged directory during filesystem operations.

The specific checksum warning suggests a problem with ext4 directory metadata or its layout. The kernel recommended e2fsck -D, which can rebuild directory indexes, but I did not need to perform that additional operation after the interactive repair.

Storage hardware

My Steam Frame contains Micron UFS flash storage:

Vendor:  MICRON
Product: MT001TBGBB8U41
Capacity: 1.02 TB
Logical block size: 4096 bytes

I attempted to read storage health using:

sudo smartctl -a /dev/sda

However, conventional SMART information was unavailable, which is not surprising for UFS storage.

I did not find clear storage I/O errors in the logs, but that alone does not prove the hardware is fault-free.

Final thoughts

In my case, the failure chain was:

Corrupted ext4 directory
↓
Automatic fsck fails
↓
/home cannot be mounted
↓
SteamOS graphical session fails
↓
Steam Frame stuck on boot logo

The actual solution was straightforward once I identified the filesystem error: stop the automatic fsck loop, repair the unmounted ext4 partition manually, verify it, and reboot.

The most useful preparation: Enable SSH on your Steam Frame while everything is still working. Having remote shell access made this recovery possible without a factory reset.

Hopefully this helps someone recover a Steam Frame that appears completely stuck at the boot logo.