[PATCH] kernel: use absolute paths in the kernel-image scripts

[PATCH] kernel: use absolute paths in the kernel-image scripts

[WXbet]

From: WXbet <57314510+WXbet@users.noreply.github.com>

On the target, the postinst of kernel-image-<type> creates the
${KERNEL_IMAGEDEST}/<type> link with a path relative to the current
directory, and the postrm removes it the same way. opkg runs package
scripts in the directory of its caller, so an upgrade started from any
directory other than / makes ln fail. The fallback then copies the image
with install, which the busybox defconfig does not enable:

  sh: install: command not found

and the postrm leaves the link behind.

Anchor the link location at / as the rootfs-time case anchors it at $D.
The link target stays relative to ${KERNEL_IMAGEDEST}.

Signed-off-by: WXbet <57314510+WXbet@users.noreply.github.com>
---

Notes:
    The relative path seems to date back to bb946b8cdb ("classes/kernel: Use
    a copy of image for kernel*.rpm if fs doesn't support symlinks"), which
    moved the link from do_install into the postinst. When $D is set at rootfs
    time, the link is still anchored at $D. If the on-target case is meant to
    be relative to the current directory, please let me know how package
    managers are expected to call it.

 meta/classes-recipe/kernel.bbclass | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
index 0a6d754108..8d8af113f7 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -136,17 +136,17 @@ python __anonymous () {
 if [ -n "$D" ]; then
     ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
 else
-    ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+    ln -sf %s-${KERNEL_VERSION} /${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
     if [ $? -ne 0 ]; then
-        echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back to copied image (%s)."
-        install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s
+        echo "Filesystem on /${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back to copied image (%s)."
+        install -m 0644 /${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} /${KERNEL_IMAGEDEST}/%s
     fi
 fi
 set -e
 """ % (type, type, type, type, type, type, type))
             d.setVar('pkg_postrm:%s-image-%s' % (kname,typelower), """set +e
-if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
-    rm -f ${KERNEL_IMAGEDEST}/%s  > /dev/null 2>&1
+if [ -f "/${KERNEL_IMAGEDEST}/%s" -o -L "/${KERNEL_IMAGEDEST}/%s" ]; then
+    rm -f /${KERNEL_IMAGEDEST}/%s  > /dev/null 2>&1
 fi
 set -e
 """ % (type, type, type))
-- 
2.47.1.windows.1

Re: [PATCH] kernel: use absolute paths in the kernel-image scripts

[Paul Barker]

On Mon, 2026-09-14 at 20:21 +0200, WXbet wrote:
> From: WXbet <57314510+WXbet@users.noreply.github.com>
> 
> On the target, the postinst of kernel-image-<type> creates the
> ${KERNEL_IMAGEDEST}/<type> link with a path relative to the current
> directory, and the postrm removes it the same way. opkg runs package
> scripts in the directory of its caller, so an upgrade started from any
> directory other than / makes ln fail. The fallback then copies the image
> with install, which the busybox defconfig does not enable:
> 
>   sh: install: command not found
> 
> and the postrm leaves the link behind.

This describes two issues, we shouldn't just fix one of them. We should
also fix the on-target postinst script relying on a command that is by
default missing if you use busybox.

I think should just enable CONFIG_INSTALL in the busybox defconfig. That
shouldn't use much disk space and trying to handle the potential absense
of `install` on the device in various scripts would be a lot of work.

> 
> Anchor the link location at / as the rootfs-time case anchors it at $D.
> The link target stays relative to ${KERNEL_IMAGEDEST}.
> 
> Signed-off-by: WXbet <57314510+WXbet@users.noreply.github.com>
> ---
> 
> Notes:
>     The relative path seems to date back to bb946b8cdb ("classes/kernel: Use
>     a copy of image for kernel*.rpm if fs doesn't support symlinks"), which
>     moved the link from do_install into the postinst. When $D is set at rootfs
>     time, the link is still anchored at $D. If the on-target case is meant to
>     be relative to the current directory, please let me know how package
>     managers are expected to call it.

Looking at KERNEL_IMAGEDEST, it's weakly assigned in two places:

    meta/classes-recipe/kernel-fit-image.bbclass:
        KERNEL_IMAGEDEST ?= "/boot"

    meta/classes-recipe/kernel.bbclass
        KERNEL_IMAGEDEST ?= "boot"

I think the solution is to use an absolute path for this variable in
kernel.bbclass. Then the rest of this patch becomes unnecessary, but we
still need a follow up patch to enable CONFIG_INSTALL in the busybox
defconfig.

Are you able to send a v2 series fixing both issues?

Best regards,

-- 
Paul Barker

Re: [PATCH] kernel: use absolute paths in the kernel-image scripts

[WXbet]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

Hi Paul,

On Sat, 2026-09-26, Paul Barker wrote:
> This describes two issues, we shouldn't just fix one of them. We should
> also fix the on-target postinst script relying on a command that is by
> default missing if you use busybox.
>
> I think should just enable CONFIG_INSTALL in the busybox defconfig.

Agreed, I'll include that in v2.

> I think the solution is to use an absolute path for this variable in
> kernel.bbclass. Then the rest of this patch becomes unnecessary

I looked into this. Changing the default alone breaks the build:
kernel.bbclass and kernel-devicetree.bbclass prefix the variable with
'/' in FILES:

kernel.bbclass:121    '/' + imagedest + '/' + type + ...
kernel.bbclass:685    /${KERNEL_IMAGEDEST}/System.map* ...
kernel.bbclass:686    /${KERNEL_IMAGEDEST}/vmlinux-...
kernel-devicetree.bbclass:17-21  /${KERNEL_DTBDEST}/... (defaults to
${KERNEL_IMAGEDEST})

With "/boot" these become "//boot/...", which populate_packages rejects
with files-invalid. That check is in CHECKLAYER_REQUIRED_TESTS, so it
is an error by default.

We can drop the '/' prefix in oe-core, but BSP layers that write
"/${KERNEL_IMAGEDEST}" in their own FILES or do_install and keep the
default would then fail with the same QA error. That pattern is common
because it is what oe-core itself uses today.

So I see two options for v2:

1) Keep the fix in the postinst/postrm scripts as in v1, plus the
busybox patch. No change for layers.

2) KERNEL_IMAGEDEST ?= "/boot", drop the '/' prefix in the FILES
entries in oe-core, plus the busybox patch, and a migration note
for layers that use "/${KERNEL_IMAGEDEST}" in FILES.

Which one would you prefer?

Best regards,
WXbet

[-- Attachment #2: Type: text/html, Size: 2197 bytes --]