🚨 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 mount error. Because there is no "Disconnect/Import" toggle, attempting to format or manage the ghost pool directly crashed the backend, rendering a persistent 500 Internal Server Error pop-up in the Web UI.
-
Severe OS Sandbox / Kernel Node Isolation:
Upon debugging via SSH (tonyadmin), cat /proc/mdstat confirmed 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/md1 or /dev/md127 did not exist).
Even though a symlink existed at /dev/block/9:1 -> ../md1, running mount manually returned special device does not exist.
-
Total CLI Lockout:
Because it is an Immutable OS, standard administrative commands like sudo 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
🚨 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 like
sudo 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: