Re: no space left on device
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.
Reply to: