When flashing the TX2 I observed that the system is not flashed with GUIDs in place, actually if you want to flash a version of the gpt that has GUIDs the flasher panics
[1314.637] I> Reading GPT from 512 for device 00010003
[1314.643] W> Cannot find any partition table for 00010003
[1314.648] E> tegrabl_partition_publish: exit error = 6834001
[1314.653] E> 06834001: Failed to publish partitions
Any reason for this? Or ways around it?
Where did you run the command from, and what was the command? Normally you can run “sudo gdisk -l /dev/mmcblk0” to see eMMC labels. The loopback file used in generation of rootfs does not itself have a GPT label, this is just content.
Note that on newer Linux PC hosts which might use 64-bit partition extensions that those partitions will not be readable by U-Boot (once in Linux those partitions are readable, but U-Boot itself cannot use a rootfs with 64-bit extensions). If you get this error in U-Boot the probably cause is different than if you get this after Linux begins to boot.
I ran
sudo ./flash.sh -c flash.xml jetson-tx2 mmcblk0p1
from my USB connected host.
I have modified flash.xml to flash specific gpt files, which include GUIDs.
The error is not produced by u-boot as u-boot has yet to be flashed, it is produced by TBoot-CPU Recovery
.
EDIT: fixed a typo in the command
I’ve not created a custom layout, but odds are high that the command itself was incorrect. The final argument of where to flash to is for the rootfs, and is an individual partition. “mmcblk0” would overwrite the entire disk, not a single partition. Try with:
sudo ./flash.sh -c flash.xml jetson-tx2 mmcblk0<b>p1</b>
That was a typo, my apologies.
So, for anyone interested, JetPack produces all the gpt info without populating the GUID field. Which implies that PARTUUID will not be available inside the OS.
The only workaround I found was for me to generate the partition table manually and modify flash.xml to flash it as data
partition instead of relying on the JetPack’s gpt generation mechanism.