On Fri 28 Jan 2022 at 18:22:37 (+0000), Gareth Evans wrote: > > On 28 Jan 2022, at 18:16, Gareth Evans <donots...@fastmail.fm> wrote: > >>> On 28 Jan 2022, at 16:52, David Wright <deb...@lionunicorn.co.uk> wrote: > >>> 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 ... > > > > I've been anticipating this stage and looking for solutions to confirm what > > I thought the process might be. > > > > If a smaller card and the dd approach are to be used, don't you have to > > loop mount the image file, resize the fs in the relevant partition, shrink > > the partition so that all partitions together are <= card capacity, then > > truncate the image file before dd-ing? > > > > None of the answers I've found on stackexchange etc mention the shrinking > > the partition step. > > ... that is, for the objective of dding a buster backup image, which was > mentioned earlier
Take a look at the diagram at the top right of: https://en.wikipedia.org/wiki/GUID_Partition_Table In a GPT-partitioned device, you have to worry about the secondary partition table right at the end of the address space. No such worries with an MBR-partitioned one. When you dd the larger card to the smaller one, all the essential structures at the start of the card will be copied intact: the MBR, the partition table itself, and any code buried in unpartitioned space, eg second-stage Grub and suchlike. Now think about what gets lost: the last 4GB of the last partition. And that's why we throw that partition away, recreate it (which corrects the partition table) and repopulate it, by copying the files, /not/ by copying the filesystem. So this makes all the shrinking and truncating irrelevant: you're just messing about with the part of the image that is never used. > >> ... 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. Of course it makes sense to start afresh with a new card. They aren't expensive and they're so tiny as to be hardly wasteful of resources. But what's your stopgap for when you're cut off from supplies? Cheers, David.
