Also:

sudo mount -t exfat /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.

makes no difference.


On 20/01/2025 16:04, Adam Weremczuk wrote:
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.




Reply via email to