Am Montag, 20. Januar 2025, 17:04:52 CET schrieb Adam Weremczuk: I am not sure, but this looks very weired for me. What are these loop- partitions? It looks like you are usinng an Ubuntu-Livesystem, do you?
I am not much friend of Ubuntu, as they sometimes do weired things (IMHO), but if I understzand you ciórrectly, you just want to transfer data from one drive to another. If so, maybe you might want to use another live system. Debian-live maybe ok, but I never worked with it, so there is not much experience by me. My favourite for such things is Knoppix and (but my self build KALI-Linux), both livesystems are working very well and got modern kernels. If you want clone a complete Linux-System from an SSD to an NVME-drive, you can use gparted. However, the linux part may not boot until you edited /etc/ fstab and (if encrypted partitions) /etc/crypttab, but this is another story. If you just want to transfer firles from one harddrive to another, use a lifesystem, format the new omne to your needs (for linux I suggest ext2/3/4 and for Windows I suggest exfat) and then use rsync for copying. Note: some days ago I got an USB-stick with exfat oin, but it could not be mounted. So I had to delete the partitiontable and create a new one, then format with exfat (using gparted) and everything worked again like a charm. Hope this helps!? Best Hans > 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-specificatio > > n#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.
