I thanked the person who responded to my post and reported that
there were no unusual log entries in syslog on the failing system
so not much to go on. I decided to upgrade the Raspberry Pi
which was suddenly having this mysterious problem as I have
backups of the failing system so I figured I'd just clone a
buster image from another Raspberry Pi that is running buster and
use dd to copy it to the Raspberry Pi which was running stretch
and having that weird problem.
Then, assuming the upgraded Pi was alive, I could use the
backup from the stretch system to put all the user space from my
old home directory on the new buster system but I messed up
again. The SSD card from the older system is 28 GB and the
working buster system's SSD card is 32 GB so the smaller card
filled up and I achieved that "no space left on device" state
that we all love to see.
Simple, I thought. I'll just delete all partitions, and
do the dd if=rpi_good.img of=/dev/sdh which is where this card shows
up when it is in the reader and I can maybe dd a smaller 8.5-gb
drive which I have that has almost never been used.
Murphy has struck again. Here is what happens when I try
to use that 28-gb SSD card: Script dump follows
Script started on 2022-01-26 20:03:52-06:00 [TERM="Linux" TTY="/dev/pts/3"
COLUMNS="80" LINES="25"]
1wb5agz martin tmp $ sudo su -
[sudo] password for martin:
root@wb5agz:~# fdisk -l /dev/sdh
/dev/sdh: 28.8 GiB, 30908350464 bytes, 60367872 sectors
Disk model: USB HS-SD Card
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: 0x680226ff
Device[0m [1mBoot[0m [1m Start[0m [1m End[0m [1m Sectors[0m
[1m Size[0m [1mId[0m [1mType[0m
/dev/sdh1 8192 137215 129024 63M c W95 FAT32 (LBA)
/dev/sdh2 137216 62333951 62196736 29.7G 83 Linux
root@wb5agz:~# fdisk /dev/sdh
Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdh: 28.8 GiB, 30908350464 bytes, 60367872 sectors
Disk model: USB HS-SD Card
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: 0x680226ff
/dev/sdh1 8192 137215 129024 63M c W95 FAT32 (LBA)
/dev/sdh2 137216 62333951 62196736 29.7G 83 Linux
Command (m for help): d
Partition number (1,2, default 2):
Partition 2 has been deleted.
Command (m for help): d
Selected partition 1
Partition 1 has been deleted.
Command (m for help): w
fdisk: failed to write disklabel: Operation not permitted
root@wb5agz:~# logout
2wb5agz martin tmp $ exit
Script done on 2022-01-26 20:07:59-06:00 [COMMAND_EXIT_CODE="1"]
So close and yet so far away. If I try to use dd on
/dev/sdh again, I get:
1wb5agz martin tmp $ sudo dd if=~/rpi/rpi2_good.img of=/dev/sdh
[sudo] password for martin:
dd: writing to '/dev/sdh': Operation not permitted
1+0 records in
0+0 records out
0 bytes copied, 0.021666 s, 0.0 kB/s
2wb5agz martin tmp $ exit
I've had usb thumb drives fail when filled to capacity
and, if I hadn't been tired, I would have noticed that the image
was 4 gb too large so this wouldn't have happened but surely,
there is some way to at least zero out everything so the SSD can
be either reformatted or used as the output of an image transfer
using dd.
The SSD passed a fsck test earlier in the day before I
blew it up so the chip should be salvageable. I don't care for
recovering either of the two partitions which will be overwritten
anyway if the SSD can be made writable again.
One can mount /dev/sdh1 which is the fat32 partition
but it mounts as read-only. If you try /dev/sdh2, you get a
squawk that says that this partition is not in /etc/fstab which
is certainly true but it doesn't mount either so mount doesn't
understand what I was trying to do. This is the partition that
got the overflow condition so it's utterly useless.
These last 2 days, I have been a day late, a Dollar short
and 1 step behind on what shouldn't be really that big of a problem.
Martin WB5AGZ
