Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #244590 > unrolled thread

The Raspberry Pi that Took a Day Off.

Back to article view | Back to linux.debian.user

Contents

  The Raspberry Pi that Took a Day Off. "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-25 15:40 +0100
    Re: The Raspberry Pi that Took a Day Off. Gareth Evans <donotspam@fastmail.fm> - 2022-01-26 18:20 +0100
      SSD Memory Card (was  The Raspberry Pi that Took a Day Off.) "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-27 21:30 +0100
        Re: SSD Memory Card (was  The Raspberry Pi that Took a Day Off.) Charles Curley <charlescurley@charlescurley.com> - 2022-01-27 23:00 +0100
          Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-28 00:00 +0100
            Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) David Wright <deblis@lionunicorn.co.uk> - 2022-01-28 01:40 +0100
              Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-28 14:40 +0100
                Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) Michael Stone <mstone@debian.org> - 2022-01-28 15:10 +0100
                Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-28 15:20 +0100
                Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) David Wright <deblis@lionunicorn.co.uk> - 2022-01-28 18:00 +0100
                  Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) Gareth Evans <donotspam@fastmail.fm> - 2022-01-28 19:20 +0100
                    Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) Gareth Evans <donotspam@fastmail.fm> - 2022-01-28 19:30 +0100
                      Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) David Wright <deblis@lionunicorn.co.uk> - 2022-01-28 21:50 +0100
                        Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) Gareth Evans <donotspam@fastmail.fm> - 2022-01-29 20:10 +0100
                        Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-29 23:40 +0100
                          Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-30 08:00 +0100
                  Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-28 19:50 +0100
                    Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) Michael Stone <mstone@debian.org> - 2022-01-28 21:50 +0100
                      Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.) <tomas@tuxteam.de> - 2022-01-29 08:10 +0100
        Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) Bijan Soleymani <bijan@psq.com> - 2022-01-28 01:30 +0100
          Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) "Martin McCormick" <martin.m@suddenlink.net> - 2022-01-28 03:00 +0100
            Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) Jeremy Ardley <jeremy@ardley.org> - 2022-01-28 03:20 +0100
            Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.) Bijan Soleymani <bijan@psq.com> - 2022-01-28 03:30 +0100
        Re: SSD Memory Card (was  The Raspberry Pi that Took a Day Off.) <tomas@tuxteam.de> - 2022-01-28 07:40 +0100
          Re: SSD Memory Card (was  The Raspberry Pi that Took a Day Off.) "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-28 14:10 +0100

Page 1 of 2  [1] 2  Next page →

#244590 — The Raspberry Pi that Took a Day Off.

This Pi is running Debian Stretch.  I believe that's what version
9 is called.  I have it capturing audio from a radio receiver and
it's been doing that for several years now and it was doing that
yesterday morning.  Later in the day, I downloaded more audio
and, after a long pause, I got the message from ssh that the
Raspberry Pi wasn't there any longer so I retrieved the Pi from
the room where it was and brought it to my Debian desktop system
to work on it.

	I could login to the Pi which seemed to be up and running
but the short story is that it couldn't talk to any address but
our router.    I couldn't even ping it's interface from the Pi,
itself.

	If I was on the Raspberry Pi's console, everything looked
normal as long as one wasn't using the TCP/IP interface.  You
could even do a ip addr or an ipconfig -a command and it would
show that it had gotten the correct address from our dhcp server
which is in the router.  It would successfully ping the router
but no other addresses, not even the address it uses on our
network.

	I finally quit messing with it and went to bed but fired
it up again today, January 25 and low and behold, it just came
right up and is now back doing what it has been doing.

	Is it possible that it got a corrupted lease for dhcp
from the router?  Dhcp leases on our Netgear router are issued
for not quite 24 hours so it may have gotten a bad lease, kept
renewing it for the time it was powered up and then it got a new
version of that lease today and all is well.

	It's the same IP address because I have put it in the
router as a static IP address.

	The other thing that is weird is that the Raspberry Pi in
question has both a wired Ethernet and a WiFi interface and both
were misbehaving identically.

	Normally, the wired port is not used and the dhcp lease
renewal process happens over WiFi.

	The results of ip addr always showed a correct subnet
mask and the only rules in iptables are the 2 default rules.  In
other words, all looked normal except that it didn't work.

	While I had it on the work bench, so to speak, I ran fsck
-fy on the SSD card since it has been a couple of years since I
last did that and there was not a single squawk about anything.

	Thanks for any ideas about how things got wrong and then
magically fixed themselves.

	When I turned it off last night, I gave it the halt -p
command.  The power supply has no switch so I unplugged it from
power so it started fresh about 8 hours later.

Martin     WB5AGZ

[toc] | [next] | [standalone]

#244633

> On 25 Jan 2022, at 14:17, Martin McCormick <martin.m@suddenlink.net> wrote:
> 
> This Pi is running Debian Stretch.  I believe that's what version
> 9 is called.  I have it capturing audio from a radio receiver and
> it's been doing that for several years now and it was doing that
> yesterday morning.  Later in the day, I downloaded more audio
> and, after a long pause, I got the message from ssh that the
> Raspberry Pi wasn't there any longer so I retrieved the Pi from
> the room where it was and brought it to my Debian desktop system
> to work on it.
> 
>    I could login to the Pi which seemed to be up and running
> but the short story is that it couldn't talk to any address but
> our router.    I couldn't even ping it's interface from the Pi,
> itself.
> 
>    If I was on the Raspberry Pi's console, everything looked
> normal as long as one wasn't using the TCP/IP interface.  You
> could even do a ip addr or an ipconfig -a command and it would
> show that it had gotten the correct address from our dhcp server
> which is in the router.  It would successfully ping the router
> but no other addresses, not even the address it uses on our
> network.
> 
>    I finally quit messing with it and went to bed but fired
> it up again today, January 25 and low and behold, it just came
> right up and is now back doing what it has been doing.
> 
>    Is it possible that it got a corrupted lease for dhcp
> from the router?  Dhcp leases on our Netgear router are issued
> for not quite 24 hours so it may have gotten a bad lease, kept
> renewing it for the time it was powered up and then it got a new
> version of that lease today and all is well.
> 
>    It's the same IP address because I have put it in the
> router as a static IP address.
> 
>    The other thing that is weird is that the Raspberry Pi in
> question has both a wired Ethernet and a WiFi interface and both
> were misbehaving identically.
> 
>    Normally, the wired port is not used and the dhcp lease
> renewal process happens over WiFi.
> 
>    The results of ip addr always showed a correct subnet
> mask and the only rules in iptables are the 2 default rules.  In
> other words, all looked normal except that it didn't work.
> 
>    While I had it on the work bench, so to speak, I ran fsck
> -fy on the SSD card since it has been a couple of years since I
> last did that and there was not a single squawk about anything.
> 
>    Thanks for any ideas about how things got wrong and then
> magically fixed themselves.
> 
>    When I turned it off last night, I gave it the halt -p
> command.  The power supply has no switch so I unplugged it from
> power so it started fresh about 8 hours later.
> 
> Martin     WB5AGZ
> 

Hi Martin,

Are your router logs accessible?

Is there anything of potential relevance in those or the pi logs around the time it stopped/restarted 'connecting' (or even in the interim)?

Perhaps

cat /var/log/syslog{.n} | grep -i dhcp

might be a start, where {.n} indicates an optional eg. .1, .2 etc if syslog itself no longer contains logs from the relevant time.

The router may have a web interface that includes a section for errors if you can't get into it with ssh.  Not sure how helpful that might be even if one exists, but  maybe worth a look.

Gareth

[toc] | [prev] | [next] | [standalone]

#244692 — SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

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     Boot  Start      End  Sectors  Size Id Type
/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

[toc] | [prev] | [next] | [standalone]

#244694 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Wed, 26 Jan 2022 21:07:31 -0600
"Martin McCormick" <martin.m@suddenlink.net> wrote:

> 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'm no expert on RPis, but that sounds to me like the SD card is
protected against writes. Check for any physical write protection
switches on the card itself and the holder.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#244698 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

Charles Curley <charlescurley@charlescurley.com> writes:
> I'm no expert on RPis, but that sounds to me like the SD card is
> protected against writes. Check for any physical write protection
> switches on the card itself and the holder.

Thanks for the suggestion, but this is one of those SSD cards
that often is found in a camera and resembles a wafer the size of
a thumbnail.  It has a projection that acts as a key way to keep
a user from inserting it in the wrong way and there is a groove
for a fingernail to help pull the chip out of the socket.  This
particular one was reading and writing just fine until I bricked
it by the DD that must have overwritten some address which now
makes it unwritable.  It went from good to bad without my
removing it from the card reader so there should be some way to
at least clear it for writing again.

	Apparently, it stops being writable if the partition
table is corrupted.  In my case, I just want to delete both
partitions and start over.

	The OS is debian Buster and has all the tools you can
expect to find and runs on a 64-bit ARM.  Otherwise, it's pure
debian Linux.

Martin

[toc] | [prev] | [next] | [standalone]

#244700 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Thu 27 Jan 2022 at 16:58:01 (-0600), Martin McCormick wrote:
> Charles Curley <charlescurley@charlescurley.com> writes:
> > I'm no expert on RPis, but that sounds to me like the SD card is
> > protected against writes. Check for any physical write protection
> > switches on the card itself and the holder.
> 
> Thanks for the suggestion, but this is one of those SSD cards
> that often is found in a camera and resembles a wafer the size of
> a thumbnail.  It has a projection that acts as a key way to keep
> a user from inserting it in the wrong way and there is a groove
> for a fingernail to help pull the chip out of the socket.  This
> particular one was reading and writing just fine until I bricked
> it by the DD that must have overwritten some address which now
> makes it unwritable.  It went from good to bad without my
> removing it from the card reader so there should be some way to
> at least clear it for writing again.
> 
> 	Apparently, it stops being writable if the partition
> table is corrupted.  In my case, I just want to delete both
> partitions and start over.
> 
> 	The OS is debian Buster and has all the tools you can
> expect to find and runs on a 64-bit ARM.  Otherwise, it's pure
> debian Linux.

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

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#244715 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

David Wright <deblis@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.

	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.

	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.

	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.

	Thanks for all useful ideas.

Martin McCormick

[toc] | [prev] | [next] | [standalone]

#244718 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Fri, Jan 28, 2022 at 07:30:25AM -0600, Martin McCormick wrote:
>	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.

SD, *not* SSD; two different things. SD cards are notoriously 
unreliable, and it sounds like it went bad. That happens, a lot. Throw 
it away, get another one. (There are less-unreliable cards, but they are 
more like $100 than $5 and rarely seen at consumer retail locations 
because typical consumers won't pay that much.)

[toc] | [prev] | [next] | [standalone]

#244719 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Fri, Jan 28, 2022 at 07:30:25AM -0600, Martin McCormick wrote:
> David Wright <deblis@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.
> 
> 	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.
> 
> 	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.
> 
> 	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.
> 
> 	Thanks for all useful ideas.
> 
> Martin McCormick
>

I'd be tempted to set up a new Raspberry Pi OS lite system on the new card
[if you were using Raspbian before], expand it using raspi-config and then
copy the working image across to another system - and rsync between.

Or jsut say - meh - and install an up to date Raspberry Pi OS on the now
zeroed card and have done with it.

Raspberry Pi OS information from here is best endeavours provision only
and may be strictly off-topic :)

Andy C

All best, as ever,

Andy Cater 

[toc] | [prev] | [next] | [standalone]

#244739 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
> David Wright <deblis@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.

[toc] | [prev] | [next] | [standalone]

#244744 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

> On 28 Jan 2022, at 16:52, David Wright <deblis@lionunicorn.co.uk> wrote:
> 
> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
>> David Wright <deblis@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.

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

[toc] | [prev] | [next] | [standalone]

#244745 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

> On 28 Jan 2022, at 18:16, Gareth Evans <donotspam@fastmail.fm> wrote:
> 
> 
> 
>>> On 28 Jan 2022, at 16:52, David Wright <deblis@lionunicorn.co.uk> wrote:
>>> 
>>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
>>> David Wright <deblis@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.
>> 

[toc] | [prev] | [next] | [standalone]

#244751 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Fri 28 Jan 2022 at 18:22:37 (+0000), Gareth Evans wrote:
> > On 28 Jan 2022, at 18:16, Gareth Evans <donotspam@fastmail.fm> wrote:
> >>> On 28 Jan 2022, at 16:52, David Wright <deblis@lionunicorn.co.uk> wrote:
> >>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
> >>> David Wright <deblis@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.

[toc] | [prev] | [next] | [standalone]

#244772 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

> On 28 Jan 2022, at 20:40, David Wright <deblis@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 <donotspam@fastmail.fm> wrote:
>>>>> On 28 Jan 2022, at 16:52, David Wright <deblis@lionunicorn.co.uk> wrote:
>>>>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote:
>>>>> David Wright <deblis@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.
> 

[toc] | [prev] | [next] | [standalone]

#244785 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

There's always one more question that nobody mentions and none of
the articles one finds on the topic don't touch.  When looking at
the man page for resize2fs in debian, it talks about the -b
option to turn on "the 64 bit feature."
__________

       When shrinking the size of the partition, make  sure
       you do not make it smaller than the new size of the ext2 filesystem!

       The  -b	and  -s  options enable and disable the 64bit feature, respect-
       tively.	The resize2fs program will, of course, take care  of  resizing
       the  block  group  descriptors  and moving other data blocks out of the
       way, as needed.	It is not possible to resize the filesystem concurrent
       with changing the 64bit status.
__________

	Do I need this since the Pi runs an ARM processor which
would make the command

   #sudo resize2fs -b /dev/loop0p2 6.3g

or is it the same command without the -b flag?

	I have determined that the 28.9 gb SSD card is 10% full
with the debian installation and the files I want in my login
directory.  I found a 7.3 gb SSD card that has probably never
been used that came with the first Raspberry Pi I bought around
2012 or so, going for a 32-gb card instead.  If I shrink the
Linux partition to 6.3 gb which is what the small card had
available, I should have it about 40 or 50% full.  I can then
safely dd it on to a larger card any time I want to do so and
then use resize2fs to expand the Linux partition after it is
installed.

	What I did so far was to mount the 27-gb partition on
/mnt through /dev/loop0 and edit /mnt/etc/hostname to reflect the
host name for the system being rebuilt.  The edit changes the
image which is really neat.  All that is left is to shrink it
down to 6.3 gb and it should be ready to dd on to the 7.3 gb card
which should be bootable on it's own but which I will use to seed
a new 28-gb system that can be customized after it is running.

	Many of the raspbian distributions have a #1 partition
that is a small fat32 lba partition for Windows users to be able
to activate debian from Windows.  Is this even necessary once one
is using unix tools on the disk?

	Thanks to all the good advice from everyone.  I am seeing
the end of this project and have learned some new  useful tricks
that are good to know.

Martin

[toc] | [prev] | [next] | [standalone]

#244805 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

[Multipart message — attachments visible in raw view] — view raw

On Sb, 29 ian 22, 16:39:31, Martin McCormick wrote:
> 
> 	Many of the raspbian distributions have a #1 partition
> that is a small fat32 lba partition for Windows users to be able
> to activate debian from Windows.  Is this even necessary once one
> is using unix tools on the disk?

At least for the first Raspberry Pi that partition contains the firmware 
necessary to boot and it has to be FAT because this is what the 
processor understands.

It's probably the same also with newer Raspberry Pi devices.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#244746 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

My thanks to everybody who has responded here.  I think the
prudent thing to do is use a new SSD card and I have one that is
supposed to be a full 32 gb.  The card I was able to finally
clear the partitions on is several years old but I think it is
still good but the suggestion to use it in a less mission
critical application is a good idea plus it is not a full 32 gb.

	I have a radio receiver that can store information on one
of these cards and I'll use it for that since if there turns out
to be a bad cell somewhere, the world won't end like it can if
one's kernel or sector information becomes corrupted if it
happens to land in a vital piece of code.

	Again, many thanks.

Martin McCormick

[toc] | [prev] | [next] | [standalone]

#244750 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

On Fri, Jan 28, 2022 at 12:42:35PM -0600, Martin McCormick wrote:
>My thanks to everybody who has responded here.  I think the
>prudent thing to do is use a new SSD card and I have one that is
>supposed to be a full 32 gb.  The card I was able to finally
>clear the partitions on is several years old but I think it is
>still good but the suggestion to use it in a less mission
>critical application is a good idea plus it is not a full 32 gb.
>
>	I have a radio receiver that can store information on one
>of these cards and I'll use it for that since if there turns out
>to be a bad cell somewhere, the world won't end like it can if
>one's kernel or sector information becomes corrupted if it
>happens to land in a vital piece of code.

The failure mode for these cards is typically that the whole thing goes 
away, not that a single sector goes bad. As soon as one starts acting 
flaky, just toss it.

[toc] | [prev] | [next] | [standalone]

#244760 — Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 28, 2022 at 03:44:13PM -0500, Michael Stone wrote:

[...]

> The failure mode for these cards is typically that the whole thing goes
> away, not that a single sector goes bad. As soon as one starts acting flaky,
> just toss it.

FWIW, I've an USB stick here (128GB) with an EXT4 file system on it (no
partitions). The file system has errors after the stick has been
quiescent fot a while (days). No I/O errors. So my hunch is that it
silently loses data. Perhaps it has used up its reserve sectors and the
firmware is desperately doing something "creative".

Those things are so embarrasingly cheap that I'd expect very variable
and erratic failure modes. I don't think the engineers get the time to
test different failure cases.

We get the cheap hell we shop for :-/

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#244699 — Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)

On 2022-01-26 10:07 p.m., Martin McCormick wrote:
> 	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.

Can you delete both partitions, create a new single linux partition, 
reboot then run mkfs.ext4 to create a single new partition and then just 
install linux onto it or try dd again?

Bijan

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web