Thank you for looking into this, but this didn’t help, at least for me.
I sent the adb command and reconnected wifi. test-ipv6.com shows 0/10 after some minutes again…
@ArianK16a Thanks for caring- I downgraded meanwhile so I can only wait along.
So you downgraded back to March build, and issue is not present anymore?
Then it indeed seems like the issue is not the one from the Google issue tracker. We can try to downgrade the firmware until we find a working state, I will push some test builds for that within the next days.
@vanMacG yes, March build runs without issues, since the May build the reported delays appeared, installing the first official build did not stop them.
The IPv6 tests displayed funny results that changed every time I repeated them; nevertheless I wonder if my device is the only one that suffers those curious issues. My “feeling” is that connection (DNS/IPv6) might be one issue, but there must be another change that causes the delays. But those ‘feelings’ aren’t helpful.
@ArianK16a Please wait until others test the way you suggested - for me as a single user it isn’t necessary!
I do no longer enjoy flashing, FP6 is my daily device; and it seems to me that it isn’t helpful for others because I cannot reproduce the issues (and the differences/changes) So to avoid this forum to go ‘magisk-like’, I enjoy March-build, it serves my needs.
@ArianK16a can I just use the updater to go from your last unofficial built to this official?
I already installed the official built from yesterday via updater. While everything seams to work, in settings (“about”) it says I am still on “LineageOS-Version 23.2-20260629-UNOFFICIAL-FP6”
No that’s not possible. You can sideload it using adb.
Do I have to reflash gapps?
Unofficial or official?
When coming from unofficial with gapps and want to sideload official 
yep, like already mentioned in the thread, this didn’t help in my case
All i know that this problem also had/has the fp6 stock rom (a friend of mine had one).
If i can test or try or help with sth, just ping me :3
Success report
Was on the unofficial build.
Saw that there was an OTA update even though the unofficial branch was closed.
Flashed it, I noticed the OTA screen changed, but it still said UNOFFICIAL in the LineageOS version.
ADB sideload the official build, it told me that signature was invalid, then that I was downgrading versions.
YOLO’d it, and surprisingly it booted fine, and LineageOS version is now NIGHTLY
Random reboots
Since about a week, my phone reboots at least once a day.
I seem to be related to media playback, or perhaps it is the extreme heat wave in France ?
Hopefully the official build will fix it 
I know the Camera app said that my phone was in moderate overheating (whatever that’s supposed to mean), and given it’s hot where I am right now (no surprises there, as you said), it could be related. My phone doesn’t reboot though.
FP6 official tree: relock shows yellow custom-key screen, then falls back to bootloader instead of booting
I’ve been building LineageOS 23.2 for the FP6 from source, signed with my own AVB key. On my previous tree (pre-official device/kernel repos) relocking worked flawlessly for months: flash boot/dtbo/vendor_boot/init_boot/recovery, fastboot flash vbmeta, sideload the zip, boot once, reboot to bootloader, fastboot flashing lock — relocked and booted every time.
I’ve now migrated to the official tree (official manifest + breakfast FP6), vendor blobs extracted from the matching FP6.QREL.16.82.0 factory image, MindTheGapps included built into the ROM via a local_manifest (vendor/gapps synced from the MindTheGapps repo, baklava branch — not sideloaded as a separate zip), Build completes fine.
The problem: unlocked, the device boots perfectly and reaches the setup wizard. But after fastboot flashing lock, it wipes, reboots, shows the yellow custom-key screen with the correct AVB key fingerprint (same screen as when it booted fine before), and then drops back to the bootloader instead of booting. Unlocking again makes it boot normally.
Already verified: main vbmeta and all chained partitions carry my custom key (matching sha1); rollback indices correct and equal-or-higher than stock; hashtree descriptors all present with valid root digests; get_unlock_ability returns 1 before locking; same device and same procedure that worked before.
getvar after the failed lock reports the device as healthy: unlocked: no, secure: yes, current-slot: b, slot-successful a: yes and b: yes, slot-unbootable a: no and b: no. Both slots successful and bootable, yet it won’t boot when locked. Since the yellow screen appears with the correct key, AVB is accepting the key and the verified-boot chain passes — the failure seems to happen after verification, only under lock enforcement.
Questions: Has anyone relocked the FP6 with a custom AVB key on the official tree (not the pre-official repos)? Is there a known change affecting relock or dm-verity enforcement when locked? Any way to capture the boot failure reason when locked (no adb, and last-boot-reason / boot-fail-reason getvars aren’t available on this bootloader)?
Device: FP6 (sm7635), A/B, lineage-23.2 built from source, self-signed AVB key. Can provide full avbtool info_image dumps, BoardConfig or fstab.
LOS does not support locking the bootloader
It seems @TomHa is trying to do what still is possible according to the quote …
I dont think so (20 chars)
@ArianK16a could you clarify this one? On the pre-official tree there used to be a patch required to enable custom AVB key support (I applied it myself during my unofficial builds and relocking worked fine). On the current official tree that patch is no longer needed — the custom AVB key support is already built into the device tree (AVB_CUSTOM_KEY_PATH / AVB_CUSTOM_ALGORITHM), and looking at the code the old patch doesn’t seem necessary anymore. So relocking with a self-signed key should be supported on official as it was on unofficial.
My builds are signed with my own AVB key, the yellow custom-key screen shows the correct fingerprint (so AVB accepts the key), but when locked the device drops back to the bootloader instead of booting, while unlocked it boots perfectly. Same device, same procedure that worked on my pre-official builds.
Is there any known difference between the pre-official and official device/kernel tree that would affect relocking or dm-verity enforcement under lock? And is there any other non-obvious guard or kill switch active on the official tree that could block booting only when locked — something in the kernel cmdline, dm-verity mode, AVB flags, or init that isn’t obvious from the device tree? Anything I might be missing on the official tree specifically?
Happy to provide full avbtool info_image dumps, BoardConfig or fstab if useful.