Problem after wiping and reformatting an external portable device with openSUSE LEAP

English Hardware
1

Hello, everybody,

In order to back-up my system, I wanted to wipe and reformat an external portable disk (Intenso, portable ssd). The identifier of the disk was /dev/sda1. So I used dd in order to erase all data on the disk, using the command

 sudo dd if=/dev/zero of=/dev/sda1 bs=4M status=progress

Then I created a new partition table on the disk using fdisk:

sudo fdisk /dev/sda1

with the options:

g (for GPT)
n (for creating a new partition)
using the suggested defaults for the size (which I don’t remember now).

But now I can’t access this disk, even with root privileges. I can see it as hardware when I use lsblk -l:

~> lsblk -l
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda         8:0    0 476.9G  0 disk 
sda1        8:1    0 476.9G  0 part

But I can’t detect it when I use df -h:

~> df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  169G   21G  145G  13% /
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           7.6G     0  7.6G   0% /dev/shm
efivarfs        374K  168K  202K  46% /sys/firmware/efi/efivars
tmpfs           3.1G   11M  3.0G   1% /run
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-sysctl.service
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev.service
/dev/nvme0n1p2  169G   21G  145G  13% /.snapshots
/dev/nvme0n1p2  169G   21G  145G  13% /boot/grub2/i386-pc
/dev/nvme0n1p2  169G   21G  145G  13% /boot/grub2/x86_64-efi
/dev/nvme0n1p2  169G   21G  145G  13% /opt
/dev/nvme0n1p2  169G   21G  145G  13% /root
/dev/nvme0n1p2  169G   21G  145G  13% /srv
/dev/nvme0n1p2  169G   21G  145G  13% /tmp
/dev/nvme0n1p2  169G   21G  145G  13% /usr/local
/dev/nvme0n1p2  169G   21G  145G  13% /var
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-vconsole-setup.service
/dev/nvme0n1p1  511M  6.3M  505M   2% /boot/efi
/dev/nvme0n1p3  301G  126G  160G  45% /home
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs           1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs           1.6G   76K  1.6G   1% /run/user/1000

And when I try to mount it as root into /mnt, I get this error message:

sudo mount /dev/sda1 /mnt
[sudo] password for root: 
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

So I took a look into dmesg, and this is the bottom of the output right after trying to mount the disk:

 287.131363] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
[  287.152861] usb 2-2: New USB device found, idVendor=152d, idProduct=0579, bcdDevice= 5.06
[  287.152868] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  287.152870] usb 2-2: Product: Portable SSD
[  287.152873] usb 2-2: Manufacturer: Intenso
[  287.152874] usb 2-2: SerialNumber: 2025081110223
[  287.759917] SCSI subsystem initialized
[  287.768872] alua: device handler registered
[  287.770689] rdac: device handler registered
[  287.772822] emc: device handler registered
[  287.785112] usbcore: registered new interface driver usb-storage
[  287.790465] scsi host0: uas
[  287.790657] usbcore: registered new interface driver uas
[  287.791077] scsi 0:0:0:0: Direct-Access     Intenso  Portable SSD     0506 PQ: 0 ANSI: 6
[  287.793575] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  288.295265] sd 0:0:0:0: [sda] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
[  288.295276] sd 0:0:0:0: [sda] 4096-byte physical blocks
[  288.295469] sd 0:0:0:0: [sda] Write Protect is off
[  288.295473] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[  288.295846] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  288.343495] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[  288.343505] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[  288.345151]  sda: sda1
[  288.345315] sd 0:0:0:0: [sda] Attached SCSI disk
[  663.384619] BTRFS info (device nvme0n1p2): qgroup scan completed (inconsistency flag cleared)
[ 1784.890549] request_module fs-minix succeeded, but still no fs?

So now I don’t know what to do. Does anyone have an idea? I’d much appreciate any help.

Cheers,
Barbara

2

Did you miss create/make filesystem after partitioning?
Try cfdisk

Bildschirmfoto_20260929_074751
Bildschirmfoto_20260929_0747511124×720 54.2 KB

3

Oh, I forgot to provide one piece of information. After using fdisk to create a GPT partition table, I also formatted the disk using mkfs.exfat in order to format it with an exFAT file system:

~> sudo mkfs.exfat -L Intenso /dev/sda1
4

I tried that, but the cfdisk command also only yields an error message:

~> sudo cfdisk
[sudo] password for root: 
cfdisk: cannot open /dev/sda: No such file or directory
5

Should have been of=/dev/sda
I think you start again with partitioning.
Or start with dd copiing some starting sector of a fuctioning device.

6

Not a solution but try lsblk instead of df, it’s output is much clearer.

I did also add part labels so my output shows:

$ lsblk -o  +FSTYPE,PARTLABEL
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS   FSTYPE      PARTLABEL
sda             8:0    0 931.5G  0 disk                crypto_LUKS 
nvme1n1       259:0    0   1.9T  0 disk                            
├─nvme1n1p1   259:1    0     1G  0 part  /boot/efi     vfat        lexar_boot_efi
├─nvme1n1p2   259:2    0     1G  0 part  /boot         ext4        lexar_boot
├─nvme1n1p3   259:3    0   100G  0 part  /             xfs         lexar_root
├─nvme1n1p4   259:4    0   150G  0 part                xfs         lexar_data
└─nvme1n1p5   259:5    0   1.5T  0 part                crypto_LUKS lexar_home
7

You may even plug/unplug device and check
lsusb
e.g.
Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s

8

You may act on device, not partition.

9

That is not true. /dev/sda1 can only point to a partition of disk /dev/sda.

I have no idea why you want to “wipe it”, but you have written all zero bytes to the whole of that partition.

That is wrong. One normally creates a partition table on a disk, in this case /dev/sda. Now you have left the partition table on the disk untouched had you have created a partition table on the partition /dev/sda1, which is a bit strange to do (and I know of no use case for that).

You see that sda (the disk) has a partition table with one partition sda1 on it. That was apparently already the case before you started this exercise.

df works only on mounted file systems. I have no idea what you expect here.

There is no file system on /dev/sda1(as the system expects), there is a partition table there. .

So better start all over again and create a fresh partition table on /dev/sda (and there is no need to “wipe” anything) with the partition(s) you need.

Then you still have no file system on it, thus create a file system on /dev/sda1 with the appropriate tool (like mkfs).

After that you might be able to mount that file system (e.g. on /mnt if that is what you want).

After that you can use the space there (and even look at it with df -h).

10

Many thanks to all of you. My mistake was small but pretty stupid, and after fixing it it’s working now. But let me explain something first and then I’ll summarize the status quo:

(1) I intentionally wiped the ssd in order to make the data that was on it un-recoverable. It was sensitive data that I didn’t want to be accessible in any way to anyone using the ssd.
Using dd is one option to do so. You copy zero bytes onto it. It’s called a ‘single-pass wiping’, overwriting the data with zeros. But it’s true, I think I used the command in the wrong way by specifying the outputfile (‘of’) incorrectly. At this stage, I don’t know now if the original data is unrecoverable.

(2) Summary: My problem was one of terminology: disk versus device. So the thing that I did wrong was that I attempted to create a new partition table on the partition (a device) instead of creating it on the disk. In other words: I ran the fdisk command on /dev/sda1 (a device) instead of on /dev/sda (the disk itself). And so I want to thank hcvv in particular for spotting this error!

After I changed this small but crucial fact, everything worked in the expected way. And now the system automatically mounts the ssd, and all is good. And thus, it’s now also listed under df:

~> df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       477G  566M  477G   1% /run/media/barbara/Intenso

A million thanks from a relieved user,
Barbara

2 Likes
11

That is of course a good reason. But you described it as an important part of your action. In fact it was a separate action that has nothing to do with the re-partitioning you wanted.
Overwriting /dev/sda1 is is good as overwriting /dev/sda for the case of destroying the data of course. Only in the second case the partition table will also be gone (but I assume that is not sensitive data).

Only problem with regards to your sensitive data is that I am not sure that works as intended on SDD hardware. You should check that. In any case, the creation of the new file system will write on a lot of places over what was there. I guess that when you are not afraid of secret services and the like to be after the information, for all others, you are OK.

12

SSDs store data in random places and maintain tables to convert external “cylynder-head” addresses to actual memory cell clusters. Once you have overwritten the whole space with zeros you have zeroed out every memory cell and recreated new translation tables, so AFAIK anybody willing to recover old data should scan the chip surface with a scanning electron microscope and even if variations in cell charge would surface, it would likely translate to garbage.

Different story on rotating rust, where accurate analog scanning of the disk surface might still reveal patterns of the old data, so it makes sense to write multiple times random data to the whole disk to protect extremely sensitive data. That needs special equipment, not necessarily “secret service” stuff but nothing an ordinary user can access.
On rotating rust when you just “delete” the contents without overwriting, you just wipe the partition table but data is still there and a good retail “recovery software” might be able to recover much of it.

[Disclaimer: I’m not on any Secret Service payroll, so I might underestimate their current technology or capability]

13

While dd is good for a simple overwrite, there is also shred, see

man shred
14

If you put sensitive data on a storage media the best way to protect it is to use encryption.

This will not only protect your data while the storage media is working fine. Even when your storage media fails (i.e. you can’t access its content due to a technical failure and therefore cannot override the content either) some expert may be able to recover the data but the data will be useless as it is still encrypted.

4 Likes
15

Thanks for the additional information! I originally provided the information about using dd since I had no clue whatsoever, what might have caused my problems. And since people warn you about dd and how powerful it is and sometimes even re-name it as “destroy disk” there was some sort of worry in me that this might just have completely destroyed my ssd.

But I am really glad about your discussion about erasing data, and about the dd command since I’m not only relieved that my ssd is working properly now, I’m also relieved that the original data is unrecoverable (at least for about 99.99% of all computer users, if not for 100%). The secret services may have it–it was about research participants and not about myself. But I vowed that I would protect these data, so I was morally (and probably legally too) obliged to erase the data in a non-recoverable way before using the ssd for another purpose.

So all in all: I learned a lot and am thankful to all of you for sharing your knowledge with me!

16

That is a pretty good advise and should be considered for newly installed systems. There’s no notable lack of performance due to FDE on modern systems for common use.

When it’s up to “wiping” a mass storage I use:

But you only can wipe a storage, when you actually have access. When there are serious HW problems, it could be too late. Then, a FDE would have helped. I consider this a true advantage for a system internal mass storage.

17

They confused it with a “hammer”.