KNULLI Second SD Card Detected but Not Used? Fix Userdata Storage Selection

Short Answer

KNULLI uses one selected storage device to back the logical path /userdata. It does not merge the primary and secondary cards.

To select the second card safely:

Power the RG CubeXX off before inserting or reseating the secondary card.
Boot KNULLI with the intended card present.
Open Start → System Settings → Storage → Storage Device.
Identify the intended entry by its displayed label and approximate capacity.
Select that entry and leave the menu normally.
Use Start → Quit → Restart System once.
After restart, confirm the same entry remains selected.
Open System Settings → Information → User Disk Usage and compare its total capacity with the intended card.

The selector displays a label and capacity, but KNULLI saves the selected filesystem’s UUID. The selected row shows configuration intent; the post-restart capacity check supplies separate evidence about which filesystem is actively backing /userdata.

Selecting storage does not copy or migrate existing data. Fresh KNULLI folders on the second card indicate initialization, not that games, saves, BIOS files, media, or settings were transferred.

Version and evidence scope

Device: RG CubeXX; shared H700 behavior only where official sources support it

Releases: Firefly 20241204, Gladiator II 20250813, Scarab 20260511

Menu: Start → System Settings → Storage → Storage Device

Visible identity: label or NO_NAME plus approximate capacity

Persisted identity: filesystem UUID

Apply action: one normal restart

Evidence: official documentation and release-matched source; no owner-device result is claimed

Symptom: Keep These Six Problems Separate

A. The second card is listed, but Internal remains active

The external card appears in the selector, but it may not have been selected, applied through restart, or mounted successfully at boot.

B. The choice appears to revert after restart

KNULLI can fall back to Internal when the saved external UUID is unavailable or cannot mount. That runtime fallback can look like a reset even when the configured UUID remains stored.

C. Displayed capacity or free space does not match the intended card

The active /userdata filesystem may not be the backing store you expected. Capacity is supporting evidence, not a unique physical-card identifier.

D. Replacing the card makes the stored selection unavailable

A replacement card normally has a different filesystem UUID. KNULLI may still be configured for the removed card’s UUID until the replacement entry is selected.

E. The label or device identity is ambiguous

The selector hides the UUID and shows label plus size. Two cards with the same label and similar capacity can look identical.

F. KNULLI-created folders appear, but existing data did not move

This is initialization, not proof of migration. The normal storage-selection workflow does not state that existing user data is copied.

Version Scope

Official RG CubeXX/H700 images exist for all three scoped releases. Their storage selectors use the same core UUID-based selection model, but Scarab changes the external backing layout.

Firefly `20241204`

Firefly exposes Start → System Settings → Storage → Storage Device. Its storage script persists a selected external filesystem as DEV <UUID> in the boot configuration. Its boot script resolves that UUID and uses the external partition root as /userdata.

Gladiator II `20250813`

Gladiator II keeps the same menu, label-plus-size display, UUID persistence, normal-restart requirement, and Internal fallback behavior. Its external partition root also backs /userdata.

Scarab `20260511`

Scarab retains the same user-facing selector and UUID model. Its boot-configuration filename changes with the KNULLI naming transition.

The pinned Scarab mount implementation creates an external /batocera directory and bind-mounts that directory as logical /userdata. Scarab release notes also describe automatic migration for legacy SD2 userdata from prior versions. That is a specific version-migration path, not a promise that normal Internal-to-second-card selection copies existing data.

What remains the same

Across the three releases:

the selector displays label or NO_NAME plus size;
KNULLI retains the selected filesystem UUID internally;
one normal restart applies a changed storage target;
only one backing store supplies logical /userdata;
boot can fall back to Internal if the saved UUID is missing or cannot mount.

Do not generalize RG CubeXX slot orientation, Linux device nodes, filesystem support, or second-slot availability to every H700 handheld.

Configured Selection vs Active `/userdata`

These are different facts.

Configured selection

The Storage Device selector reads KNULLI’s configured sharedevice value. For a specific external card, KNULLI stores:

DEV <filesystem-UUID>

The UI hides the DEV <UUID> prefix and displays the remaining label and size. A selected entry therefore shows which UUID KNULLI intends to use at boot. It does not prove that filesystem mounted successfully.

Active `/userdata`

At boot, KNULLI resolves the stored UUID and tries to use that filesystem as the backing store for /userdata. If the UUID is unavailable or cannot be mounted, the boot process uses Internal userdata instead. Source also contains a RAM fallback if Internal fails.

The active mount can therefore differ from the configured target.

Why both checks are required

After restart, verify both:

Storage Device: the intended label-plus-capacity entry remains configured.
User Disk Usage: the active /userdata total is consistent with the intended card.

The selector shows configuration intent. User Disk Usage reports active filesystem capacity. Neither identifies a unique card serial number or proves migration.

For network access to the active /userdata, open KNULLI’s SHARE folder from Windows.

Identify the Card by Label and Capacity

KNULLI’s selector displays an external entry using:

its partition label, or NO_NAME when no label is available;
its approximate filesystem size.

An entry may look like SHARE - 25.6G. This is only an example; usable size need not equal advertised card capacity exactly.

Use label and capacity together:

Record the current selection before changing it.
Record the intended card’s visible label.
Compare its approximate size.
Select only when that combination is sufficiently distinct.

The UI does not expose the UUID. Capacity is corroborating evidence, not unique physical identity.

If two entries are indistinguishable

Do not guess. Shut down normally. With power fully off, ensure only the intended supported secondary data card is present in the secondary slot labeled TF2/Ext., while leaving the required primary KNULLI system card in place. Then boot and inspect the selector again.

Never insert, remove, or reseat a card while the device is powered. Do not infer a top/bottom orientation or /dev/mmcblk* mapping from this guide.

Select the Intended Device

Boot with the intended secondary card present.
Open Start → System Settings.
Under Storage, open Storage Device.
Record the current selection.
Identify the intended external entry by label and approximate capacity.
Select that one entry.
Exit the settings screen normally so KNULLI saves the choice.

A reboot-required notice is expected. The selection is boot-time storage configuration; /userdata does not switch backing storage merely because a row was highlighted.

Do not edit batocera-boot.conf, knulli-boot.conf, mount scripts, UUIDs, or manual mount settings.

Perform One Normal Restart

Use the documented path:

Start → Quit → Restart System

Restart once. Do not use sleep/wake, a theme reload, or a game-list refresh as a substitute. Do not cut power while KNULLI is running.

Verify the Selector and Active Capacity

1. Check the configured target

Open Start → System Settings → Storage → Storage Device and confirm that the intended label-plus-capacity entry remains selected.

This shows that the target remains configured after one restart. It does not prove the mount succeeded.

2. Check active `/userdata` capacity

On Scarab/current English UI, open System Settings → Information → User Disk Usage. Compare its total with the intended card’s expected usable capacity rather than the primary card’s SHARE partition.

Equivalent disk-usage code exists in release-matched Firefly and Gladiator frontend history, but wording can vary by release, translation, or theme. Do not invent a different menu label.

The capacity display does not reveal card serial, hidden UUID, physical slot, health, filesystem integrity, migration, or game visibility.

Pass condition

Stop when both conditions are true:

The intended external entry remains configured after restart.
User Disk Usage reports a total consistent with that card actively backing /userdata.

Do not create, copy, move, rename, or delete files as verification. A selector screenshot proves only visible configuration. A capacity screenshot supports active-filesystem identity but does not prove migration or long-term persistence.

Diagnose Reversion or Internal Fallback

Documented fact: the selected UUID is designed to persist

All three release-tagged storage scripts write the selected UUID into boot configuration and read it at startup. An apparent reversion should first be treated as possible boot fallback, not immediate proof that KNULLI silently reset the setting.

Documented fact: an unavailable or unmountable UUID triggers fallback

If the stored UUID cannot be found or mounted, KNULLI can boot using Internal userdata. The source establishes fallback, but it does not establish why a particular card failed to mount. Do not diagnose corruption, card failure, contact problems, or a damaged filesystem without separate evidence.

Safe retry

Shut down normally.
With power fully off, confirm the intended secondary card is seated.
Boot KNULLI.
Open Storage Device.
Confirm the intended label-plus-capacity entry appears.
Select that currently listed entry again.
Exit normally.
Perform one normal Restart System.
Recheck both the selector and User Disk Usage.

Do not format, initialize, repartition, repair, clone, or recover the card in this workflow.

Card Replacement and UUID Explanation

KNULLI saves a filesystem UUID, not “TF2,” the visible label, size, slot number, or Linux device node.

A replacement card normally has a different UUID. The old configured selection may therefore refer to the removed card even when the replacement has the same label and capacity.

After replacing the secondary card:

Power off before inserting it.
Boot KNULLI.
Open Storage Device.
Identify the replacement by its current label and capacity.
Select that entry.
Restart once.
Verify the configured entry and active capacity.

Do not clone UUIDs, edit identifiers, or assume every replacement necessarily has a different UUID. The UUID mechanism is documented; the identity of a particular card must still be checked.

System-Created Folders Are Not Migrated Data

After a new second card is selected and KNULLI restarts, KNULLI creates or populates the required userdata folder structure. Fresh folders prove initialization only.

They do not prove that KNULLI copied games, saves, BIOS files, scraped media, configuration, or any other existing files. Ordinary storage selection is not documented as a copy operation.

For firmware placement on the active storage, place and verify KNULLI BIOS files.

Scarab’s automatic legacy-SD2 migration is a separate major-version behavior for older data already associated with SD2. Do not generalize it into an Internal-to-SD2 migration promise.

This guide stops here. Copying, migration, folder layout, game detection, rescanning, cloning, recovery, and data verification require separate workflows.

Version Differences at a Glance

Release	Configured identity	Apply behavior	External layout	Fallback
Firefly `20241204`	`DEV <filesystem UUID>`	One normal restart	External partition root backs `/userdata`	Internal if UUID is absent/unmountable
Gladiator II `20250813`	`DEV <filesystem UUID>`	One normal restart	External partition root backs `/userdata`	Same
Scarab `20260511`	`DEV <filesystem UUID>`	One normal restart	External `/batocera` subdirectory backs `/userdata`	Same

Scarab adds a documented legacy-SD2 migration path. It does not change the logical /userdata path and does not turn normal storage selection into a general migration tool.

If It Still Fails

A. Second card is listed, but Internal remains active

Select the exact external label-plus-capacity entry.
Exit normally.
Use Quit → Restart System once.
Recheck the selector and User Disk Usage.

B. Choice appears to revert after restart

Confirm the intended card was present before power-on.
Check whether its entry still appears.
Treat Internal usage as possible mount fallback.
Re-select the currently listed target and restart once.

Do not call this a confirmed settings-reset bug without evidence that the stored value was rewritten.

C. Capacity or free space does not match

Compare User Disk Usage with the card’s approximate usable capacity.
Reopen Storage Device and correlate label plus size.
Remember that advertised and usable capacities differ.

Do not format or edit identifiers to make numbers match.

D. Card replacement made the selection unavailable

Find the replacement’s current entry.
Select it rather than relying on the removed card’s saved UUID.
Restart once and verify capacity.

E. Label or identity is ambiguous

Record label and capacity.
Do not guess between identical-looking entries.
Power down before changing which secondary card is present.
Retest with only the intended supported TF2/Ext. card present alongside the required system card.

F. New folders exist but old data does not

Stop. Folder creation is initialization, not migration. Do not mass-move, delete, format, partition, clone, recover, or rescan data in this selection guide.

Safe escalation record

Record locally: RG CubeXX model, exact KNULLI release, current Storage Device display, external label and approximate capacity, whether the card was present before boot, whether the reboot-required notice appeared, post-restart User Disk Usage total, and whether KNULLI used Internal.

Do not post boot files, UUIDs, personal labels, serials, device identifiers, or unrelated library contents.

FAQ

What does Internal mean on RG CubeXX?

In this workflow, Internal means the SHARE/userdata partition on the primary KNULLI system card. It does not mean soldered eMMC.

Does KNULLI merge both cards for one library?

No. One selected backing store supplies logical /userdata.

Why does the UI show label and capacity instead of UUID?

The UI hides the DEV <UUID> prefix and presents label or NO_NAME plus size. KNULLI retains the UUID internally.

Why is a restart required?

The selection is applied by the boot-time mount process. Highlighting the item does not immediately switch active /userdata.

Why did KNULLI return to Internal after I replaced SD2?

The saved UUID may belong to the removed card. Select the replacement’s current entry, restart once, and verify capacity.

Do fresh folders mean my files were copied?

No. KNULLI creates the required userdata structure on newly selected storage. That does not prove migration.

What changed in Scarab’s external layout?

Scarab’s pinned boot implementation uses an external /batocera directory as the source for logical /userdata. Firefly and Gladiator II use the external partition root directly.

Does User Disk Usage prove which physical card is mounted?

It reports the active userdata filesystem’s used and total space. It cannot prove a unique physical card when candidates have similar capacities and does not expose serial number or UUID.

Will selecting SD2 make my games appear?

This guide makes no game-visibility promise. It verifies only the configured and active storage backing /userdata. If games remain absent, fix games missing from the KNULLI list.