public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Zhihang Wei <wzh@ilbers.de>
To: Jan Kiszka <jan.kiszka@siemens.com>, isar-users@googlegroups.com
Subject: Re: [PATCH v2] qemuarm-trixie: Workaround with missing drivers in qemuarm-trixie initramfs
Date: Fri, 20 Feb 2026 16:55:15 +0100	[thread overview]
Message-ID: <42fb7bd5-985d-4cf0-8c37-6fa93aa6df5c@ilbers.de> (raw)
In-Reply-To: <6a4c8dd5-16b4-48f5-8164-ab0a28534956@siemens.com>



On 2/20/26 16:36, Jan Kiszka wrote:
> On 20.02.26 15:42, Zhihang Wei wrote:
>> This is a workaround to fix the current qemuarm-trixie image unbootable
>> issue.
>>
>> Starting with Debian Trixie, update-initramfs invokes "dracut-install"
>> to collect and install required drivers into the generated initramfs.
>> "dracut-install" relies on fts_open() / fts_read() from glibc to
>> traverse directories and locate drivers.
>>
>> Due to a long-standing bug [1] between qemu and glibc, the fts_*
>> functions may fail to find files on certain 32-bit architectures. As a
>> result, required modules such as virtio_blk are not detected and not
>> added to the initramfs. The produced image then fails to boot under
>> qemu because the block device driver is missing.
>>
>> A similiar dracut bug report was filed in 2024 [2], pointing to this
>> upstream glibc issue reported in 2018 [1]. No upstream fix has been
>> applied, and the issue appears to affect only qemu builds for specific
>> 32-bit targets.
>>
>> As a temporary workaround, use a customized initramfs-hook to append
>> the neccessary drivers that are currently missed from the initramfs.
>>
>> For a complete fix, we either need to push for an upstream glibc/qemu
>> fix, or convince dracut to avoid using these non-POSIX fts_* functions
>> and use opendir() / readdir() instead.
>>
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
>> [2] https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=1079443
>>
>> Signed-off-by: Zhihang Wei <wzh@ilbers.de>
>> ---
>> Changes in v2:
>> - Use initramfs-hook to install the driver, instead of adding another
>>    variable
>>
>>   meta-isar/conf/multiconfig/qemuarm-trixie.conf            | 4 +++-
>>   .../initramfs-virtio-blk-hook_0.1.bb                      | 8 ++++++++
>>   2 files changed, 11 insertions(+), 1 deletion(-)
>>   create mode 100644 meta/recipes-initramfs/initramfs-virtio-blk-hook/initramfs-virtio-blk-hook_0.1.bb
>>
>> diff --git a/meta-isar/conf/multiconfig/qemuarm-trixie.conf b/meta-isar/conf/multiconfig/qemuarm-trixie.conf
>> index 5600ab23..20eecd92 100644
>> --- a/meta-isar/conf/multiconfig/qemuarm-trixie.conf
>> +++ b/meta-isar/conf/multiconfig/qemuarm-trixie.conf
>> @@ -1,7 +1,9 @@
>>   # This software is a part of Isar.
>> -# Copyright (C) 2024 ilbers GmbH
>> +# Copyright (C) 2024-2026 ilbers GmbH
>>   #
>>   # SPDX-License-Identifier: MIT
>>   
>>   MACHINE ?= "qemuarm"
>>   DISTRO ?= "debian-trixie"
>> +
>> +IMAGE_INSTALL += "initramfs-virtio-blk-hook"
> This covers the initramfs-tools based generation. What if someone
> enables dracut (kas/opt/dracut.yaml)?
A pure dracut generated initramfs for qemuarm-trixie cannot boot. It
surprisingly has virtio_blk, but still not bootable. Need to find the
reason.

Actually, there should be more drivers installed into initramfs by
initramfs-tools, but they are now missing due to the same bug. Adding
virtio-blk just makes this initramfs-tools generated initramfs
"minimally" bootable. My guess is that the dracut generated initramfs
is missing some other necessary drivers.

Zhihang
>> diff --git a/meta/recipes-initramfs/initramfs-virtio-blk-hook/initramfs-virtio-blk-hook_0.1.bb b/meta/recipes-initramfs/initramfs-virtio-blk-hook/initramfs-virtio-blk-hook_0.1.bb
>> new file mode 100644
>> index 00000000..229d91d6
>> --- /dev/null
>> +++ b/meta/recipes-initramfs/initramfs-virtio-blk-hook/initramfs-virtio-blk-hook_0.1.bb
>> @@ -0,0 +1,8 @@
>> +# This software is a part of Isar.
>> +# Copyright (C) 2026 ilbers GmbH
>> +#
>> +# SPDX-License-Identifier: MIT
>> +
>> +inherit initramfs-hook
>> +
>> +HOOK_ADD_MODULES = "virtio-blk"
> Jan
>

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/42fb7bd5-985d-4cf0-8c37-6fa93aa6df5c%40ilbers.de.

  reply	other threads:[~2026-02-20 15:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20 14:42 Zhihang Wei
2026-02-20 15:36 ` 'Jan Kiszka' via isar-users
2026-02-20 15:55   ` Zhihang Wei [this message]
2026-02-20 16:43     ` 'Jan Kiszka' via isar-users

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42fb7bd5-985d-4cf0-8c37-6fa93aa6df5c@ilbers.de \
    --to=wzh@ilbers.de \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox