dietpi-drive_manager drive name switch when formatting (Caused data loss)

[Arimodu]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=19
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | trixie
• Kernel version | Linux Prometheus 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 GNU/Linux
• SBC model | Native PC (x86_64)
• Power supply used | N/A
• SD card used | N/A

Additional Information (if applicable)

• Software title | dietpi-drive_manager

Steps to reproduce

Note: Probably not accurate

1. Have NTFS formatted drive
2. Enter format, whole drive, new GPT, XFS
3. Drive manager swaps to another drive and fails with 'device is busy'
4. Force-unmount the target drive letter (/dev/sdb) in a subshell
5. Drive manager does something (lost to shell scrollback)
6. After reboot, partition table gone on non-target drive /dev/sdc - complete file structure loss, manual recovery with new partition table and xfs_repair, files named after inode numbers.

Expected behaviour

Drive manager should format the correct drive

Actual behaviour

Drive manager swaps drive letter mid-format

Extra details

Unfortunately all the evidence of the original data loss incident is lost to a reboot and a corrupted XFS filesystem. However after multiple hours of troubleshooting and attempt at data recovery I have caught drive_manager in the act of swapping the letter of the drive mid-format.
Data on /dev/sdc is permanently lost, as while the data is there in lost+found, the filesystem structure is gone.

The log from a later reformat to btrfs (after data loss and me giving up on the data on sdc) - I thought it was an issue with XFS:

root@Prometheus:~# dietpi-drive_manager
[ INFO ] DietPi-Drive_Manager | Detecting drives, please wait...
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sda2 > /
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sda1 > /boot/efi
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/nvme0n1p1 > /mnt/adata-nvme
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdb1 > /mnt/exos
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdc1 > /mnt/backups
[  OK  ] DietPi-Drive_Manager | mv .fstab /etc/fstab
[  OK  ] DietPi-Drive_Manager | systemctl daemon-reload
[ INFO ] DietPi-Drive_Manager | Checking for required APT packages: e2fsprogs
[  OK  ] DietPi-Drive_Manager | sync
[ INFO ] DietPi-Drive_Manager | Checking for required APT packages: btrfs-progs
[ INFO ] DietPi-Drive_Manager | Skipping APT update, as last call was less than an hour ago and neither sources lists nor architectures changed since.
[ INFO ] DietPi-Drive_Manager | APT install btrfs-progs, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
  libcurl3-nss nss-plugin-pem
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libreiserfscore0t64
Suggested packages:
  duperemove
The following NEW packages will be installed:
  btrfs-progs libreiserfscore0t64
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 989 kB of archives.
After this operation, 5493 kB of additional disk space will be used.
Get:1 http://ftp.debian.org/debian stable/main amd64 libreiserfscore0t64 amd64 1:3.6.27-9 [80.7 kB]
Get:2 http://ftp.debian.org/debian stable/main amd64 btrfs-progs amd64 6.14-1 [908 kB]
Fetched 989 kB in 0s (5319 kB/s)
                                Selecting previously unselected package libreiserfscore0t64.
(Reading database ... 91437 files and directories currently installed.)
Preparing to unpack .../libreiserfscore0t64_1%3a3.6.27-9_amd64.deb ...
Unpacking libreiserfscore0t64 (1:3.6.27-9) ...
Selecting previously unselected package btrfs-progs.
Preparing to unpack .../btrfs-progs_6.14-1_amd64.deb ...
Unpacking btrfs-progs (6.14-1) ...
Setting up libreiserfscore0t64 (1:3.6.27-9) ...
Setting up btrfs-progs (6.14-1) ...
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.57+deb13-amd64
Processing triggers for libc-bin (2.41-12) ...
[  OK  ] DietPi-Drive_Manager | APT install btrfs-progs
[.     ]umount: /mnt/exos: target is busy.t/exos
[FAILED] DietPi-Drive_Manager | umount /mnt/exos
[  OK  ] DietPi-Drive_Manager | umount /mnt/exos
[  OK  ] DietPi-Drive_Manager | systemctl stop mnt-exos.automount
[  OK  ] DietPi-Drive_Manager | rmdir /mnt/exos
[ INFO ] DietPi-Drive_Manager | Detecting drives, please wait...
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sda2 > /
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sda1 > /boot/efi
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/nvme0n1p1 > /mnt/adata-nvme
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdc1 > /mnt/backups
[ INFO ] DietPi-Drive_Manager |  - Detected unmounted drive: /dev/sdb1
[  OK  ] DietPi-Drive_Manager | mv .fstab /etc/fstab
[  OK  ] DietPi-Drive_Manager | systemctl daemon-reload
[  OK  ] DietPi-Drive_Manager | sync
[ INFO ] DietPi-Drive_Manager | Erasing partition: /dev/sdc1
[  OK  ] DietPi-Drive_Manager | dd if=/dev/zero of=/dev/sdc1 bs=4K count=1337
[.     ]ERROR: /dev/sdc1 is mounteds.btrfs -f /dev/sdc1
btrfs-progs v6.14
See https://btrfs.readthedocs.io for more information.

[FAILED] DietPi-Drive_Manager | mkfs.btrfs -f /dev/sdc1
[FAILED] DietPi-Drive_Manager | Unable to continue, DietPi-Drive_Manager will now terminate.

[Arimodu]

The relevant section is:

[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdb1 > /mnt/exos
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdc1 > /mnt/backups

and later on when formatting /mnt/exos

[.     ]umount: /mnt/exos: target is busy.t/exos
[FAILED] DietPi-Drive_Manager | umount /mnt/exos
[  OK  ] DietPi-Drive_Manager | umount /mnt/exos
...
[ INFO ] DietPi-Drive_Manager | Erasing partition: /dev/sdc1
[  OK  ] DietPi-Drive_Manager | dd if=/dev/zero of=/dev/sdc1 bs=4K count=1337
[.     ]ERROR: /dev/sdc1 is mounteds.btrfs -f /dev/sdc1

/dev/sdc is mounted at /mnt/backups

[MichaIng]

Many thanks for your report. An important one. When the drive is unmounted, drives are rescanned, which re-creates the drive array from scratch, hence the indexes can change. They are even assured to change, since unmounted drives are detected in a separate loop after mounted drives.

You can observe this in your logs. While the drive is mounted:

[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdb1 > /mnt/exos
[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdc1 > /mnt/backups

After it was unmounted:

[ INFO ] DietPi-Drive_Manager |  - Detected mounted physical drive: /dev/sdc1 > /mnt/backups
[ INFO ] DietPi-Drive_Manager |  - Detected unmounted drive: /dev/sdb1

They swapped position, hence indexes.

There is a function in the script which updates the index for the currently selected drive. But it does so based on the mount target. After unmounting a drive, there is no mount target anymore, hence the index remains the old one.

Now one can ask why drives are rescanned at all right before one is formatted, instead of just doing it after it has all finished. It takes quite a while and is done another time after the format succeeded. The rescan is currently done in the respective mount and unmount functions, and this should be better done in the parent functions, and only if this is the last step of whichever operation is done.

But this whole numerical index thing is fragile anyway, and we better not rely on an indexes being updated correctly after a rescan. Hence first step is switching to associative arrays with the source as index. So the most important identifier, which does not depend on whether or where a contained filesystem is mounted, is assured to remain correct.

Theoretically the same filesystem can be mounted multiple times, but so far the drive manager filters duplicate mount points anyway, hence no regression.

[Arimodu]

I guess I can see that, however from a users perspective, this is completely transparent, and when doing a format on a mounted drive, the script unmounts it automatically. I think this is what caused the dataloss itself, as when the two drives swapped places, the dd command later on just overwrote the GPT table and XFS superblock, along with some file data, causing everything to end up an orphaned inode.

From my perspective I don't even understand why the dd command is there, why overwrite X kbytes with zeros before a format?

[MichaIng]

Actually, a single line/step was missing:

• The on Mount_Drive as well as all other circumstances where drives are rescanned, the MENU_DRIVE_TARGET variable was set to the new mountpoint, in which case the scan function aligns the index automatically with this new target: https://github.com/MichaIng/DietPi/blob/6a62f56/dietpi/dietpi-drive_manager#L476-L477
• This was however missing for the Unmount_Drive function: https://github.com/MichaIng/DietPi/blob/6a62f56/dietpi/dietpi-drive_manager#L493
  Of course there is no mountpoint anymore when unmounting a drive, but it is assigned as placeholder based on the UUID, or based on the device name if not formatted with a filesystem. Hence:

  Init_Drives_and_Refresh
  MENU_DRIVE_TARGET="/mnt/${aDRIVE_UUID[$MENU_DRIVE_INDEX]}"

  and after formatting a partition via dd to be failsafe:

  MENU_DRIVE_TARGET="/tmp/aDRIVE_SOURCE_DEVICE[$MENU_DRIVE_INDEX]"

  The rescan would have then aligned the index automatically. A pain that it was missing exactly here.

However, it is better to not rely on such numerical indexes at all, hence I did a larger rework which changes this to the mount source (respectively device node), along with two more changes to assure that the format run never relies on any global variable that can change: #7853

[Arimodu]

Thank you for the quick resolution. Hopefully this didn't affect anyone else.

My case was lucky that the other drive was, as the mount point implies, backups. The only real loss for me so far are two files, which I will probably go fishing for in the inode list, and the file history, which is inconvinient but not critical.

I am glad this is resolved now.

[MichaIng]

Okay, merged, with another minor fix and enhancements in some menu and output texts: 6b6420a