I have dietpi on a 4TB NVMe SSD (in my rpi5), and as I flashed it for the first time and booted into dietpi, the disk partition size was limited to 2TB. At some point I needed more space, so I tried to resize it to 4TB using dietpi-drive_manager, but even though it said something like "Reboot is needed to complete resizing operationg, reboot now?" and I said "Yes", nothing was changing after reboot.
So, I decided to ask AI and manually resize the partition. I don’t remember what I exactly did in that session, but now I cannot boot properly and dietpi stucks at boot. Here are my speculations based on that AI session as far as I remember it:
dietpi uses MBR, and it limits to 2TB, why not GPT?
I tried to convert partition into GPT and this removed the layout (MBR) section?
It doesn’t matter what I did wrong, but at the end, the fact is that I cannot use dietpi on a 4TB SSD. It doesn’t expand to whole drive by default, nor dietpi-drive_manager can resize it. So, I simply interpret this as “Dietpi uses MBR which doesn’t support more than 2TB”. Is this a correct speculation?
Would you recommend me to reflash dietpi and discard all data (I have backup), or is there a still way to reflash or restore my correct dietpi partition, so that I can continue as if nothing happened? And even if I burn dietpi and set it up again, how can I work this around to use my whole disk?
If you used a proper tool for conversion of the whole partition table, it might work on RPi 5. You just need to replace the PARTUUID in /boot/firmware/cmdline.txt, resp in the root of the FAT partition, with the new one after the conversion.
If the RPi 5 bootloader does not support GPT, or not the way you created it, you should be able to convert back to MBR without loosing data, or hybrid MBR/GPT. The first actual partition/filesystem starts at 1 MiB offset, and RPis have no bootloader between partition table and first partition, hence enough space for MBR and GPT.
Thanks! Replacing PARTUUID in /boot/firmware/cmdline.txt solved the issue.
Btw why is MBR preferred over GPT in Dietpi?
EDIT: as far as I understand from here:
the reason is compatibility with other operating systems. But still I’m not sure about this:
For 4 TiB, you need to partition the drive with a GPT partition table, which is also the default in dietpi-drive_manager.
As I tried using dietpi-drive_manager, it simply didn’t resize. So, if I install dietpi again in future, I’ll be probably converting it to GPT manually, breaking it again, and fixing it through the method you mentioned above.
Wouldn’t it better to put an option for it in dietpi-drive_manager, or maybe automatically convert it to GPT if you try to resize a disk over 2TB?
This was not meant for the root partition, but for additional/external drives. There, GPT is a reasonable default. For SBC root images, it means opening a can of worms, since it works only for some SBCs, not for others, in case depends on the SPI bootloader version (which we cannot know or affect with the image) etc. Also it adds additional complexity, e.g. for the first boot partition expansion, since GPT partitions cannot be effectively resized while mounted, but require another reboot.
Raspberry Pi OS images are MBR as well. As long as the ~1.7 TiB limitation is the only one, and users attempting to run the distro on a >=4 TiB drive is an edge case (you are the 3rd I know), we better stick with MBR.
hiyo i suggest if your wanting to samba share a ssd to get a dual or quad ssd hat. i use a 256gb 970 evo plus for my main drive and i use two teamgroup 4tb ssds for storage. a 4 to 5 amp power supply would be needed though. i use these two items. 4x ssd hat and a barrel power supply. *ill probably upgrade the main drive to something better sometime.
MichaIng wrote:
[…] Also it adds additional complexity, e.g. for the first boot partition expansion, since GPT partitions cannot be effectively resized while mounted, but require another reboot.
Oh I see
Raspberry Pi OS images are MBR as well. As long as the ~1.7 TiB limitation is the only one, and users attempting to run the distro on a >=4 TiB drive is an edge case (you are the 3rd I know), we better stick with MBR.
Interesting, I thought this would be a common practice, because many
people use large SSDs for storage purposes.
get a dual or quad ssd hat. i use a 256gb 970 evo plus for my main drive and i use two teamgroup 4tb ssds for storage.
this could’ve been a solution, but unfortunately my SSD hat has only one
slot and my 4TB NVMe SSD is attached there.
So, what would be the recommended setup in my case? As I fixed it by
changing PARTUUID, it worked without any issues so far. Is it
recommended to keep it this way, or would it be recommended to use a
microsd to burn dietpi and have root partition there, while using
attached NVMe ssd as an external storage? But this would both introduce
more moving parts (and microsd is more fragile), and the microsd could
bottleneck the high I/O speed which I get via NVMe SSD.
i suggest if your wanting to samba share a ssd to get a dual or quad ssd hat. i use a 256gb 970 evo plus for my main drive and i use two teamgroup 4tb ssds for storage. a 4 to 5 amp power supply would be needed though. i use these two items.