[PROPOSAL] RPI imager fails on some preformatted media

[marcelgsteiger]

I'm using the RPI imager on ubuntu 20.04LTS. Normally I can use the RPI Imager even when the disk has some preformatting. Obviously the imager tries to unmount partitions that have been auto-mounted when inserting the device.

But if the device contains md (= linux raid) partitions that have been auto-activated, this does not work - these sometimes remain active, prohibiting partition operations.

I propose that the imager detects, stops and then erases md devices that have been auto-started, i.e. doing something equivalent to

mdadm --stop <device(s)> && mdadm --zero-superblock <affected partition(s)

before trying to delete these partitions, or at least give a meaningful message.

Regards Marcel

[maxnet]

Practical problem is that calling mdadm requires root privileges, and Imager typically does not run as that...

[marcelgsteiger]

Ah, I thought that a program that can overwrite the entire device could also do this, so please excuse me. /proc/mdstat could still reveal active devices with members on the SD card. Why i stumbled about this: I add a production root partition 3 as mdraid, starting with only one device ("missing" as second device) and then add mirror devices later - using partition 2 as maintenance root partition and using the "TRYBOOT" feature. The mirror device can be added later and is typically a USB SDXC card holder with everything necessary to boot instantly should the main SD card fail. My testing left some debris behind...

[maxnet]

We outsource opening the raw disk device to udisks2. Perhaps that can destroy raid arrays as well. But requires more work than just calling mdadm. And probably generates multiple password prompts.

[lurch]

I think using Linux RAID on an SD-card is very much of an edge-case?

[marcelgsteiger]

This may seem somewhat exotic - I agree - it's my attempt to apply a common trick from the old days. I'm running a headless building / energy control system running 24*365 with heavy database load now for 3 years on a pi 4. Daily database backups from SSD to the SD card and manual rootfs backups from SD card to the USB SSD after software updates. Restoring after a device failure is too complicated and leads to significant downtime and loss of real-time data capture and today's data; linux RAID can help to improve this a lot.

Moreover, I believe that currently available A2 SDXC cards can replace USB SSDs in many cases. To evaluate, I copied the database partition (Grafana/Zabbix/NodeRed/PostgreSQL) from the Samsung Portable T5 UAS SSD to a Samsung ProPlus 128GB SDXC (available as a kit w/USB adapter) - the app did not run noticeably slower. However, of course, "true" USB SSDs are still much faster - at least with the PI5 whose USB power allows to connect two of them.

So the idea came up to repartition and use symmetric md mirroring on two identical and interchangeable SDXC (one of them in an USB adapter) instead of asymmetric SDXC and USB SSD; using RAID 10 where possible to double read speed and help compensate for the fact that writes now must occur twice.

The production rootfs is now RAID1 with its members on partition 3 w/metadata 0.9. The eeprom boots without problems, root is normally mounted read-only. swap, /var, /home, /tmp are RAID 10 using logical partitions and metadata 1.2 with offset layout. During install, I work with only one SDXC card (to save time) and initialize the md devices with the second RAID member missing, like so for /var on logical partition 8: mdadm --create /dev/md8 --level=10 --metadata=1.2 --raid-devices=2 --layout=o2 --chunk=2M --bitmap=internal --assume-clean --run --name=var --homehost=\<none\> --uuid={{specific_mduuid}} /dev/{{rootdev}}8 missing && mkfs -t ext4 -L RASPIMDVAR -U {{specific_uuid}} -Fq /dev/md8

I change the cmdline to use LABEL=RASPIxxxx instead of PARTUUID=xxxx and, in /etc/fstab, I use ID=md-uuid-{{ specific mduuid }}. This way, I can install everything normally with one SD card (either onboard or installed in the USB adapter) and then prepare a second SDXC card for mirroring. Even if this new card has other PARTUUIDs, the filesystems and RAID members are always found. If necessary RAID devices are accessible using /dev/md/var-xxx etc.

Other tricks become possible thanks to md - e.g. making bit-for-bit backup media while the system runs or snapshotting prior to critical updates/upgrades. The default partition 2 is being kept as maintenance root, without RAID, for the case should RAID itself need repair.

[tdewey-rpi]

@marcelgsteiger Thanks for the report! Your use case definitely hits my "interesting-engineering" button, but that's also why I cannot guarantee to be able to look at it in the near term. md is indeed a bit of a superpower when used correctly, though non-md-aware tooling prevents me using it more widely.

One breadcrumb for if/when we can get the bandwidth to come back to this: UDisk2 does indeed have something claiming to be MD support: http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.MDRaid.html. We already use UDisks2 via D-Bus, so a prototype could, in theory, be fairly straightforward.

As such, I'm not recommending this be closed - but something we could look at addressing in a future release, once we've acheived our maintainance and UI objectives.

[marcelgsteiger]

For now. I disable automatic assembly of new arrays temporarily and clear out lingering superblocks as follows (assuming /dev/sde is the inserted SD card and x,y,z the raid member partitions):

sudo udevadm control --env=ANACONDA=1 --reload
# insert card, determine device name (e,g, /dev/sde), then
sudo mdadm --zero-superblock /dev/sde{x,y,z}

...and, after finishing my rpi-imager work, I re-enable automatic RAID assembly with sudo udevadm control --env=ANACONDA= --reload