mounting multiple STM32 boards Topic is solved

Having issues with your DietPi installation or found a bug? Post it here.
User avatar
MichaIng
Site Admin
Posts: 3214
Joined: Sat Nov 18, 2017 6:21 pm

Re: mounting multiple STM32 boards

Post by MichaIng »

For certain drive/mount types indeed dietpi-drive_manager should be skipped. I'm not yet sure how to handle best:
  • It detects some mount types, like tmpfs, network drives, ecryptfs, ..., and leaves those fstab entries untouched already. But for this, there needs to be a way to identify them. See https://github.com/MichaIng/DietPi/blob ... #L122-L127 and https://github.com/MichaIng/DietPi/blob ... nager#L271. If those virtual drives appear exactly like physical drives, this method cannot be used. So is there any way, like with lsblk, findmnt, blkid, to know whether a block device is such a virtual one or not?
  • A custom section is actually not a bad idea. The problem is that fstab is edited by some other scripts as well, so we'd need to implement the custom section detection in several places. And then also sometimes entries are removed first and added with changed options again, like when increasing the /tmp tmpfs size, moving the rootfs to an external drive, restoring a dietpi-backup at first boot etc. So not sure how to handle custom entries then when something in them needs to be changed. Keeping them in custom place, re-adding them outside, how we know whether this will work then. So nice in theory, but it gets complicated :?.
  • I was thinking about using systemd mount units with dietpi-drive_manager and keeping the whole fstab untouched. So instead of adding an fstab entry, which is parsed and translated into a mount unit at boot, we can create such a mount unit directly. But it may be confusing for admins when seeing an empty fstab. At least it requires some explanation. But that way we wouldn't mess with any custom entries.
  • However, while using labels is a workaround, if multiple block devices have the same UUID, this is gonna cause issues earlier or later outside of our scripts. So while I agree that dietpi-drive_manager requires a better handling of custom entries, in your case I'd invest some time to find out how to have unique "Universally Unique Identifier" for those drives. Often block devices simply have no label, so a general option to use labels instead of UUIDs is not possible, same with PARTUUIDs, considering that a filesystem can be created on a drive without any partition table. UUIDs are the only reliable "unique" identifier which is aimed to always work, so if this is broken by some virtual drive implementation, then that implementation requires fixing ;).
jcwippler
Posts: 7
Joined: Wed May 26, 2021 8:16 pm

Re: mounting multiple STM32 boards

Post by jcwippler »

Many thanks for the detailed info. First off: I understand the complexity, and respect any choice you guys make on this. Just keep in mind that, as the saying goes, "perfection is the enemy of done" - it may not be possible to address every concern, so I'll be keeping my "label-saving" workaround for now, until a better option emerges.

My solution is not perfect. I don't know how the setup will work if I plug in two identical boards, for example (not a very useful scenario for a build farm). AFAICT, this will lead to duplicate disk labels.

The chance of this getting fixed by the manufacturer is zero: ST Microelectronics is a company with $10B yearly revenues. They have other priorities than helping out an open-source developer.

Each µC on the board has a unique 96-bit ID. This is used to construct the unique serial number of the serial port, also implemented as part of the USB interface. I use it to uniquely identify the serial port, via /dev/serial/by-id/.... I have not yet found a unique way to associate each virtual drive with this same serial number, but I also haven't looked deeply since the disk label was good enough.
User avatar
MichaIng
Site Admin
Posts: 3214
Joined: Sat Nov 18, 2017 6:21 pm

Re: mounting multiple STM32 boards

Post by MichaIng »

jcwippler wrote: Sat Aug 21, 2021 1:26 pm "perfection is the enemy of done"
Haha, yes I agree, and this is particular issue for me quite often, as I tend to be perfectionist :D. However, what is important to me is, when we add a feature to our scripts, it needs to be well supported (not conflicting) with our other scripts. And for a custom section in fstab, this is a bit difficult to achieve. Switching from fstab to system mount units is a large task as well, but is solves a lot of other issues and it is much easier then to leave fstab consequently as custom file and strictly only handle systemd mount units we created. All is also possible with a custom section, but it implies a lot more grep/sed action then, at least.
Post Reply