Check Time: 04:00, September 9, 2026 (Beijing Time)
This issue has been reproduced on both x86_64 and aarch64 architectures. Starting from the official pre-installed openEuler 22.03 LTS SP4 system, running dnf -y update normally, and rebooting immediately after a successful transaction, the default new kernel fails to boot.
The root cause lies in the dracut-055-20.oe2203sp4 package provided by the current Update repository. During the kernel update process, the generated initramfs includes a public boot script with a syntax error from this package. The upstream has already merged the fix and built Release 21, but the official source and mirror entries still serve Release 20.
Users who have recently updated the kernel or rebuilt initramfs are advised to check before rebooting. Pay special attention to the boot image generated by dracut 055-20, and retain the known working old kernel and its initramfs.
Console Errors During Actual Reboot
Both architectures initially run kernel 216 and dracut 055-13, which boot normally. After a full update, both are on kernel 331 and dracut 055-20. DNF returns 0, and the transaction history shows Return-Code: Success. After normal reboot, the serial console displays the following errors, excerpted from the actual x86_64 boot log:
[ 0.972613] dracut-cmdline[266]: /lib/dracut-lib.sh: line 460: unexpected EOF while looking for matching `)'
[ 0.975256] dracut-cmdline[266]: /lib/dracut-lib.sh: line 1158: syntax error: unexpected end of file
[ 1.000416] dracut-cmdline[307]: /bin/dracut-cmdline: line 45: make_trace_mem: command not found
[ 1.038025] dracut-cmdline[347]: /bin/dracut-cmdline: line 54: label_uuid_to_dev: command not found
[ 1.155914] dracut-initqueue[413]: /lib/dracut-lib.sh: line 460: unexpected EOF while looking for matching `)'
Approximately 193 seconds later, x86_64 continues with:
[ 193.355870] dracut-initqueue[413]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
[ 193.358684] dracut-initqueue[413]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
[ 193.363391] dracut-initqueue[413]: [ -e "" ]
[ 193.364633] dracut-initqueue[413]: fi"
[ 193.367791] dracut-initqueue[3590]: /bin/dracut-initqueue: line 111: emergency_shell: command not found
[ 193.370254] dracut-initqueue[413]: Warning: Not all disks have been found.
[ 193.372043] dracut-initqueue[413]: Warning: You might want to regenerate your initramfs.
The aarch64 system exhibits the same parsing errors, missing functions, and empty device path waits, reporting emergency_shell: command not found and Not all disks have been found after about 203 seconds. Neither system reaches normal login.
Where Is the Problem?
The error is located in /usr/lib/dracut/modules.d/99base/dracut-lib.sh, caused by a quote mismatch introduced during the patch adaptation for CVE-2026-15816. Systems still running can perform a read-only check:
rpm -q dracut
bash -n /usr/lib/dracut/modules.d/99base/dracut-lib.sh
On the openEuler experimental machine with Release 20, the check returns a non-zero status, with output including:
line 460: unexpected EOF while looking for matching `)'
line 1158: syntax error: unexpected end of file
Different Bash versions may report slightly different line numbers and unclosed characters. The same file in Release 21 passes the syntax check.
The dracut 99base module copies this file to /lib/dracut-lib.sh in the initramfs. Scripts in the normal boot path load it. The current released kernel RPM calls new-kernel-pkg --mkinitrd --dracut in its post-transaction script, so DNF transactions involving kernel updates automatically generate initramfs and embed this faulty script.
Official Fix and Repository Status
Timeline:
- August 24: The relevant security fix was merged into the 22.03 LTS SP4 branch, with package version
055-20.oe2203sp4. - August 25: Upstream submitted a fix for the quote issue and upgraded the release to 21. See fix commit and merge request !217.
- August 26: Official EulerMaker has built Release 21 binaries for both architectures.
- August 30: The official openEuler-SA-2026-3501 data still lists
055-20.oe2203sp4as the CVE-2026-15816 fix version; the Update 20260824 announcement also includes this security fix. - September 9, 04:00: The 12 entry points, two architectures, and 24 sets of Update metadata checked all still serve dracut Release 20.
The check included repo.openeuler.org, OpenAtom CDN, CERNET joint mirrors, and mirrors from Alibaba Cloud, Tencent Cloud, Huawei Cloud, Tsinghua University, USTC, Nanjing University, HIT, ISRC, and PS.kz. CERNET was redirected to Nanjing University mirror.
Each repomd.xml and primary metadata were read individually, and corresponding RPMs were downloaded and verified with checksums. The Release 20 main packages for both architectures passed official signature verification, and files downloaded from the same architecture across different mirrors were identical. Therefore, simply switching mirror sites will not resolve the issue.
What to Check Before Rebooting
bash -n checks the source file on the system. If you previously updated the kernel or rebuilt initramfs under Release 20, you should also check the script within the boot image intended for use.
First, check the currently running kernel and default boot entry:
uname -r
sudo grubby --default-kernel
ls /boot/initramfs-*.img
Use the initramfs corresponding to the default boot entry as the target. Extract and check the script as follows (replace the first line with the actual image name):
image=/boot/initramfs-actual-kernel-version.img
check_dir=$(mktemp -d)
if sudo lsinitrd -f lib/dracut-lib.sh "$image" > "$check_dir/dracut-lib.sh" \
&& test -s "$check_dir/dracut-lib.sh"; then
bash -n "$check_dir/dracut-lib.sh"
else
echo 'Failed to extract script. Please check image path, content, and lsinitrd error'
fi
This script performs a syntax check only if extraction succeeds and the file is non-empty. Confirm the script in the target image is fixed, retain the working old boot entry, then proceed with reboot.
Repair and Recovery Recommendations
Prioritize using the official dracut package with the fix, and synchronize updates for other source-matching subpackages like dracut-network, dracut-squash, etc. Although the official Update has not yet provided Release 21, the official EulerMaker has signed build artifacts:
The same build directory contains corresponding subpackages. These official build artifacts are awaiting inclusion in the official Update release. Community members are encouraged to expedite formal release and provide unified repair guidance. Install with signature verification preserved.
After fixing dracut, regenerate the initramfs for affected kernels, verify the script within it, and then schedule a reboot for validation. Before proceeding, back up the target initramfs and retain the known working old kernel and its boot image.
For machines that can no longer boot, first try booting with the old kernel that retains the original initramfs. If the backup boot image is also affected, use a rescue medium or mount the system disk for repair.
Experimental Results and Community Verification Needed
This round used independent clones of the official pre-installed image for normal update and reboot validation. The fault was successfully reproduced on both architectures. A controlled repair test was also conducted: first installing the official dracut 21 and matching subpackages, then running the same full update command and reboot. Both architectures successfully booted into the same 331 kernel, restored SSH access, and systemctl is-system-running returned running, with zero failed units. The only difference in the complete package list between the two architectures was the 20/21 version of the three dracut source-matching packages.
The number of affected machines is still under assessment.
We urge the community to confirm: Why has Release 21 not yet entered the Update? Should Release 20 be withdrawn or replaced? How can users who have installed this package—especially those who have rebuilt initramfs—be alerted? Should post-kernel-update boot testing and boot script syntax checking be included in regression testing?