Yes, /dev/nvme0n1 comes from the onboard M2 socket (where the drive was
populated with data) and /dev/sdb comes from USB adaptor used to connect
the same drive to a different Ubuntu desktop.
Output from the first (/dev/nvme0n1 on board) loadout.
$ sudo lsblk --fs -o +SIZE
NAME FSTYPE FSVER LABEL UUID
FSAVAIL FSUSE% MOUNTPOINTS SIZE
loop0 squashfs 4.0
0 100% /snap/core20/2379 64M
loop1 squashfs 4.0
0 100% /snap/bare/5 4K
loop2 squashfs 4.0
0 100% /snap/core20/2434 63.7M
loop3 squashfs 4.0
0 100% /snap/core22/1663 73.9M
loop4 squashfs 4.0
0 100% /snap/core22/1722 73.9M
loop5 squashfs 4.0
0 100% /snap/gnome-3-38-2004/119 346.3M
loop6 squashfs 4.0
0 100% /snap/gnome-3-38-2004/143 349.7M
loop7 squashfs 4.0
0 100% /snap/gnome-42-2204/176 505.1M
loop8 squashfs 4.0
0 100% /snap/gtk-common-themes/1535 91.7M
loop9 squashfs 4.0
0 100% /snap/snap-store/1113 12.9M
loop10 squashfs 4.0
0 100% /snap/snap-store/1216 12.2M
loop11 squashfs 4.0
0 100% /snap/snapd/23258 44.3M
loop12 squashfs 4.0
0 100% /snap/snapd/23545 44.4M
loop13 squashfs 4.0
0 100% /snap/snapd-desktop-integration/247 564K
loop14 squashfs 4.0
0 100% /snap/snapd-desktop-integration/253 568K
sda
953.9G
├─sda1 vfat FAT32 D7C9-A88E
487.3M 5% /boot/efi 512M
└─sda2 ext4 1.0 7258149c-b137-4855-b4d8-44dfb426e1f9
208G 73% / 953.4G
sdb
7.3T
└─sdb1 ext4 1.0 ARCHIVE-1 8186b203-86ce-439c-a2e7-988e121ea53b
7.3T
nvme0n1 exfat 1.0 6786-F242
3.6T
There are other disks on board: 1TB sda (SSD) and 8TB sdb (HDD).
On the same system I get:
$ sudo file -s /dev/nvme0n1
/dev/nvme0n1: DOS/MBR boot sector
...and I'm pretty sure I initialised the drive with GPT partition table.
It would be enough to somehow mount it in the current loadout and copy
the data to another spare 2 TB SSD. That would save me 3 days spent
waiting for the data to be processed.
The drive was mounted there and everything worked up until a reboot.
So maybe there is a way to remount it?
On 20/01/2025 15:44, Max Nikulin wrote:
On 20/01/2025 20:37, Adam Weremczuk wrote:
sudo mount /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on
/dev/ nvme0n1, missing codepage or helper program, or other error.
Is it for the drive plugged directly into a M.2 slot or through a USB
adapter? In the latter case you should mount something like /dev/sdb.
Notice that Dan suggested to explicitly specify filesystem type to mount
(-t exfat). Review drives you have connected
lsblk --fs -o +SIZE
I have tried a USB pendrive with exfat partition
file -s /dev/sdb1
/dev/sdb1: DOS/MBR boot sector
Perhaps it is due to "AA55h" signature in 510 and 511 bytes just like in
MBR partition table
<https://learn.microsoft.com/en-gb/windows/win32/fileio/exfat-specification#3120-bootsignature-field>
So tools unaware of filesystem name in 3-10 bytes may be confused. Maybe
they do not expect a "superfloppy" and take MBR with no partitions
hypothesis first.
