usb boot from 5tb hdd

korn16ftl3

the command to show the partition ID's is sudo blkid. IMHO

the read out for sudo blkid:

/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="F737-8E10" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="90ace319-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="d6ecfcd5-2703-41bf-9301-10c403b6fb0c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="90ace319-02"
/dev/sda2: LABEL="rootfs" UUID="d4cc7d63-da78-48ad-9bdd-64ffbba449a8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Basic data partition" PARTUUID="0000046b-eba0-706e-cf40-dc01d6080000"
/dev/sda1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="EC36-4DE1" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="701069d0-00cf-01dc-e814-08b86700ee00"

@mitu said in usb boot from 5tb hdd:

IMHO, you should use gparted for converting the partition table to GPT instead of using Windows to do it.

I've tried this but for some reason (even when in MBR) when i try to make edits to the partition tables it doesn't want to let me. i launch gparted from the console with sudo gparted however when i right click the partitions to edit or delete them it wont let me click any options or use any of the buttons on the tops of the GUI.

im willing to let someone remote desktop access my PI OS x64 and have a look around for themselves as its no security risk I'm really only using it for a bootable os to have a look at things and try to sort this mess out.

mitu

@korn16ftl3 said in usb boot from 5tb hdd:

/dev/sda2: LABEL="rootfs" UUID="d4cc7d63-da78-48ad-9bdd-64ffbba449a8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Basic data partition" PARTUUID="0000046b-eba0-706e-cf40-dc01d6080000"

The PARTUUID of the disk is not the one you have in /etc/fstab - the one in /etc/fstab actually refers to the partition from the uSD card.

Btw, did you post the output of /etc/fstab from the uSD card or the one from the disk ? Check that the /etc/fstab on the disk contains the correct Partition UUIDs - the ones from /dev/sda1 and /dev/sda as shown by the blkid command and ensure that the cmdline.txt from the disk has the right partition ID (of /dev/sda2) also.

korn16ftl3

@mitu said in usb boot from 5tb hdd:

@korn16ftl3 said in usb boot from 5tb hdd:

/dev/sda2: LABEL="rootfs" UUID="d4cc7d63-da78-48ad-9bdd-64ffbba449a8" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Basic data partition" PARTUUID="0000046b-eba0-706e-cf40-dc01d6080000"

The PARTUUID of the disk is not the one you have in /etc/fstab - the one in /etc/fstab actually refers to the partition from the uSD card.

Btw, did you post the output of /etc/fstab from the uSD card or the one from the disk ? Check that the /etc/fstab on the disk contains the correct Partition UUIDs - the ones from /dev/sda1 and /dev/sda as shown by the blkid command and ensure that the cmdline.txt from the disk has the right partition ID (of /dev/sda2) also.

I opened the fstab in a txt editor from the hard drive it's self from the /etc/fstab rather than running any commands in the shell to receive an output so the fstab should be for the hdd

I will do a cli readout when I return home a little later.

It's looking like I need to fix the cmdline.txt and the fstab on the hdd like u are suggesting. I will post pre edit and post edits of everything I change to double check the correctness of it.

If I'm understanding correctly the cmdline.txt (located in the boot partition) the fstab (located in /etc) must all have matching UUID'S for the corresponding partitions.

korn16ftl3

so having a look here to see what matches and what to replace in the fstab and what I'm seeing is the following:

/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="F737-8E10" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="90ace319-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="d6ecfcd5-2703-41bf-9301-10c403b6fb0c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="90ace319-02"

those would be the SD card labels if im not mistaken and you had said:
@mitu said in usb boot from 5tb hdd:

The PARTUUID of the disk is not the one you have in /etc/fstab - the one in /etc/fstab actually refers to the partition from the uSD card.

however i am not seeing the PARTUUID d9c86127 anywhere in the mmcblk0 read outs. I'm curious how you came to that conclusion.

do i change the entire PARTUUID in the fstab to match the ones in the blkid readout:
i.e.
from this in fstab:

PARTUUID=d9c86127-01  /boot/firmware  vfat    defaults          0       2

to this:

PARTUUID=701069d0-00cf-01dc-e814-08b86700ee00-01  /boot/firmware  vfat    defaults          0       2

I'm assuming that the -01 at the very end directs it to partition 1 on the hdd as it is labeled /boot/firmware under the proc column.

lastly i should change the cmdline.txt from this:

code_textconsole=serial0,115200 console=tty1 root=PARTUUID=d9c86127-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot cfg80211.ieee80211_regdom=NA systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target

to this:

console=serial0,115200 console=tty1 root=PARTUUID=701069d0-00cf-01dc-e814-08b86700ee00-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot cfg80211.ieee80211_regdom=NA systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target

what kind of throws me for a loop is the fact that the HDD PARTUUID has so many more characters than the original PARTUUID. Is there any particular reason for this?

UPDATE:
tried the above changes an got a message from the system stating something about running blkid or something to that effect. the message kept appearing.

im going to switch back to the 5tb drve and start fresh, so i can pick up work on the 12tb drive later sine we have established the problem is not the drive(s) just the way the system is handling them.

this time i suppose its time to leave my comfort zone a little more and try doing everything within linux and on the pi itself.

im going to start by tinkering around with th tools talked about here:
https://forums.raspberrypi.com/viewtopic.php?t=196778

i will keep this thread up to date with things i have tried and if i succeed or not because i personally hate when people dont follow up with their threads for other readers that may be having the same issues or attempting the same things and aren't sure what to do or where to go.

mitu

@korn16ftl3 said in usb boot from 5tb hdd:

however i am not seeing the PARTUUID d9c86127 anywhere in the mmcblk0 read outs. I'm curious how you came to that conclusion.

There's no mmcblk0 partition and I didn't mention any d9c86127 in my reply, I just mentioned that the Paritition UUID for the uSD card partitions (that you posted):

/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="F737-8E10" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="90ace319-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="d6ecfcd5-2703-41bf-9301-10c403b6fb0c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="90ace319-02"

are the Partition UUIDs that also appear in /etc/fstab.

In the /etc/fstab file from the hard disk (not uSD), it's the Partition UUIDs from /dev/sda[1|2] that should be used, not the ones from the uSD - the error you got with the kernel not finding the Partition UUID is caused by a mismatch in the UUID(s).

korn16ftl3

so in some more googling i found this:
https://raspberrypi.stackexchange.com/questions/120525/is-it-possible-to-boot-a-raspberry-pi-4-from-a-gpt-usb-connected-disk

in one of the reply's it says:
"By the way, you will have to update your /boot/cmdline.txt and /etc/fstab files, as your partitions will have different PARTUUID values. Also you have to change the boot order with raspi-config.

I recommend you set up /dev/sdX values in those files and then boot the raspberry and update the values with the right PARTUUID values. I tried to use the PARTUUID values I got when the disk was attached to my laptop, but they are different, for some reason."

what does he mean by reccomending that you set up /dev/sdX in those files? i know X is a variable (sda, sdb, whatever the external storage device is assigned) but is he suggesting i add those in place of the PARTUUID value in case of a bad readout, as he reports having an issue with?

example:

code_textconsole=serial0,115200 console=tty1 root=PARTUUID=/dev/sdX rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot cfg80211.ieee80211_regdom=NA systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target

Lolonois

@korn16ftl3 the legacy format is root=/dev/sda1 (or whatever drive and partition holds / (the root filesystem). Same format a la /dev/sda1 goes for /etc/fstab.

FWIW, there is a good reason why the legacy format is discouraged: https://wiki.archlinux.org/title/Persistent_block_device_naming

korn16ftl3

@Lolonois said in usb boot from 5tb hdd:

@korn16ftl3 the legacy format is root=/dev/sda1 (or whatever drive and partition holds / (the root filesystem). Same format a la /dev/sda1 goes for /etc/fstab.

FWIW, there is a good reason why the legacy format is discouraged: https://wiki.archlinux.org/title/Persistent_block_device_naming

I haven’t read that link yet but the sda and sdb are all determined by the order of of detection at boot up or order of being plugged in I’m not mistaken so i can understand how this is discouraged and no longer the way to do things.

On a positive note I did get this all working with BOTH the original 5tb and the later 12tb hard drives. The solution…..so it all in Linux. I’ll write a guide here in this thread to help others and maybe a separate one individually so it can be stickied and not follow this trail of confusing stuff?

Long story short I/we were on the right patch to begin with…just don’t use windows to change to gpt for some reason that screw’s it all up.

Simple rundown is as follows:
Write SD boot firmware to SD card with pi imager> boot SD boot firmware sd card in pi >Write retropie image to 2+tb device > write raspberry pi OS to micro SD card > boot raspberry pi OS from SD > ensure all updates and such (use the config editor with the raspberry pi imager to speed up a few things like ssh and WiFi setup) > ensure GParted and gdisk are installed > use gdisk to change hard retropie drive to GPT > use GParted to expand the root file system > check the retropie partitions partuuid in the cmd prompt > edit the cmdline.txt partuuid to match the ones you just looked up > mount the root drive for the retropie storage device with cmd prompts > load the FStab with nano > edit both partitions partuuid to the corresponding ones you just found > unmount > attempt boot

It does give some errors upon the first boot after this process and scans the hard drive and says it’s in emergency mode because it can’t boot the kernel. Just let the hard drive finish its scan and then when you can’t do anything more (it won’t even do anything if you hit enter to continue) just unplug the pi and plug it back in everything should boot accordingly and be fine after that.

Lolonois

@korn16ftl3 Thanks for the heads up and hints. Happy retro-gaming.

korn16ftl3

@Lolonois said in usb boot from 5tb hdd:

@korn16ftl3 Thanks for the heads up and hints. Happy retro-gaming.

It should also be noted to check and see if you have an energy saver in the firmware for your HDD. Mine did and it interfered with it somehow and gave me problems after a shit down and did some weird stuff…it eventually straightened its self out HOWEVER if you have the energy saver “feature” on your particular hard drive it should be disabled if you plan to leave the system on for long periods of time. I was able to do this with a windows pc using the WD utilities software. Others may have to seek other solutions to keep the drive from entering sleep mode.

I must say that even tho this whole thing was frustrating it was fun at the same time and felt accomplishing once I actually got the results I was after. Oh and I learned a lot about Linux along the way besides the little I already knew.