The officially official Devuan Forum!

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

[SOLVED] SD Card problem

Hello:

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.

Last edited by Altoid (Yesterday 13:10:12)

Camtaf

Member

Registered: 2019-11-19

Posts: 571  

Re: [SOLVED] SD Card problem

I'm thinking a '32GB' card is about 29GiB in actual fact, so it looks reasonable to me...

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

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

Last edited by Camtaf (Yesterday 13:28:26)

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

@Camtaf
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.

Last edited by Altoid (Today 12:26:05)

dzz

Member

From: Exmouth, South West England

Registered: 2016-12-01

Posts: 127  

Re: [SOLVED] SD Card problem

"64GB" Sandisk Ultra here:

# 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..

rolfie

Member

Registered: 2017-11-25

Posts: 1,517  

Re: [SOLVED] SD Card problem

That download link is perfecty ok.

This is the old GB vs GiB problem.

KindlyDoRight

Member

Registered: 2026-10-05

Posts: 20  

Re: [SOLVED] SD Card problem

I found "testdisk" apt show testdisk useful to reset the correct partition size, after I have botched a partition when resizing it.

Last edited by KindlyDoRight (Yesterday 15:53:26)

Mercury

Member

Registered: 2024-11-14

Posts: 67  

Re: [SOLVED] SD Card problem

To recap:

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)

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

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

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.

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

Will post with results.

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.

greenjeans

Member

Registered: 2017-04-07

Posts: 1,771  

Website

Re: [SOLVED] SD Card problem

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

---

https://sourceforge.net/projects/vuu-do/ Vuu-do GNU/Linux, Devuan-based Openbox systems.
Devuan 6 mate-mini iso, pure Devuan, 100% no-vuu-do. Now with Xlibre as well.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
https://devuanusers.com/ Apps source : https://git.devuan.org/greenjeans

rbit

Administrator

Registered: 2018-06-12

Posts: 162  

Re: [SOLVED] SD Card problem

It may be that the "img" file is of the device, but you're trying to write it to a partition.
What does this show fdisk -l /media/storage/isos/chimaera/rpi_chimaera.img

Mercury

Member

Registered: 2024-11-14

Posts: 67  

Re: [SOLVED] SD Card problem

7.8 vs 7.2 is GB vs GiB and dd reports both. That's not an issue.

31914983424 bytes, 62333952 sectors

That looks right. The sectors are a multiple of 1024, and therefore the total capacity is a multiple of 524,288 bytes, or exactly half a MiB. Searching for the exact values you gave pulls up a lot of google results, so this is standard.

Partitioning and GRUB are not the issue here. If you took an image of the entire device then the image should be the same size as the device capacity. All bootloader and partitioning info (if any) will be part of the image and should not be regarded separately for purposes of dd flashing.

dd if=/media/storage/isos/chimaera/rpi_chimaera.img of=/dev/sdg1

Why are you flashing to a partition here?

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

... the old GB vs GiB problem.

Look close Altoid ...

Yes ...
And see how easy it is to embarass oneself.  8^°

Thank you both.

Best,

A.

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

Sorry for the delayed reply.

... the "img" file is of the device, but you're trying to write it to a partition.

I see.

I did it so:
1. formatted the sd card (clear and then as FAT32 or ext4)
2. remount it and check the device name (with dmesg, Gparted, Disks and lsblk) <- imagine why...*
All these printed [/dev/sdX1], so I used that for [dd].
Made sense to me as the SD Card was not partitioned.
ie: just one single partition

OT ->
When new to Linux, I read about [dd] being called "disk destroyer") so I have always been weary of using it.
But I have used it in a few occasions, inevitably resulting in lack of practise / experience.
Something you may have noticed. 8^°

But I will insist, I think it is a very powerful and versatile tool, just have to learn to master it.
Eventually. * even with all these precautions, I have lost more than one partition table to [dd].
<- OT

... fdisk -l /media/storage/isos/chimaera/rpi_chimaera.img

# fdisk -l rpi_chimaera.img
Disk rpi_chimaera.img: 7.22 GiB, 7757398016 bytes, 15151168 sectors
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: 0xd9d859d0

Device            Boot  Start      End  Sectors  Size Id Type
rpi_chimaera.img1 *      2048   524287   522240  255M  b W95 FAT32
rpi_chimaera.img2      524288 15151103 14626816    7G 83 Linux
# 

I have managed to properly write an image to the sd card using [disks]; boots/works as expected.
[rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img] from the Devuan repository.

# fdisk -l rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img
Disk rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img: 1.82 GiB, 1958482432 bytes, 3825161 sectors
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: 0xd9d859d0

Device                                                Boot  Start     End Sectors  Size Id Type
rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img1 *      2048  524287  522240  255M  b W95 FAT32
rpi-3-devuan-chimaera-5.10.74-v8-ext4-2021-10-19.img2      524288 3825160 3300873  1.6G 83 Linux
# 

I now have to pull configuration and files I need from the last working image which can be mounted with [disks].
Only remaining problem (if I stay with Chimaera) is the repository not working yet.
Again, eventually.

Thanks for your input.

Best,

A.

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

... an image of the entire device then the image should be the same size as the device capacity. All bootloader and partitioning info (if any) will be part of the image ...

I see.

Why are you flashing to a partition here?

See my previous reply to @rbit.

Thanks for your input.

Best,

A.

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

@KindlyDoRight

... useful to reset the correct partition size, after I have botched a partition when resizing it.

Yes, I have used the [testdisk] [PhotoRec] utility to recover files from an accidental [dd] stopped at 1.5MB.

The problem is that losing the directory structure results is an endless stream of [recup_dir.X] directories with a few files in each of them, many times repeated in other directories. ie: a nightmare.
Better than nothing, I guess.

I have yet to find a properly documented (understandable) set of instructions to reset partiton sizes and such operations.
That said, most important step is to make an image of the damaged drive before doing anything with [testdisk].

@dzz

"64GB" Sandisk Ultra here ...

# 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.

Right.

Thank you both for your input.

Best,

A.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 3,000  

Re: [SOLVED] SD Card problem

I have yet to find a properly documented (understandable) set of instructions to reset partiton sizes and such operations.

One or more of these should work.

Restore partition table with sfdisk
https://html.duckduckgo.com/html?q=rest … h%20sfdisk

Altoid

Member

Registered: 2017-05-07

Posts: 2,129  

Re: [SOLVED] SD Card problem

Hello:

One or more of these should work.

Thanks for the heads-up.
Had never heard of [sfdisk] before.

Best,

A.