Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)
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 signature.asc Description: PGP signature
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
Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)
> On 28 Jan 2022, at 20:40, David Wright wrote: > > On Fri 28 Jan 2022 at 18:22:37 (+), Gareth Evans wrote: >>> On 28 Jan 2022, at 18:16, Gareth Evans wrote: > On 28 Jan 2022, at 16:52, David Wright wrote: > On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote: > David Wright 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
Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)
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 signature.asc Description: PGP signature
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.
Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)
On Fri 28 Jan 2022 at 18:22:37 (+), Gareth Evans wrote: > > On 28 Jan 2022, at 18:16, Gareth Evans wrote: > >>> On 28 Jan 2022, at 16:52, David Wright wrote: > >>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote: > >>> David Wright 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
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
Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)
> On 28 Jan 2022, at 18:16, Gareth Evans wrote: > > > >>> On 28 Jan 2022, at 16:52, David Wright wrote: >>> >>> On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote: >>> David Wright 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
Re: SD Memory Card (was The Raspberry Pi that Took a Day Off.)
> On 28 Jan 2022, at 16:52, David Wright wrote: > > On Fri 28 Jan 2022 at 07:30:25 (-0600), Martin McCormick wrote: >> David Wright 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
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 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
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 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
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.)
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
David Wright 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
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
On Fri, Jan 28, 2022 at 07:39:12AM +0100, to...@tuxteam.de wrote: > On Wed, Jan 26, 2022 at 09:07:31PM -0600, Martin McCormick wrote: > > 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 > > This looks to me like the write to the SD card failing. Since you > excluded write protection in this thread, I'd venture the hunch that the > SD has gone bad, in some way. > > Any entries in your /var/log/syslog or /var/log/messages at this point? > > Have you tried to write to the SD card, e.g. > > dd if=/dev/zero of=/dev/sdh bs=1024 count=1 oflag=sync > > would overwrite the first 1K bytes with zeros. Any errors, then? > > If I had to bet at this point, I'd say the SD card isn't good. This > happens. > > Cheers > -- > t I've had a few cards that are just annoying: there is a (Windows only) utility from the industry consortium that "does" SD which is often recommended and has recovered one or two for me - especially some which appear to have an Apple Mac partition ID SD cards - unless particularly strange physical sizes - are probably cheap enough that you can write it off to experience. SSD drives in SD card format - don't know. And yes, I've a "blessed" SD -> MicroSD card adapter which seems to work better than most of the others and a good Sandisk USB2 -> SD card holder. It is a bit random as to what will work and what doesn't. Just my €0.02 of experience, All the very best, as ever, Andy Cater
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
On Wed, Jan 26, 2022 at 09:07:31PM -0600, Martin McCormick wrote: > 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 This looks to me like the write to the SD card failing. Since you excluded write protection in this thread, I'd venture the hunch that the SD has gone bad, in some way. Any entries in your /var/log/syslog or /var/log/messages at this point? Have you tried to write to the SD card, e.g. dd if=/dev/zero of=/dev/sdh bs=1024 count=1 oflag=sync would overwrite the first 1K bytes with zeros. Any errors, then? If I had to bet at this point, I'd say the SD card isn't good. This happens. Cheers -- t signature.asc Description: PGP signature
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
On 2022-01-27 8:54 p.m., Martin McCormick wrote: Great suggestions but I can't. Part of the typescript output I included was me doing just that and I was root when I did it but the squawk is that I don't have permission as if I wasn't root. Oops! Sorry I missed the operation not permitted messages (or at least the one in fdisk). What does: ls -l /dev/sdh* show for permissions? Bijan
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
On 28/1/22 9:54 am, Martin McCormick wrote: Great suggestions but I can't. Part of the typescript output I included was me doing just that and I was root when I did it but the squawk is that I don't have permission as if I wasn't root. If writing to the SSD card was possible, I could have just done the dd command, only with a smaller input image and it would have worked. Thank you because what you suggest would be the normal way out. Martin Martin My take that solid state drives - SSD and especially CF - can go bad and it's usually safest to get a replacement rather than continue to work with one that's showing any sign of misbehaviour. Incidentally, there are a wide variety of SSD drive brands and some are definitely slower and less reliable than others. Genuine Sandisk are usually pretty good, but always use a tool to check that what's inside is the same as the label. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
Bijan Soleymani writes: > 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? Great suggestions but I can't. Part of the typescript output I included was me doing just that and I was root when I did it but the squawk is that I don't have permission as if I wasn't root. If writing to the SSD card was possible, I could have just done the dd command, only with a smaller input image and it would have worked. Thank you because what you suggest would be the normal way out. Martin Martin
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 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.
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
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
Charles Curley 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
Re: SSD Memory Card (was The Raspberry Pi that Took a Day Off.)
On Wed, 26 Jan 2022 21:07:31 -0600 "Martin McCormick" 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/
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[0m [1mBoot[0m [1m Start[0m [1m End[0m [1m Sectors[0m [1m Size[0m [1mId[0m [1mType[0m /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
Re: The Raspberry Pi that Took a Day Off.
> On 25 Jan 2022, at 14:17, Martin McCormick 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
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
