RPI : a serial SD card killer ?

Desiderius · 09-10-2021, 04:20 AM

Yesterday I put a new 32 GB card into an RPI4 and following the "excellent" tutorial of @Exaga, I began to install Slackware ARM on it.

The installation works fine during an hour and at the end, I exit from the Slackware installer to make the post installation work.

At this time I notice a long time before getting the prompt of the shell.

But, when I want to remove the unnecessary kernel files, I get error messages saying the files do not exist; Effectively, the architecture under /mnt has disappeared.

I reboot the PI4 ( by the reboot command ) and try to restart : the PI4 fails to boot !

I get back the SD card : it is very hot !

I try to mount it on a laptop : impossible : many many blocks errors ; the card is broken !

One more ! this is the third or the fourth the RPI has killed !

So is'n it possible to copy the system on the SD card on laptop and put it after on the PI4 ?

I suppose it is the warmness of the PI4 the responsible

michaelk · 09-10-2021, 06:39 AM

I don't think you can say it's solely due to installing slackware. A quick search found many threads with different Pi models experiencing a similar overheat problem. Some attribute this to bad or fake SD cards.

Where all from the same manufacturer and purchased at the same time?

fatmac · 09-10-2021, 08:32 AM

The RPi4B is designed to use the sockets as additional cooling, but getting really hot SD cards does seem to be a fake card problem.

SanDisk get recommended the most for a good quality card.

I've had my RPi4B since they were introduced, (also RPi400), & have had no problems with SDcards failing, most of mine are made by Integral.

Exaga · 09-10-2021, 09:01 AM

Quote:

Originally Posted by fatmac

I've had my RPi4B since they were introduced, (also RPi400), & have had no problems with SDcards failing, most of mine are made by Integral.

I use Kingston SDCG3 SD cards these days, and have done for some years. I find them to be one of the most reliable with impressive longevity.

glorsplitz · 09-10-2021, 07:11 PM

no problem following ""excellent" tutorial of @Exaga" for my rpi4 using sandisk

@Desiderius which brand sd card? so we can avoid them

TheTKS · 09-11-2021, 09:13 AM

Quote:

Originally Posted by michaelk

I don't think you can say it's solely due to installing slackware…

Some attribute this to bad or fake SD cards.

Where all from the same manufacturer and purchased at the same time?

I don’t think you can say it has anything to do with installing Slackware.

Interesting point about a possible connection with bad or fake SD cards.

@Desidirius, I would also like to know which cards you used, and where you bought them.

Below are cards I have used successfully - no card failures or overheating. I have also installed heat sinks and a cooling fan on my Pi4.

Slackware: started with a 16GB SanDisk Ultra card. I ran out of space on that soon enough, even leaving off some large sets like emacs and tex, so installed anew and since have been running on a SanDisk Ultra Plus 64GB. (Didn’t need that much or that fast of a card, but the sale price was irresistible.)

OpenBSD: Samsung EVO Plus 32GB.

SD cards bought only at reputable electronics or office supply stores.

TKS

glorsplitz · 09-11-2021, 02:57 PM

TKS, could also do what I did, install to ssd or nvme it seems.

Exaga · 09-12-2021, 04:32 PM

Quote:

Originally Posted by TheTKS

Slackware: started with a 16GB SanDisk Ultra card. I ran out of space on that soon enough

OpenBSD: Samsung EVO Plus 32GB.

SD cards bought only at reputable electronics or office supply stores.

I won't touch SanDisk and haven't done for +8 years. Had a bad experience with one on the Raspberry Pi (1) and as a result I tried the Samsung EVO SD cards and found them to be much more suitable. I'd used Samsung EVO cards exclusively on that device until quite recently.

Can't agree more when buying SD cards to only get them from an established reputable source/retailer. Too many fakes around these days.

Desiderius · 09-13-2021, 07:05 AM

It was a Kingstone SD card but before it has also killed Samsung cards.

I will a new try with another Kingstone

Exaga · 09-13-2021, 07:10 AM

Quote:

Originally Posted by Desiderius

It was a Kingstone SD card but before it has also killed Samsung cards.

I will a new try with another Kingstone

If you've experienced failures with other SD cards on the same device, it might be just bad luck with those particular cards, or the device itself may be causing it.

HappyTux · 09-13-2021, 07:35 AM

Quote:

Originally Posted by Desiderius

I try to mount it on a laptop : impossible : many many blocks errors ; the card is broken !

One more ! this is the third or the fourth the RPI has killed !

So is'n it possible to copy the system on the SD card on laptop and put it after on the PI4 ?

I suppose it is the warmness of the PI4 the responsible

Certainly is possible to copy the files using the laptop. I backup my Pi4 Debian install over my network using my x86_64 system using scp and rsync on the EFI and / partitions respectively. Now if it is an installer running arm then it is not possible unless a virtual machine is usable for the purpose. If it is eating cards that often do yourself a favor and get a cheap SSD and USB3 connector cable to use for its booting. Just make sure you get a USB3 dongle compatible with booting on a Pi4 and you will be good to go, the Kingston 120gb recommended drive I bought cost me something like $20 on Amazon. Much easier and if you use LABEL= for the booting of the partitions totally simple to backup with the commands I have already mentioned.

https://jamesachambers.com/raspberry...-flash-drives/

As I have mentioned you do not have to use the partuuid editing in that link above I use.

Code:

root@bullseye-raspi:~# cat /etc/fstab
# The root file system has fs_passno=1 as per fstab(5) for automatic fsck.
LABEL=RASPIROOT / ext4 rw 0 1
# All other file systems have fs_passno=2 as per fstab(5) for automatic fsck.
LABEL=RASPIFIRM /boot/firmware vfat rw 0 2

root@bullseye-raspi:~# cat /boot/firmware/cmdline.txt 
console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0  rootwait

To backup or copy from a fresh sdcard, the commands used from my notes.

Code:

Now to copy the working system to the SSD. 

root@bullseye-raspi:~# rm -r /tmp/ssdboot/*
root@bullseye-raspi:~# scp /boot/firmware/* /tmp/ssdboot/
'/boot/firmware/bcm2711-rpi-4-b.dtb' -> '/tmp/ssdboot/bcm2711-rpi-4-b.dtb'
'/boot/firmware/bcm2837-rpi-3-a-plus.dtb' -> '/tmp/ssdboot/bcm2837-rpi-3-a-plus.dtb'
....

root@bullseye-raspi:~# rm -r /tmp/ssdroot/*
root@bullseye-raspi:~# rsync -ahPHAXx --delete --exclude={/boot/firmware/*,/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} / /tmp/ssdroot/
sending incremental file list
./
bin -> usr/bin
initrd.img -> boot/initrd.img-5.10.0-8-arm64
initrd.img.old -> boot/initrd.img-5.10.0-8-arm64
lib -> usr/lib
sbin -> usr/sbin
vmlinuz -> boot/vmlinuz-5.10.0-8-arm64
vmlinuz.old -> boot/vmlinuz-5.10.0-8-arm64
.....

As you can see I made certain the mounted partitions were empty before the copying if doing over network needs to be done as root user so need to allow that in your ssh configuration.

Edit: and now I see it if your partition for the EFI partition for the booting is mounted as something other than /boot/firmware you need to change that in the exclude part of the rsync command everything else are standard linux items you want to exclude as there are re-created on every boot, no sense in copying those items.

Exaga · 09-14-2021, 06:54 PM

Quote:

Originally Posted by HappyTux

Much easier and if you use LABEL= for the booting of the partitions totally simple to backup with the commands I have already mentioned

The only caveat I would point out with using LABEL is, if you have 2 devices with the same name you're asking for trouble. However likely, or unlikely, that may be is down to each individual user's preference and choices.

I would advise using PARTUUID and UUID instead of LABEL because the chance of duplicate IDs is most improbable. I did a SARPi mini-project on persistent storage device naming some time ago for anyone who is interested - https://sarpi.penthux.net/index.php?p=pers-devnam

For the Raspberry Pis I have which run Slackware ARM using a SSD storage device, this is how things look:

Code:

root@kron:~# cat /etc/slackware-version
Slackware 14.2+

root@kron:~# cat /proc/device-tree/model && echo
Raspberry Pi 4 Model B Rev 1.4

root@kron:~# blkid
/dev/sda1: SEC_TYPE="msdos" UUID="3FC7-9165" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="35804286-01"
/dev/sda2: UUID="4276998c-1673-4a46-8fc2-0ec361641da7" TYPE="swap" PARTUUID="35804286-02"
/dev/sda3: UUID="1f460cc7-b257-4f63-a17a-4ea67db7cfe6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="35804286-03"

root@kron:~# cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 nofont root=PARTUUID=35804286-03 rootfstype=ext4 rootwait ro

root@kron:~# cat /etc/fstab
UUID=4276998c-1673-4a46-8fc2-0ec361641da7     swap             swap        defaults         0   0
UUID=1f460cc7-b257-4f63-a17a-4ea67db7cfe6     /                ext4        defaults         1   0
UUID=3FC7-9165   /boot            vfat        fmask=177,dmask=077 1   0
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       nosuid,nodev,noexec 0   0

HappyTux · 09-15-2021, 09:18 AM

Quote:

Originally Posted by Exaga

The only caveat I would point out with using LABEL is, if you have 2 devices with the same name you're asking for trouble. However likely, or unlikely, that may be is down to each individual user's preference and choices.

Yes I had done that partition ID thing at the start then got tired of forgetting to edit the files with the proper values each time you do a backup and boot with it to test the success. Which I do with every major update. The chances of having two boot devices plugged in at the same time are very slim to none when using a single SSD dongle attached to the machine. Now if stupid enough to leave a sdcard plugged in when using the method I do, well it is a sorry about your luck for your own stupidity moment. As it will always boot from that first even with the boot order set to ssd first, another lie from them Pi people...

Code:

root@bullseye-raspi:~#  vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0xf41
[none]
FREEZE_VERSION=0

The BOOT_ORDER=0xf41 setting is supposed to do the USB booting but with the sdcard left in the machine it uses it no matter that setting. For anyone wanting the vcgencmd you just need to copy it over from a Pi installation of the Debian flavour you use. Then run the ldd command on it to find the two missing libraries and then copy them to your Debian install and you have it running. From my notes.

Code:

From doing it with a Debian Buster install in those notes.

root@buster-raspi:~# ldd vcgencmd 
	linux-vdso.so.1 (0x0000ffff8125e000)
	libvchiq_arm.so.0 => not found
	libvcos.so.0 => not found
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff811eb000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff811d7000)
	librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff811bf000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff8104d000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff81230000)


Copying of the files from Bullseye Raspian to the Debian Bullseye I have installed for vcgencmd.

root@zeus-H370M:~# rsync -avP pi_sync/raspian_bullseye/sdroot/usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0 root@192.168.0.116:/usr/lib/aarch64-linux-gnu/
sending incremental file list
libvchiq_arm.so.0
         30,888 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)

sent 30,985 bytes  received 35 bytes  20,680.00 bytes/sec
total size is 30,888  speedup is 1.00
root@zeus-H370M:~# rsync -avP pi_sync/raspian_bullseye/sdroot/usr/lib/aarch64-linux-gnu/libvcos.so.0  root@192.168.0.116:/usr/lib/aarch64-linux-gnu/
sending incremental file list
libvcos.so.0
         60,296 100%   26.25MB/s    0:00:00 (xfr#1, to-chk=0/1)

sent 60,392 bytes  received 35 bytes  120,854.00 bytes/sec
total size is 60,296  speedup is 1.00
root@zeus-H370M:~# rsync -avP pi_sync/raspian_bullseye/sdroot/usr/bin/vcgencmd  root@192.168.0.116:/usr/bin/sending incremental file list
vcgencmd
         18,792 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)

sent 18,880 bytes  received 35 bytes  37,830.00 bytes/sec
total size is 18,792  speedup is 0.99

The results it works.

root@bullseye-raspi:~# vcgencmd measure_temp
temp=51.1'C

Minime_2003 · 09-20-2021, 03:00 AM

Some configuration tips and tweaks to make your solid-state drives (SSD) and SDcard last longer is to reduce the use of swap, add noatime to fstab, activate TRIM for LVM and run fstrim regulary.

Add noatime to fstab
First make a backup of your fstab config.

Code:

# cp /etc/fstab /etc/fstab.bak
# nano /etc/fstab

Add noatime to the partition definition. I have added the noatime option to the root (/) partition:

Code:

/dev/mmcblk0p3   swap             swap        defaults         0   0
/dev/mmcblk0p2   /                ext4        defaults,noatime,errors=remount-ro  1   1
/dev/mmcblk0p1   /boot            vfat        fmask=177,dmask=077 1   0
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       nosuid,nodev,noexec 0   0

Enable TRIM for Logical Volumes (LVM)

Code:

# nano /etc/lvm/lvm.conf

Change the line "issue_discards = 0" to "issue_discards = 1".

Run fstrim regularly
According to Linux man pages:
fstrim is used on a mounted filesystem to discard (or "trim") blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs)/SDCards and thinly-provisioned storage. By default, fstrim will discard all unused blocks in the filesystem. Options may be used to modify this behavior based on range or size, as explained below.

Before activating and using fstrim, make sure your SSD/SDcard drive supports TRIM.

Code:

# lsblk -D

NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
mmcblk0            0        4M    41.9G         0
├─mmcblk0p1  4177920        4M    41.9G         0
├─mmcblk0p2  3145728        4M    41.9G         0
└─mmcblk0p3  3145728        4M    41.9G         0

Non-zero values for DISC-GRAN and DISC-MAX indicate TRIM support.

Slackware has already created a weekly cron jobs /etc/cron.weekly/ So we create a cron job for fstrim:

Code:

# nano /etc/cron.weekly/fstrim

Add:

Code:

#!/bin/sh
/sbin/fstrim -a || true

Make "fstrim" executable.

Code:

# chmod 755 /etc/cron.weekly/fstrim

Reduce the use of swap
Modern systems now have enough RAM (4 GB or more) like the raspberry pi 4 with 4GB RAM =<, so the systems very rarely use the SWAP memory.
So you really do not need to cast anything, but it is still recommended to do the following:

With your favorite text editor (nano in my case)

Code:

# nano /etc/sysctl.d/ssd.conf

Code:

# change the following decimal integer
# 0 - 100 where 0 is NEVER use swap
vm.swappiness=1

Best of regards:
Minime