This is the old GB vs GiB problem.

Yep.

The GB (Gigabyte) is decimal system and equals 1,000,000,000 bytes. The GiB (Gibibyte) is binary system and equals 1,073,741,824 bytes.

Look close Altoid : 7.8 GB, 7.2 GiB

Unfortunately, I am getting the same results I posted previously.

This is the [dd] process:

# dd if=/media/storage/isos/chimaera/rpi_chimaera.img of=/dev/sdg1 bs=4M status=progress
7755268096 bytes (7.8 GB, 7.2 GiB) copied, 668 s, 11.6 MB/s^[[B
1849+1 records in
1849+1 records out
7757398016 bytes (7.8 GB, 7.2 GiB) copied, 787.312 s, 9.9 MB/s
# 

ie: all records written but only 7.2 GB of 7.8 GB copied. <-- what did not get copied?

# mount /dev/sdg1 /mnt/SD
mount: /mnt/SD: wrong fs type, bad option, bad superblock on /dev/sdg1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.
# 

As I was able to install an old Devuan Beowulf and boot without issues it would seem that the SD Card is working properly,
I will try to burn and [*iso] file to see what happens.

Will post with results.

Best,

A.

Yes to all.

There's still more:
While [dd] prints that all records have been written [1849+1 records in / 1849+1 records out], at the same time it prints that of the 7.8 GB that had to be copied, only 7.2 GB had been written [(7.8 GB, 7.2 GiB) copied].

# dd if=/media/storage/isos/chimaera/rpi_chimaera.img of=/dev/sdh1 bs=4M status=progress
7757398016 bytes (7.8 GB, 7.2 GiB) copied, 577 s, 13.4 MB/s
1849+1 records in
1849+1 records out
7757398016 bytes (7.8 GB, 7.2 GiB) copied, 703.66 s, 11.0 MB/s
#

Also, if I try to mount the card, I get this:

# mount /dev/sdh1 /mnt/SD
mount: /mnt/SD: wrong fs type, bad option, bad superblock on /dev/sdh1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.
# 

[dmesg] prints the same data.

Curiously enough I was able to install an old [Beowulf] netinstall but stopped short of installing [LiLO] because GRUB was not offered as an option.

So what's up with my not being to install [*.img] files?
I insisted with the Beowulf installation this time in automatic mode and (lo and behold) I was able to install it, booting just fine.

Here is what [fdisk -l] and [df -h] print:

Disk /dev/sdg: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Disk model: Storage Device  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb403ed78

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdg1  *     2048 62332927 62330880 29.7G 83 Linux

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdg1        30G  607M   27G   3% /mnt/SD
# 

I can also mount it manually with no issues:

# mount /dev/sdg1 /mnt/SD
# cd /mnt/SD
# ls
bin   dev  home        initrd.img.old  lib64	   media  opt	root  sbin  sys  usr  vmlinuz
boot  etc  initrd.img  lib	       lost+found  mnt	  proc	run   srv   tmp  var  vmlinuz.old
# 

So the next test would be to see if installing [GRUB] to the card has cleared out whatever was causing the problem.
ie: any one (or more) of these: wrong fs type, bad option, bad superblock on /dev/sdh1, missing codepage or helper program, or other error.

Will post with results.

Best,

A.

You took a dd image of this device. Now your are trying to write that image using dd back to the same device but you are getting the error that there is insufficient space. Correct?

It's natural to blame the device since cards like this are known for failing, and that's if they're even legitimate. However, I'm wondering if something about the image you took is the problem. Maybe it somehow got "padded out".

Exactly how large (in bytes or sectors) is the card, and exactly how large is the image?

Look at the image itself. Is the end filled with zeroes or does it contain data? (I use wxHexEditor for such things but other tools exist)

This is the old GB vs GiB problem.

# fdisk -l /dev/sdc
Disk /dev/sdc: 57.3 GiB, 61530439680 bytes, 120176640 sectors
Disk model:  SanDisk 3.2Gen1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8776131b

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdc1  *     2048 120176639 120174592 57.3G  c W95 FAT32 (LBA)

Gparted also reports 57.3G. Never mind, it works.

! That link is a M$ platform executable..

Thanks for the link, but [uBlock] gives me a warning, probably false.

That said, the card is an original/store purchased Sandisk Ultra which worked perfectly well until I screwed it up.
If there was some issue with respect to its real capacity or provenance it would have shown up once I used it for the first time.

Methinks there is something else afoot here ...

Best,

A.

(I think you should be able to check the SD card with an online checker.)

Or, maybe this - https://h2testw.org/

I think I sort-of-ish screwed up the 32Gb SD Card I use in my RPi3B+ by attempting to resize the first 128Mb partition.
The result was that while [df -h] reported a size of 128Mb, [fdisk -l] reported a size of 256Mb.

The RPi booted/worked properly but thinking the discrepancy (ie: filesystem smaller than the partition it occupied) would eventually become a problem, I messed it up.

Have to rewind a bit and see if I can remember exactly what I did last night.

No problem (said I feeling smug ...) I had previously made an image albeit with the discrepancy included.
But as it was an image of a working system, I was confident I could recover it and just live with it.

Not so.
An attempt to write the image with the [Disks) utility gave me an error: the image was 1.6Mb larger than the available space.

No problem, (said I, still feeling smug) I'll just [dd if=/dev/zero] the saylights out of it and problen solved.
Not so.

Here is the printout of the process:

# dd if=/dev/zero of=/dev/sdg bs=4M status=progress
31910264832 bytes (32 GB, 30 GiB) copied, 2818 s, 11.3 MB/s
dd: error writing '/dev/sdg': No space left on device
7610+0 records in
7609+0 records out
31914983424 bytes (32 GB, 30 GiB) copied, 2928.4 s, 10.9 MB/s
# 

Unless I am mistaken, it would seem that the size discrepancy has been baked into some part of the sd card I have not been able to access with [dd] and as a result it reads the card and computes that it can write 32Gb worth of zeroes to it but something in the card says that its size is 30Gb and throws an error. ie: No space left on device

Edit:

Attempting to [dd] the [2026-09-15-raspios-trixie-arm64-lite.img] downloaded fron the Raspberry website gets me this:

# dd if=/media/storage/isos/RPi/2026-09-15-raspios-trixie-arm64-lite.img of=/dev/sdg1 bs=4M status=progress
3057647616 bytes (3.1 GB, 2.8 GiB) copied, 261 s, 11.7 MB/s
730+0 records in
730+0 records out
3061841920 bytes (3.1 GB, 2.9 GiB) copied, 386.086 s, 7.9 MB/s
# 

In this case, [dd] does not copy all the data but 2.0Gb less, just like before.
ie: 30Gb of 32Gb copied.

Maybe it is not being able to write to the partition table space?

Any idea as to how to solve this?

Best,

A.