On 2025-03-11, Vagrant Cascadian wrote:
> 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...
This patch works for me with flash-kernel and u-boot-menu installed,
with U_BOOT_SYNC_DTBS=true|false, but slightly changes the behavior of
U_BOOT_SYNC_DTBS to put files in a different location.
diff --git a/read-config b/read-config
index d25edcc..8798d44 100644
--- a/read-config
+++ b/read-config
@@ -47,7 +47,7 @@ then
_BOOT_PATH="/boot"
if [ "${U_BOOT_SYNC_DTBS}" = "true" ]
then
- _FDT_DIR="/dtb-"
+ _FDT_DIR="/dtbs/"
fi
else
# / and /boot are on the same filesystem
diff --git a/u-boot-update b/u-boot-update
index 6b20e7f..4a35420 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -142,7 +142,7 @@ do
elif [ -d "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/" ]
then
_FDT="fdtdir ${U_BOOT_FDT_DIR}${_VERSION}/"
- elif [ -f "${_BOOT_PATH}/${U_BOOT_FDT:-dtb-${_VERSION}}" ] && [
/usr/lib/linux-image- = "${U_BOOT_FDT_DIR}" ]
+ elif [ -f "${_BOOT_PATH}/${U_BOOT_FDT:-dtb-${_VERSION}}" ] # && [
/usr/lib/linux-image- = "${U_BOOT_FDT_DIR}" ]
then
_FDT="fdt /${U_BOOT_FDT:-dtb-${_VERSION}}"
else
I am not sure if the /usr/lib/linux-image- check is guarding anything
important for other use-cases...
I have not yet checked behavior when /boot and / are on the same
partition where it should just directly use fdtdir
/usr/lib/linux-image-VERSION/ ...
live well,
vagrant
signature.asc
Description: PGP signature
