Notice: Trying to access array offset on value of type bool in /srv/www/vhosts/ on line 649 FS#237 : /dev/mmcblkN - N sometimes points to left, sometimes to right SD card slot! Unreliable! Dangerous!

OpenPandora Main OS

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Core
  • Operating System Release 1 (Zaxxon)
  • Severity Critical
  • Reported Version Hotfix 5
Attached to Project: OpenPandora Main OS
Opened by Stefan Nowak - 08.07.2011
Last edited by Stefan Nowak - 13.07.2011

FS#237 - /dev/mmcblkN - N sometimes points to left, sometimes to right SD card slot! Unreliable! Dangerous!

SPECIFICATION: According to /dev/mmcblk0 is the left SD card slot (the one being closer to the headphone check) /dev/mmcblk1 is the right SD card slot I trusted that device path specification. And it was correct MOST of the time. But sadly only most of the time, NOT ALWAYS!!! This bug is severely dangerous, as a (possibly critical) command could unexpectedly affect a device other than the one you intended it for! BUG INCIDENT: Sadly, I realized this bug at the worst possible moment! I issued the command: shred -fvz /dev/mmcblk0 but it erased the card in the RIGHT slot. I realized that because the card inserted on the left has 16GB, and the one on the right 128MB. I checked both the card positions and my entered command, to exclude my own mistake. Sadly it was not a clumsy mistake: This severe bug really exists! BUG REPRODUCIBILITY: I already slightly witnessed this bug during the last days, but thought it was just a coincidence. I.e. in GParted the larger card showed up at the wrong device path. I did a refresh and/or ejected/re-inserted the card, and the expected device path was back again, and I did not think further about this incident. Only today with this fatal shred incident, I eventually realized this behavior is a bug. Luckily I had my data backed up.
Closed by  Stefan Nowak
13.07.2011 10:54
Reason for closing:  Not a bug
Additional comments about closing:  Wiki contained misleading info. Was corrected in this version:
John Willis commented on 13.07.2011 09:36
Just to extend on Mike's comments (as you requested me to do). Relying on a fixed device node on Linux for a task such as shredding a card without a check is fundamentally a very bad idea. Device nodes in Linux are NOT sacrosanct (this does not just apply to mmcblk devices) and can change based on the enumeration that takes place, normally on a desktop for example, that enumeration is fairly consistent but this is not always the case and should never be taken as fixed. If your running commands such as this with no abstraction via a GUI or API unfortunately it falls into the 'caveat emptor' end of the spectrum and it is not something we can really do a huge amount about. /dev/mmcblk0 is simply the 1st SD device the system becomes aware of (regardless of slot) and 1 is the second (and so on, if you connected a card reader to USB and put an SD card in that before you used the built in slots you can throw this out further). Regards, John
Stefan Nowak commented on 13.07.2011 10:37
Thanks for your answers. The false info came from the mentioned wiki page. 1) Michael Mrozek already corrected the info there. 2) In addition I informed the person who wrote it, that one should be careful with publishing instructional texts, on which other less informed people rely, especially if those instructions contain possible dangerous commands/consequences.


Available keyboard shortcuts


Task Details

Task Editing