On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote: > David Wright <deb...@lionunicorn.co.uk> writes: > > I've not heard of that problem. You were prevented from zeroing the > > entire device, which would have wiped the partition table anyway. > > > > What I would want to check is that the OS isn't doing something > > stupid, like trying to automount it, failing, and consequently > > setting the device readonly. By OS, I really mean DEs, or > > automounters in general. > > > > You could also try zeroing it in another machine, ± any adapters > > required. (Bear in mind that adapters do have readonly sliders.) > > I suspect this is the crux of the problem. the adapter I > connected is a card reader. You put the SSD in a little plastic > jacket that holds the SSD in such a way that the card reader can > access the edge connector but the holder jacket has no electronics. > There is a small notch in the plastic of the jacket on the left > edge and the right front corner of the plastic carrier has a > diagonal cut to prevent someone from putting it in upsidedown.
Yes, most connectors are keyed in some way, though some are quite fragile, like the plastic post in PS/2 keyboards and mice. > Since I posted, there is good news but I still wonder if > I am not going bonkers because after unplugging the Sony card reader > and plugging it back in, I now am getting device /dev/sdg instead > of /dev/sdh. I was also able to do the following: > > #sudo fdisk /dev/sdg > > which gave me the fdisk utility as before so I did what crazy > people do which is to do the same thing as before, hoping for > different results. That's why people are encourages to use [PART]UUIDs and [PART]LABELs instead of dynamically chosen kernel names. Pulling the card could reset a gate, or it could clean the contacts. Who knows. I would tend to mark down the card as suspect, and not use it in mission-critical ways. > By Joe, I got them. > > I typed d to delete a partition and it put partition 2 up as the > default candidate as before so I selected it and then typed d > again which told me that only partition 1 was left so it was > deleted. > > I had gotten this far before so wasn't too excited but type > w and this time got the message stating that the partition table > had been rewritten and fdisk then exited. > > Now, doing sudo fdisk -l /dev/sdg yields > > 1wb5agz martin tmp $ sudo fdisk -l /dev/sdg > Disk /dev/sdg: 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 > > The partitions are gone. My latest screwball theory is > that the Sony card reader went in to some sort of protective mode > after the dd operation overwrote the device. My unplugging the > reader and plugging it back in reran the driver which reset the > protective mode back to normal which may be why it all worked > right this time. Who knows. > One last question: Since the image will still be too > large as it is, can tunefs be run on it or a copy of it to shrink > about 4 gb of user space? The good system I copied the image > from only had about 12% of the partition used so I should be > able to transplant it to the smaller disk if tunefs can do that > and still leave a bootable device. I don't know what this image contains, but I'm guessing it's the rootfs for the Pi. My question then is how full was it. I assume that you don't run it to 100% usage, and even then, there are files you can do without, like rotated logfiles, caches etc. Two different methods: One course of action would be to copy the old to the new card, just as you have done, with dd running out of space. That deals with three things: the MBR, the partition table, and the first partition (whatever that it). Next, I would fdisk it, delete partition 2 and recreate it so that its size matches the partition table entry. Recreate a filesystem with mkfs. Next, I copy the entire contents of the second partition from the old card to the new, using copy -a or rsync … or whatever you're comfortable with. This assumes, I think, that you don't have weird things like sparse files and so on. If you run out of space, then you may need to prune your target to make sure the essential files (like /etc, /usr) are copied, and be more selective with other trees, like parts of /var, /home. A second course of action would be to copy the entire card to file on a disk, loop mount it, and reduce the contents of the second partition so that you know there'll be room for it on the new card. Then dd from the image file to the new card as in the first method, amend the partition table on the card, recreate the filesystem, and copy the files from the loop mount to the card. Whether either method is worthwhile is obviously moot, but it's good practice in ingenuity with the tools at hand. Cheers, David.
