Regards
Berni
Just in parenthesis: hardcoding the uuid is no less hardcoding than hardcoding the partition device name. At some stage in history there was that idea of partition "label" which survives partition resize, move and copy; that could be used as well.
]]>Note that you can set the uuid of an ext4 parition with tune2fs, i.e. you should be able to restore the uuid of the shrunk partition.
Might be easier just to add the new root=PARTUUID=newid-02 to /boot/cmdline.txt and be done with it. Or you could just hard code it in with something such as root=/dev/sda2.
]]>(this is all to be used with a Raspberry Pi 4)
With
xzcat "image".xz > /dev/sdb
I flashed an image of Devuan Beowulf 3.0 onto my SSD. The image was provided by c0rnelius under this link:
https://github.com/pyavitz/rpi-img-buil … tag/images (THANKS A LOT! ).
The image booted fine and sshd via ethernet worked out of the box.
After shutdown the Raspi, attaching the SSD to my Linux PC and looking at the partitioning I found two partitions:
A very small boot partition and a very large root partion (more than 100GBytes).
For backup reasons I would like to have at least an additon partition for my $HOME.
Since this has worked for a lot of cases, I shrinked the root partition with gparted, added an addtional partition with an ext4 file system, wrote whole stuff to the SSD (no error/warning) and fired up my Raspi with the SSD.
It does not boot anymore.
I reflashed the image, and did the partioning before the first boot. Same thing: No boot.
I reflashed the image, and did the partioning, disable the automatic partition resizer, boot the Raspi. Again: No boot.
In all cases the partition for $HOME was left off fstab (to be added, if boot succeeds, which it doesn't).
I searched the forum with "repartitioning" and "gparted" and found either nothing or much too much hits to be of what I wanted.
Did I overlooked something? How can I successfully modify the partion scheme?
Cheers!
mcc