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