Control: Severity 1091979 serious
Control: tags 1091979 confirmed
On 2025-03-03, Vagrant Cascadian wrote:
> Looping Arnaud into the conversation, as I suspect the patches submitted
> were touching this code quite a bit:
>
> 51d120d549e5b21a19ce659c7bef578c86ed9636 Allow to automatically sync DTBs
> when /boot is on a separate partition (Closes: #1025956)
> 96a866bc886f118de9286a00587b2e1fcf263105 read-config: make /boot partition
> check a function
>
> Of course I am the one who uploaded them, but antoehr pair of eyes
> obviously will not hurt! :)
>
> live well,
> vagrant
>
> On 2025-03-03, Johannes Schauer Marin Rodrigues wrote:
>> Quoting Johannes Schauer Marin Rodrigues (2025-01-02 23:53:53)
>>> The lines that should contain an fdt or fdtdir entry are missing. Lets look
>>> at
>>> the sh -x output to figure out why they were not generated:
>>>
>>> 1 P: Writing config for vmlinuz-6.12.6-mnt-reform-arm64...
>>> 2 + _NUMBER=0
>>> 3 + _ENTRY=1
>>> 4 + [ -e /boot/initrd.img-6.12.6-mnt-reform-arm64 ]
>>> 5 + _INITRD=initrd /initrd.img-6.12.6-mnt-reform-arm64
>>> 6 + [ -e ]
>>> 7 + [ -e /boot6.12.6-mnt-reform-arm64/ ]
>>> 8 + [ -d /boot6.12.6-mnt-reform-arm64/ ]
>>> 9 + [ -f /boot/dtb-6.12.6-mnt-reform-arm64 ]
>>> 10 + [ /usr/lib/linux-image- = ]
>>> 11 + _FDT=
>>>
>>> Line 6 checks an empty value because U_BOOT_FDT is unset. Line 7 and 8
>>> cannot
>>> work because there is a missing slash between ${_BOOT_PATH} and
>>> ${U_BOOT_FDT_DIR}. Line 9 finds /boot/dtb-6.12.6-mnt-reform-arm64 but the
>>> check
>>> in line 10 fails because {U_BOOT_FDT_DIR} is unset. Why is it unset? Because
>>> even though read-config found a separate /boot partition in
>>> has_separate_boot(), U_BOOT_SYNC_DTBS was set to false, so _FDT_DIR was
>>> never
>>> set to "/dtb-" and even if it were set to that, the check in line 10 would
>>> still fail because "/usr/lib/linux-image-" is not equal to "/dtb-". So to
>>> summarize:
>>>
>>> 1. why is a fdt or fdtdir line not added by default?
>>> 2. why are there missing slashes in line 7 and 8?
>>> 3. why do i have to enable U_BOOT_SYNC_DTBS? I already use flash-kernel
>>> for that
>>> 4. why is there a check for "/usr/lib/linux-image-" if _FDT_DIR gets set
>>> to "/dtb-"?
>>>
>>> One workaround is to set:
>>>
>>> U_BOOT_FDT_DIR="/dtbs/"
>>>
>>> which will then add fdtdir entries that look correct. The slashes are
>>> critical
>>> because they are missing in the u-boot-update script.
>>
>> so here is a potential patch:
>>
>> --- /usr/share/u-boot-menu/read-config
>> +++ /usr/share/u-boot-menu/read-config
>> @@ -48,6 +48,8 @@
>> if [ "${U_BOOT_SYNC_DTBS}" = "true" ]
>> then
>> _FDT_DIR="/dtb-"
>> + else
>> + _FDT_DIR="/dtbs/"
>> fi
>> else
>> # / and /boot are on the same filesystem
>>
>> With that in place, extlinux.conf will now contain a line like this:
>>
>> fdtdir /dtbs/6.12.15-mnt-reform-arm64/
>>
>> Note, how this is still a change in behaviour. With u-boot-menu from
>> Bookworm,
>> not fdtdir would be set but one would have:
>>
>> fdt /dtb-6.12.15-mnt-reform-arm64
>>
>> But maybe that change is intentional?
>>
>> I can make an attempt at different fix for this problem but I'd need to
>> understand what is supposed to happen first. My four questions above still
>> are
>> unanswered and especially with the missing slashes and the unset _FDT_DIR,
>> the
>> code *can* not work as it is or am I missing something?I one problem is that u-boot-menu and flash-kernel and using the same path, e.g. /boot/dtb-X.Y.Z-ARCH, but for flash-kernel it expects it to be a symlink to the specific .dtb file to use, and the new u-boot-menu syncing functionality expects it to be a directory... I think if u-boot-menu used /boot/dtbs/X.Y.Z-ARCH which flash-kernel includes as a directory, it might just work. Still probably a few more issues to sort out... (e.g. it behaves differently if U_BOOT_SYNC_DTBS=true rather than just responding to what files are present). I noticed a few runs where it still broke the older kernels even if I managed to somewhat manually fix a newer one. I have not had a chance to dig into untangling this yet, but it warrants a serious severity, as it can break booting on previously valid combinations of packages (e.g. u-boot-menu and flash-kernel), which could be an ugly surprise for a bookworm upgrade... live well, vagrant
signature.asc
Description: PGP signature
