> On 28 Jan 2022, at 20:40, David Wright <deb...@lionunicorn.co.uk> wrote:
>
> 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.
OK thanks
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.
>
> 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.
>
