Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Are you sure you want to erase 'Mass Storage Device'? #439

Open
duanev opened this issue May 13, 2022 · 23 comments
Open

Are you sure you want to erase 'Mass Storage Device'? #439

duanev opened this issue May 13, 2022 · 23 comments

Comments

@duanev
Copy link

duanev commented May 13, 2022

rpi-imager-are-you-sure

The description I see for the target SD device is simply 'Mass Storage Device', which is pretty unnerving. "/dev/sdX" would be a much more welcome description. (this is on Linux, lsblk is being used to find candidates)
@maxnet
Copy link
Collaborator

maxnet commented Jun 3, 2022

"/dev/sdX" would be a much more welcome description.

Problem is that as which /dev/sdX device drives appear is not guaranteed to be fixed on Linux.
Your USB drive may be /dev/sdb today and /dev/sdc tomorrow.

@duanev
Copy link
Author

duanev commented Jun 4, 2022 via email

@lurch
Copy link
Contributor

lurch commented Jun 4, 2022

IMHO many users would get confused by "/dev/sdX" (or "/dev/sd*"), and not realise that the "X" designates a placeholder? 🤷 Also, on a system with multiple USB drives connected, "/dev/sdX" doesn't really help identify which drive Imager is going to overwrite?
(Oh - were you thinking that the "sd" in "/dev/sdX" stands for "SD card"? It doesn't, it stands for "SCSI Device", and in the Linux-world all internal SATA HDDs and all USB flash drives / USB card-readers / USB HDDs appear as "/dev/sdX")

IIRC the "Mass Storage Device" string comes from the USB descriptor for your particular card-reader, so on some systems it might say something like "Internal SD card reader" or "Sandisk USB3.0 SD" instead of "Mass Storage Device"?

@duanev
Copy link
Author

duanev commented Jun 5, 2022 via email

@lurch
Copy link
Contributor

lurch commented Jun 5, 2022

Indeed a warning such as this MUST uniquely identify the device about to be wiped in a way the user can recognize.

Do you have any clever suggestions for how RPi Imager might uniquely do that? Some USB SD card-readers (particularly the cheaper ones) just identify themselves as a "USB Mass Storage Device" without any additional information; so if you have a "generic" 16GB USB Flash drive and a 16GB SD-card in a "generic" USB card-reader plugged in at the same time, there's no way for the Linux kernel (or RPi Imager) to tell them apart - it just sees them as two USB-attached block devices.
If you're worried that you can't tell which device is which, I guess the only reliable way to be sure is to unplug everything except for your USB card-reader. 😕

@duanev
Copy link
Author

duanev commented Jun 5, 2022 via email

@maxnet
Copy link
Collaborator

maxnet commented Jun 5, 2022

I'll bet a mfg name shows up there ...

Imager already shows the manufacturer name if it is there...
Problem is SD card reader vendors are not so original with the name.

E.g.:

$ cat /sys/class/block/sdc/device/vendor
Generic 
$ cat /sys/class/block/sdc/device/model
STORAGE DEVICE

Then Imager shows it as "Generic STORAGE DEVICE"

@duanev
Copy link
Author

duanev commented Jun 5, 2022 via email

@MrSmoer
Copy link
Contributor

MrSmoer commented Dec 30, 2022

I was reading over this and I found a weird approach to this.
Would it help to include the timestamp the device was inserted or maybe "n seconds ago"?
Surely the unique identifiers change every time, so why not use that change to identify the desired device?
By this way you would just need to replug (if you had it inserted since boot-time) the desired device and not ALL devices to absolutely sure.
This could still be a pain if you used a multi-device reader though.

@maxnet
Copy link
Collaborator

maxnet commented Dec 30, 2022

Would it help to include the timestamp the device was inserted or maybe "n seconds ago"?

Don't think we have that kind of information (unless Imager is started first, before anything is plugged.)

Safest solution is to only run Imager on the Pi itself. The netinstall thing.
But requires wired Ethernet, and cannot borrow wifi credentials from normal computer that way, so is not so convenient either.

@MrSmoer
Copy link
Contributor

MrSmoer commented Dec 30, 2022 •
edited
Loading

Surely this is the safest solution, but rpi-imager is just a whole lot more convenient (thx ^^).

I guess you could extract it from the system logs, but that's not a good style, is it?

In linux there is an "sd 6:0:0:0: [sdX] Attached SCSI removable disk" event in dmesg/journalctl(idk about openrc logs)
Windows sends one in the EventViewer under Application and Services Logs -> Microsoft -> Windows -> StorageSpaces-Driver -> Operational
I don't know about mac, but I can search later

I know this could open a whole new can of worms, but what is your opinion about the approach with the timestamp, disregarding the technical difficulties?

If you think this is a waste of time, just say it. I don't want to force anything, I just wanted to mention the idea.
Have a nice day!

Edit: Is it maybe event possible to use the file creation time in /dev?

@lurch lurch mentioned this issue Dec 30, 2022
Open
@adamvleggett
Copy link

I can't speak for Linux, but on macOS I know it is possible to get the icon associated with a drive, I have seen more than one program use it. There is a StackOverflow article on the subject. I recently blew away an SSD with important data accidentally using the Pi Imager so this issue is pretty close to my heart. The following UI changes would have certainly prevented me from making the mistake (which I admit was ultimately my own responsibility).

Before:
before

After:
after

@lurch
Copy link
Contributor

lurch commented Dec 30, 2022

Linux does also display an SD-card icon for some drives, but it can only do this when the USB device reports itself as a SD-card-reader. As mentioned above, many of the cheaper USB card-readers just report themselves to the OS as a "generic USB Storage Device"; so there's no way of reliably telling whether a drive is an SD-card, a USB flash drive, or a USB HDD or SSD.

I don't work on RPi-Imager myself, but many years ago I worked on Etcher, and that also had many similar "complaints" to this one.

@adamvleggett
Copy link

adamvleggett commented Dec 30, 2022 •
edited
Loading

This doesn't have to have complete reliability everywhere. For it to work with repeatable results on the same machine would, I think, be adequate. Also note, I think the big bold 2 TB on the right, not inline with the name of the drive, would alone have been enough.

@duanev
Copy link
Author

duanev commented Dec 30, 2022 via email

@MrSmoer
Copy link
Contributor

MrSmoer commented Dec 30, 2022

How about the approach with plugin timestamps? Those would let you differentiate them?

@lurch
Copy link
Contributor

lurch commented Dec 30, 2022

I don't mean to sound rude, but if people don't spot the difference between "2000.4 GB" and "15.6 GB", then I'm not sure if they'd spot the difference between "inserted 3 hours ago" and "inserted 4 minutes ago" ? 🤷

@adamvleggett
Copy link

adamvleggett commented Dec 30, 2022 •
edited
Loading

I don't mean to sound rude, but if people don't spot the difference between "2000.4 GB" and "15.6 GB", then I'm not sure if they'd spot the difference between "inserted 3 hours ago" and "inserted 4 minutes ago" ? 🤷

Layout can have an enormous impact on what people read and understand when they look at a UI. Mixing "2000.4 GB" in with the name of the device caused me to skim over it, combined with the device name it just looked like a block of text, which I ignored because there was one item in the list (the SD card wasn't showing up for whatever reason) and I was used to there being one item in the list. Whether that could be considered lazy or not, it is how people operate. It's possible people would similarly skim over "inserted 4 minutes ago", but if one or both (2 TB or 2.0 TB is preferable to 2000.4 GB) is aligned to the right and/or in a different weight, size or color than the name of the device, it is more likely people will notice and process it.

At least on a Mac, the icon would make a huge difference because people are used to seeing the icon on the Desktop or in Finder already, and they are familiar with it.

Notice that in my "After" screenshot above, a person would notice the difference between the two items even if they were looking at the screen from across a room. Not so with the "Before".

@MrSmoer
Copy link
Contributor

MrSmoer commented Jan 1, 2023

I don't mean to sound rude, but if people don't spot the difference between "2000.4 GB" and "15.6 GB", then I'm not sure if they'd spot the difference between "inserted 3 hours ago" and "inserted 4 minutes ago" ? 🤷

No worries, i agree☺
I thought this was about uniquely identifying the device in the pop up, allowing to double check, without clicking back.
The warning with just the name is not 'verbose' enough, the layout is a seperate issuse. (please correct me)
So this is my point of view, why I think a timestamp would help:
If it was the device path, it would require the user to do an lsblk, which is inconvenient (not GUI) and sometimes unclear. The size of the device would not uniquely identify the desired device either, if there was another USB of the same size.

I think that the timestamp would often be unique enough.

E.g: I often buy those packs of three SanDisk 16 GB USBs and have one always plugged in to live-Boot other Linux distros.
When I want to flash an USB Device, I plug the new one in, realize i can not differentiate them, open a terminal and run lsblk, unplug the new USB run lsblk to find the missing device, and replug it.
A timestamp would do the entire trick for me.

Of course I do not want to force anything, and I dont expect you to implement it. I just want your feedback, if I should start to put the work in it myself over on the disklist repo. Sorry if I am annoying

@lurch
Copy link
Contributor

lurch commented Jan 1, 2023

E.g: I often buy those packs of three SanDisk 16 GB USBs and have one always plugged in to live-Boot other Linux distros.
When I want to flash an USB Device, I plug the new one in, realize i can not differentiate them, open a terminal and run lsblk, unplug the new USB run lsblk to find the missing device, and replug it.

Haha 😆

Sorry if I am annoying

Not at all, it's always useful to get different points of view 🙂 But I won't comment on any of your other points as I don't work on RPi Imager myself.
And note that the https://github.com/balena-io-modules/drivelist project we use isn't maintained by Raspberry Pi, so you might want to start up a separate conversation over there?

@MrSmoer
Copy link
Contributor

MrSmoer commented Jan 11, 2023

The imager seems to be using version 8.0.9 with a few tweaks, but https://github.com/balena-io-modules/drivelist is at version v11.1.0.
Maybe I can do a version bump

@maxnet
Copy link
Collaborator

maxnet commented Jan 11, 2023

The imager seems to be using version 8.0.9 with a few tweaks, but https://github.com/balena-io-modules/drivelist is >at version v11.1.0.
Maybe I can do a version bump

No C code was updated in the newer upstream drivelist version, and we are not using the node.js bits that did had an update.

And the way they are handling some things in the newer upstream drivelist in node.js code did NOT work properly on Mac OS X for me.
If you attach a USB-C USB HUB+SD card reader all-in-one thingy -like many Mac users have due to only one USB-C port on some models-, and attach a USB hard disk to that, it was thinking the SD card and USB hard disk were part of the same APFS volume, and it was combining the mount points of the two.
That's because they are looking at the devicePath here: balena-io-modules/drivelist@d6b69de
And the devicePath is the same for everything attached to the same USB port on the Mac. It does not take multiple devices connected through a USB HUB into account.

That's why I solved things differently with my "tweak"
I am not entirely happy with my solution either.
It was inspired by internal code Apple released as open source, and does not use well documented APIs, so has the risk of breaking at any future OS X update.
That's why I have not submitted it upstream.

@MrSmoer
Copy link
Contributor

MrSmoer commented Jan 26, 2023 •
edited
Loading

I opened a PR on balena-io-modules/drivelist#421, which adds a field called attachTimestamp which contains the unix timestamps of the devices which are attached.

I already have a fork of rpi-imager that also contains a linux C++ implementation. It just displays the timestamp right after the device's name.
It is tested on Linux native and on Windows and OSX vms with USB-Sticks and usb-passthrough. I will test Windows native soon, but I can only test macos native up to 10.13

On Linux my Multi-Card reader that keep the empty device entries are not a problem because (I guess) udev modifies the device, when an SD-Card is plugged in.

I could not test the issue you are describing with the USB HUB, because I do not have one at hand.

@MrSmoer MrSmoer mentioned this issue Jul 29, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@duanev @lurch @maxnet @adamvleggett @MrSmoer