Flash historical V24.2 from Ubuntu 18.04

I have a legacy system with TX1 that must run with l4t 24.2 (a vendor for a driver does not support more recent versions). I used to rebuild the rootfs and flash it with my pc using Ubuntu 16.04, but recently I had to upgrade to 18.04 since I also need to support tx2 for other work, and I can’t really go back to 16.04.
Now the problem is this: if I build the rootfs on 18.04 the tx1 does not boot, it seems it cannot read the ext4 partition from mmc and thus does not load the kernel. A system.img built on the old system works perfecly. I also tried with a colleague’s pc, again with 18.04, and the tx1 does not boot, as my system. So I suspect in ubuntu 18 some tool for image creation is different? Any pointers would be helpful, I would prefer not to have yet another system dedicated just to rebuilding rootfs.

As far as I know command line flash from Ubuntu 18.04 should still work. There is one catch which you should probably check on though since it sounds like an issue I’ve seen in the past from non-Ubuntu flashing. Another issue is that sometimes people use the older non-UEFI tool fdisk instead of the UEFI gdisk (and related…some tools are front ends to fdisk or gdisk, e.g., gparted is a front end to gdisk).

A previously known issue is that ext4 supports some 64-bit extensions, and although so far as I know none of the Ubuntu releases enable to those by default, some people have enabled 64-bit ext4 extensions (either manually or by using one of the more rare Linux distributions which set this as a default).

If you look at the host PC’s “/etc/mke2fs.conf” you will find some defaults for people creating a new ext4 partition. You will find there is a block for defaults for specific filesystem types, and in this case we are interested in the “ext4 =” block. I’ll explain each individually, but examine this:
gawk '/ext4 =/,/[}]/' mke2fs.conf | grep '(metadata_csum|64bit)'

The “metadata_csum” will definitely cause boot failure. The “64bit” might not be an error on more recent releases, not sure, but will very likely be an issue on the very early L4T releases. If you were to manually format a partition, then this would eliminate both of those for just that one partition (I’m using “mmcblk0p1” as an example, adjust for whatever this is when you format):
sudo mkfs.ext4 -O ^metadata_csum,^64bit /dev/mmcblk1p1

If you flash through “flash.sh”, then you could edit every instance of “mkfs” where ext4 is expected (e.g., not needed for “mkfs.msdos”) to include the “-O ^metadata_csum,^64bit”. As an example this might be one new line:
mkfs -t $4 -O ^metadata_csum,^64bit "${loop_dev}" > /dev/null 2>&1;

The other issue I mentioned is related to this being a GPT partition scheme, and not a BIOS partition scheme. Partitions created with fdisk are old style BIOS, partitions created with gdisk are UEFI style partitions. When creating a loopback file partition these are not used, but if you have manually worked on partitioning, then this might be an issue.

A final thought which you might consider is to make sure that if you are using your own filesystem rootfs image, then the size of that image must either match the default image size, or you must specify with the “-S size” option (manual use of “flash.sh” has option “-S” for non-default sizes). Otherwise partitioning may trunctate something.