Now running minimal vanilla #Debian on my #RaspberryPi 4B for #Pihole. Unfortunately I tried but failed to boot with root mounted to #HDD. After the third attempt's kernel panic due to "no working init found", I gave up. I now at least have swap disabled on #SD and Pi-hole logs disabled. Any other tips for SD longevity?
@syntax As backup you can make image of your SD card with dd. If your previous SD card fails you just flash that image onto new SD card and keep everything like your SD card never failed. As for longevity - thoughts and prayers.
@nikolal Yep, I think dd backups are the way forward!
@syntax may I suggest to use non-journaling filesystem like EXT2 instead of the journaling ones? What do you think, Sam?
@ademalsasa Would I be able to do that now I've already written the image to the SD?
@djsumdog Hard to tell. It seemed worn/corrupted with my last install, but I had swap enabled, 24/7 logs etc, so no surprise it wasn't healthy. But now after flashing Debian it seems OK again. The SD card is fairly new, class 10 SanDisk, ~60GB.
@syntax huh … well if you run into more issues, you could put your logs on a logfs partition which does append only. If you’re doing a lot of I/O, you might just want to attach a USB SDD for your / or maybe just your /var. There are also some single board solutions out there with horizontal SATA ports so you can slide in an SSD (The Bananna Pi comes to mind, although I had stability issues with mine).
@syntax any special install instructions for this? Is it 64-bit?
@benis Thanks for the tip!
@syntax minimize writes. A good start is to remove logs you don’t need
@jet Thanks. I've now disabled Pi-hole logs. Any other system logs etc. which can/should be disabled?
@syntax it’s been awhile since I worked with a systemd system. Journald would be the beast to tame, because that thing is always writing logs
@jet So far I've commented out everything logging to /var/ in rsyslog.conf and disabled the service for good measure. Also set journald.conf to 'storage=volatile' -- I figure it's good to have some logs in memory rather than disabling journal completely. But it's trial and error for me currently...
@syntax when I had Pi running, I got a WD Pi hard drive for it. Shame they discontinued it..
Can you describe exactly the steps you've taken?
It should be as simple as creating a(n ext4) partition on your HDD and LABEL it RASPIROOT and then copy/rsync the contents of RASPIROOT on your SDcard over to your HDD and then delete the RASPIROOT partition on your SDcard.
This should be done outside your RPi, so f.e. on your 'normal' computer.
Oh I didn't label the HDD partition RASPIROOT or delete root from SD afterwards. I followed a guide which showed adding the HDD PARTUUID to the SD's /boot/config.txt (root=) then editing /etc/fstab on cloned HDD root.
That procedure should also work, assuming you made a typo and meant cmdline.txt, not config.txt.
In the cmdline.txt you specify the root partition. The ones from raspi.debian.net contain "root=LABEL=RASPIROOT"
If you label the HDD partition RASPIROOT, then you don't have to change cmdline.txt or /etc/fstab.
But ofc there shouldn't be 2 partitions labeled RASPIROOT as it then won't know which one to take.
As is so often the case, there are multiple ways to achieve your goal ;-)
Thanks. That's why I don't understand why my original method didn't work: simply adding the HDD PARTUUID to /boot/cmdline.txt and /etc/fstab. Maybe I'll try again soon and label the partition "RASPIROOT".
Ah, the PARTUUID could very well be the problem
"A PARTUUID is only valid for GPT formatted drives, UUIDs are valid for either one (MBR or GPT)."
A search for PARTUUID gave several such responses (on quick glance, didn't fully verify)
The images from raspi.debian.net use MBR
I actually tried in this order:
1. PARTUUID, resulted in kernel panic;
2. UUID, after reading somewhere this was better method, still resulted in kernel panic;
3. Reverted everything, so back to "root=LABEL=RASPIROOT", which strangely still resulted in kernel panic on boot. Maybe all caused by the first attempt breaking something.
I need to start a fresh attempt using LABEL method.
I just did the above with a RPi3B+ and a PiDrive, but instead of deleting RASPIROOT on the SDcard, I just gave it a new label:
tune2fs -L OLD_ROOT /dev/sdd2
mounted 'old' RASPIROOT on /media/rasp1/ and new on /media/rasp2/ and then ran this:
rsync -avHAX --progress /media/rasp1/ /media/rasp2/
Unmounted and disconnected everything from PC and connected things up with the RPi.
I think it took me ~10 minutes, where majority of time was making sure I got the right devices in my commands.
And now I've discovered tune2fs - thanks. I always wondered if I could change labels without repartitioning.
@syntax I mean minimal OSes (Arch Linux ARM, for example) can certainly help SD longevity but really I think you're just sort of minimally prolonging the inevitable. Just be sure to make regular backups to an external storage device and you'll be all good.
@ThreeBadgersInATrenchcoat I agree. I've done all I can for now / all I have the patience for (disabled logging, swap etc.). Other than that I'll just keep an eye on performance, clone the SD every month or so.