Dietpi on Raspberry with GPT image?

Hello,
I would like to use balena-Etcher on a 4Tb SSD
so I need a GPT partition table and not MBR
but your RaspberryPi image only offers MBR…
How can I do it?

@MichaIng can you have a look pls.

At least there are users who state it is possible (they did it with RPi OS, so it should work:
https://raspberrypi.stackexchange.com/questions/120525/is-it-possible-to-boot-a-raspberry-pi-4-from-a-gpt-usb-connected-disk

And they also mention in their docs:

The boot ROM also now supports GUID partitioning and has been tested with hard drives partitioned using Mac, Windows, and Linux.

We can simply test it, no big problem to generate a GPT partitioned RPi image.

64-bit for RPi 4, I suppose?

1 Like

Yes, that’s right, I’m trying to install a Sandisk 4TB SSD on my “old” Pi 3B+ for a sort of primitive NAS…
I was discouraged by the current price of the 4B 8!!!
and I wanted to do some testing in the meantime before making a decision…

Ah, in the meantime I created a GPT partitioned RPi image. Please test this, when you find time: https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Bullseye.7z

Good evening,
and sorry for not being quick enough.
Here it is, following your message I have downloaded the dietpi-GPT version
Then I formatted an SSD in GPT for security,
Then with Etcher I recreated the two partitions, no problem
After checking again everything is normal,
so I plug this new SSD on the raspberry and I boot
and then… nothing!
I tried several times for security but nothing happens, the boot does not start
Here it is, sorry
but anyway, things never work the first time, eh!
I’m ready to try again with a new version if I have to
here you go, thanks
good evening

Translated with DeepL Translate: The world's most accurate translator (free version)

There should be no need to format the SDD beforehand. The image contains the whole partition table so needs to be flashed to the naked/whole drive. Etcher should do it correctly, but on Windows with Rufus I’m certain.

However, there were two partitions on the drive, including the mountable boot FAT partition with dietpi.txt etc inside? Then it worked correctly I suppose.

I’ll try to label the root partition rootfs to match RPi OS (currently it’s root), just in case. While the docs state that pre-RPi4 boot ROM supports GPT, the StackExchange user did in on RPi4 which has an entirely different bootloader and EEPROM. So there as a chance that it works already on RPi4 (probably someone can test) and on prior RPi models maybe other preparations are needed. “also now supports” sounds like it may depend on the PCB revision since prior to RPi4 the ROM is fixed.

OK, you’re right, there’s no need to format before, in fact, to check, I tried again with an SD card formatted in MBR MsDos and Etcher correctly created a GUID partition table for me instead. With a FAT32 partition (with the name boot) and another in EXT4 (with the name root).
But I don’t understand, the boot doesn’t start…

Oh, sorry, I should have made it clear that I don’t have an RPI4 (expensive and unobtainable at the moment) but it’s an RPI3B+.
I don’t know if it changes anything in the boot

Ok I think I found it!
I decided to start over.
So I re-downloaded your compressed file, unzipped it carefully with 7z, then:
I started with a small SD directly in the RPI and it booted!
then I recreated the same thing on my “big” 64GB SD on USB… and it booted
finally, I took back my SSD that I completely reset before (…) and I started again, flashing, then connecting on the USB of the RPI, starting … and it works!
I assume that my download was not famous, yet I had not had any message …
So sorry to have made you search, your GUID version is excellent
Thanks

2 Likes

Morality, the verification with the hash is never a luxury…

Actually 7zip has internal CRC hashes to check with, so actually a bad download is unlikely if extraction works. However, at some point something must have gone different. I’m glad it works now.

The question now is whether we should offer GPT partitioned RPi images on a regular basis? Build and storage wouldn’t be such a problem, but I fear that too many RPi image options (we have so many already) causes too much confusion. At least another change for simplified choice should be done first, like showing the ARMv6 image for RPi 1 and Zero (1) only, ARMv7 image for RPi 2 v1.1 only and ARMv8 images for all other RPi models. Other download options then only behind an “other image options” link or so :smile:.