<Armbian-Discord>
<Tenkawa> I had to run... priting disaster at house preparing for afternoon event
<Armbian-Discord>
<c0rnelius> Yeah not a one size fits all when dealing with Pis. Its a problem.
<Armbian-Discord>
<IgorPec> it worked before, have to get to that situation
<Armbian-Discord>
<c0rnelius> Alright. I got it booting just by removing the ESP flag from the partition. So stop it from being flagged/labeled ESP during img creation and it should be fine.
<Armbian-Discord>
<IgorPec> tnx, will pass this forward.
<Armbian-Discord>
<c0rnelius> ``` Raspberry Pi 3 Model B Plus Rev 1.3
<Armbian-Discord>
<c0rnelius> [ 0.000000] Linux version 5.15.80-bcm2711 (root@79c6070d5798) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.11.1 SMP PREEMPT Wed Nov 30 11:02:56 UTC 2022 ```
<Armbian-Discord>
<c0rnelius> your welcome
<Armbian-Discord>
<ManoftheSea> Flag? In fdisk?
<Armbian-Discord>
<ManoftheSea> What does that actually do to the layout? Because the "flag" is actually the partition uuid, does the raspi look for something else specific?
<Armbian-Discord>
<rpardini> Ok so... original rpi4b I did together with the first UEFI builds. So I shared some code...
<Armbian-Discord>
<rpardini> Both used GPT, and an ESP flagged partition, in FAT fs.
<Armbian-Discord>
<rpardini> Back then, the physical order of partitions was different from the logical one -- that has been changed recently for "Oleg wants it this way" reasons.
<Armbian-Discord>
<rpardini> Sincerely tracking this down now will be harder, maybe simpler to just introduce a ${UEFI_PART_IS_ESP:-yes} or something to that effect to avoid flagging it as ESP when it isn't.
<Armbian-Discord>
<Tenkawa> Oleg needs to quit arbitrarily changing things "wants it this way"
<Armbian-Discord>
<Tenkawa> and anyone else for that matter
<Armbian-Discord>
<rpardini> sincerely, he had a point. my way was more compatible but very confusing.
<Armbian-Discord>
<Tenkawa> especially with no documentation as to "why", "what" and "how it will impact other things"
<Armbian-Discord>
<Tenkawa> It wasn't documented... thats all thar has to be said
<Armbian-Discord>
<Tenkawa> And if it is... where?
<Armbian-Discord>
<c0rnelius> There is just no reason 'currently' to do this with Pis. Not even using u-boot right? Unless you wanna make it an optional that is.
<Armbian-Discord>
<c0rnelius> Plus I don't believe the bootcode.bin which older Pis need supports the ESP which is what the underlining problem is here. It can't find the partition because its hidden.
<Armbian-Discord>
<rpardini> u-boot was never involved...
<Armbian-Discord>
<rpardini> I did it that way only because was already done for UEFI "transpose so EFI is in sda15 and root in sda1, while physically EFI is first on disk"
<Armbian-Discord>
<rpardini> and it worked a bit by accident
<Armbian-Discord>
<rpardini> sincerely I think removing the ESP flag is the correct way to go
<Armbian-Discord>
<rpardini> for pi's at least.
<Armbian-Discord>
<c0rnelius> yeah what you said. introduce a variable and problem solved.
<Armbian-Discord>
<Tenkawa> @rpardini hey you know the armbian build system a lot better than I do.. whats the appropriate conf method/option to have it not wipe/re-extract the kernel source every build attempt?
<Armbian-Discord>
<Tenkawa> I'm integrating a piece of new code that needs some fixes and it wipes out the extracted source every run in cache as is
<Armbian-Discord>
<Tenkawa> found a way to accomplish what I needed to do
<Armbian-Discord>
<ManoftheSea> what does this mean?
<Armbian-Discord>
<ManoftheSea> what is "ESP flag"
<Armbian-Discord>
<ManoftheSea> There is no ESP flag, there is a GUID for ESP. The nonsense that is fdisk or parted should not be used in normal discussion about this topic because it is needlessly confusing.
<Armbian-Discord>
<Tenkawa> @ManoftheSea yes and since when has Broadcom adhered to "anyones" standards.... never
<Armbian-Discord>
<ManoftheSea> But esp "flag" isn't a standard
<Armbian-Discord>
<ManoftheSea> "hidden" is a flag. Is that getting set?
<Armbian-Discord>
<ManoftheSea> We can fix that by using sgdisk instead of fdisk
<Armbian-Discord>
<ManoftheSea> A reason to have esp as first partition is to allow uboot to discover it for purposes like "bubt" (binary update tool) which only looks at the first partition.
<Armbian-Discord>
<ManoftheSea> But rpi doesn't need that
<Armbian-Discord>
<Tenkawa> rpi/bcm are going to use what they want, when they want.. so you better follow them not try to dictate what it "should" be
<Armbian-Discord>
<Tenkawa> That's how it's always been and how it will always be as long as its foundation/bcm code.
<Armbian-Discord>
<rpardini> I wrote the original with parted: set 15 esp on (what I call a "flag")
<Armbian-Discord>
<rpardini> hzyitc rewrote it with fdisk, which I think takes type=uefi
<Armbian-Discord>
<rpardini> I understand both actually set C12A7328-F81F-11D2-BA4B-00A0C93EC93B GUID
<Armbian-Discord>
<ManoftheSea> Well, a dirty hack is to do a hybrid mbr, that identifies the partitions for the bootloader
<Armbian-Discord>
<ManoftheSea> But if rpi can't use ESP, there's no reason to do gpt
<Armbian-Discord>
<rpardini> hybrid is done for UEFI x86 only
<Armbian-Discord>
<ManoftheSea> ew
<Armbian-Discord>
<ManoftheSea> Hmm, is it a lack of "boot" flag due to the sfdisk method?
<Armbian-Discord>
<rpardini> Here we just need to turn off the ESP flag in the partition and it's all good
<Armbian-Discord>
<ManoftheSea> That seems weird to me, that it's specifically looking for the ESP GUID and not using the partition
<Armbian-Discord>
<rpardini> 👆
<Armbian-Discord>
<ManoftheSea> okay, but that's not a complete description of what got changed. What is it instead, and is that something we can make use of?
<Armbian-Discord>
<ManoftheSea> because ESP isn't a flag, you can't "remove the ESP flag"
<Armbian-Discord>
<ManoftheSea> does it look for the GUID that was put there instead? The Boot flag? a specific other label?
<Armbian-Discord>
<rpardini> what changed is 2 things
<Armbian-Discord>
<rpardini> - sfdisk instead of parted : some "esp flag" / GUID / whatever
<Armbian-Discord>
<Tenkawa> -> [HttpSkipResponseCommand.cc:218] errorCode=3 Resource not found
<Armbian-Discord>
<Tenkawa> oh just the checksums
<Armbian-Discord>
<Tenkawa> whew
<Armbian-Discord>
<ManoftheSea> "fat16"? shouldn't it be fat32? or that has a minimum size?
<Armbian-Discord>
<IgorPec> tenkawa: that should not be a problem
<Armbian-Discord>
<Tenkawa> yeah I verified they are all checksums
<Armbian-Discord>
<Tenkawa> just disconcerting at first though
<Armbian-Discord>
<IgorPec> hmm, let me check
<Armbian-Discord>
<IgorPec> this cache does not exists - you are doing some custom selection of apps?
<Armbian-Discord>
<IgorPec> but if its not found, then it should start deboostraping
<Armbian-Discord>
<c0rnelius> @ManoftheSea I'm just using that setup as an example of how to list the flags. If I pull that card out of the board, and stick it in my main PC, the FAT part will by default be invisible. At least on a Linux system.
<Armbian-Discord>
<c0rnelius> In this case, the ESP flagged partition contains the EFI binary.
<Armbian-Discord>
<c0rnelius> You don't want this happening on a Pi, unless you don't wanna support older boards. Although adding a u-boot bin as the kernel may be away around this? Would need to check... But the easiest way would be not to force an EFI/GPT setup on raspi images.
<Armbian-Discord>
<Tenkawa> Agreed... RPI's are not universally EFI/GPT friendly in general.
<Armbian-Discord>
<c0rnelius> Yeah its just not a good idea. Plus its not adding anything. There is no benefit to doing so. Really no benefit on any SBC from what I can tell but people are really interested in the EFI/GPT for whatever reason.
<Armbian-Discord>
<c0rnelius> I guess I'm just getting old
<Armbian-Discord>
<Tenkawa> Hey I'm already there