- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Core
- Operating System Release 1 (Zaxxon)
- Severity Critical
- Reported Version Hotfix 5
Opened by porg - 08.07.2011
Last edited by porg - 13.07.2011
FS#237 - /dev/mmcblkN - N sometimes points to left, sometimes to right SD card slot! Unreliable! Dangerous!
SPECIFICATION:
According to http://pandorawiki.org/SD_compatibility_list
/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.
13.07.2011 10:54
Reason for closing: Not a bug
Additional comments about closing: Wiki contained misleading info.
Was corrected in this version:
http://pandorawiki.org/?oldid=8655
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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
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.