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
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.
@FreePietje
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.
@syntax
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 ;-)
@FreePietje
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".
@FreePietje
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.
@syntax
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)."
from
https://www.linuxquestions.org/questions/linux-newbie-8/fstab-uuid-vs-partuuid-4175678376/#post6143152
A search for PARTUUID gave several such responses (on quick glance, didn't fully verify)
The images from raspi.debian.net use MBR