CRITICAL UPDATE: Real-world Bug & Urgent Feature Request Expansion (Why Pool Export/Import GUI is Mandatory)
Following up on my original request for advanced storage management, I recently encountered a severe storage system lockup on ZimaOS v1.6.1 that solidifies why the current storage architecture needs a major overhaul.
Currently, the ZimaOS Storage Panel only provides a destructive 【Format and Break】 option. There is absolutely no GUI workflow to safely Disconnect, Export, or Import an existing pool without wiping the data. This missing lifecycle feature creates a fatal flaw when users physically migrate arrays from standard Linux environments (like Proxmox VE or traditional BTRFS NAS systems) into bare-metal ZimaOS.
The Real-world Failure Scenario (mdadm over Btrfs Migration Bug)
When attempting to migrate a healthy 4-HDD mdadm RAID 5 array with a Btrfs filesystem layer directly into ZimaOS, the system’s strict Immutable OS sandbox and the lack of an Import/Export GUI completely broke the storage management layer:
-
Web UI Desync & 500 Internal Server Error: The Storage Control Panel detected the physical drives but completely choked on the legacy partition metadata. Clicking into the Files App threw a
/media/pool: storage not mounterror. Because there is no “Disconnect/Import” toggle, attempting to format or manage the ghost pool directly crashed the backend, rendering a persistent500 Internal Server Errorpop-up in the Web UI. -
Severe OS Sandbox / Kernel Node Isolation:
Upon debugging via SSH (tonyadmin),cat /proc/mdstatconfirmed that the Linux kernel successfully assembled the array flawlessly as healthy ([4/4] [UUUU]). However, due to ZimaOS’s aggressive sandboxing, the system completely omitted the creation of the block device node (/dev/md1or/dev/md127did not exist).
Even though a symlink existed at/dev/block/9:1 -> ../md1, runningmountmanually returnedspecial device does not exist. -
Total CLI Lockout:
Because it is an Immutable OS, standard administrative commands likesudo su -are completely blocked (command not found). Users are left entirely trapped in a loop where the GUI throws 500 errors and the CLI is too castrated to manually rescue or mount the data.
Critical Expansion Request: Native Pool Import / Export (Disconnect) Wizard
This issue proves that traditional RAID concepts managed by rigid background scripts are failing the users. To solve this, ZimaOS desperately needs to implement a Native Pool Lifecycle Wizard in the GUI, similar to how ZFS handles pools:
- 【Disconnect / Export Pool】 (Safe Unmount): Allow users to safely export/disconnect a Btrfs/ZFS pool via the Web UI without wiping the hard drives. This spins down the array, cleans up the OS system cache, removes host-specific UUID associations, and prepares the physical disks to be safely pulled out and migrated to another ZimaOS box or any standard Linux system.
- 【Scan & Import Pool】 (Foreign Array Adoption): A visual scan wizard that detects foreign or migrated storage arrays (whether standard mdadm, native Btrfs, or ZFS pools). Instead of blindly throwing a 500 error or forcing a complete wipe via 【Format and Break】, it should recognize the existing filesystem signature and safely mount it with a single click.
Why this matters
As stated in the background of this issue, advanced users choose hardware platforms like the Minisforum N5 or multi-bay ASRock Rack servers precisely for storage portability and disaster recovery.
Forcing a destructive wipe (Format and Break) as the only method to clear a pool error or manage a disconnected state is extremely dangerous for data integrity. Unlocking ZFS-style zpool import/export and standard Btrfs device pool tracking within the ZimaOS GUI is not just a luxury feature—it is a critical safety requirement to prevent complete OS storage panel lockups.
