Bug 1810504 - initrd generated with dracut-050-1 with busybox module enabled does not boot
Summary: initrd generated with dracut-050-1 with busybox module enabled does not boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-05 11:50 UTC by Marien Zwart
Modified: 2020-06-01 01:24 UTC (History)
6 users (show)

Fixed In Version: dracut-050-61.git20200529.fc32
Clone Of:
Environment:
Last Closed: 2020-06-01 01:24:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Marien Zwart 2020-03-05 11:50:40 UTC
Description of problem:
An initrd generated with dracut-050-1 with the busybox module enabled boots to a shell without a working /dev or the root filesystem mounted, and complaints about /dev/tty2 - /dev/tty4 being unavailable every few seconds. The previous version of dracut (049-27.git20181204.fc32.2) worked, and it works if I remove busybox from add_dracutmodules.

Version-Release number of selected component (if applicable): dracut-050-1.fc32.x86_64

How reproducible:
always

Steps to Reproduce:
1. put add_dracutmodules+=" busybox" in /etc/dracut.conf.d/busybox.conf
2. dracut --force /boot/.../initrd
3. reboot

Actual results:
System boots to shell prompt

Expected results:
System boots normally

Additional info:
Looking at lsinitrd, all symlinks to /usr/bin/busybox are in the initramfs "/", not in /usr/sbin/ or /usr/bin as they were on the previous version. This includes /init being a symlink to /usr/bin/busybox (not to usr/lib/systemd/systemd as it was on the previous version). We're probably booting into busybox's init instead of the intended systemd, which probably tries to spawn a few shells by default.

Looking at upstream commits and --debug output, the find_binary changes in https://github.com/dracutdevs/dracut/commit/a01204202b3014c0c761c93bc7de8bf35e6dc5ef look suspicious. The busybox module calls "ln_r /usr/bin/busybox $_path" after "_path=$(find_binary "$_i")". Running dracut with --debug shows:

//usr/lib/dracut/modules.d/05busybox/module-setup.sh@26(install): find_binary awk
//usr/lib/dracut/dracut-functions.sh@43(find_binary): local _delim
//usr/lib/dracut/dracut-functions.sh@44(find_binary): local l
//usr/lib/dracut/dracut-functions.sh@45(find_binary): local p
//usr/lib/dracut/dracut-functions.sh@46(find_binary): [[ -z awk ]]
//usr/lib/dracut/dracut-functions.sh@46(find_binary): _delim=/
//usr/lib/dracut/dracut-functions.sh@48(find_binary): [[ awk == *.so* ]]
//usr/lib/dracut/dracut-functions.sh@60(find_binary): [[ awk == */* ]]
//usr/lib/dracut/dracut-functions.sh@66(find_binary): for p in $DRACUT_PATH
//usr/lib/dracut/dracut-functions.sh@67(find_binary): [[ -L /sbin/awk ]]
//usr/lib/dracut/dracut-functions.sh@67(find_binary): [[ -x /sbin/awk ]]
//usr/lib/dracut/dracut-functions.sh@66(find_binary): for p in $DRACUT_PATH
//usr/lib/dracut/dracut-functions.sh@67(find_binary): [[ -L /bin/awk ]]
//usr/lib/dracut/dracut-functions.sh@68(find_binary): printf '%s\n' awk
//usr/lib/dracut/dracut-functions.sh@69(find_binary): return 0
/usr/lib/dracut/modules.d/05busybox/module-setup.sh@26(install): _path=awk
/usr/lib/dracut/modules.d/05busybox/module-setup.sh@27(install): '[' -z awk ']'
/usr/lib/dracut/modules.d/05busybox/module-setup.sh@28(install): ln_r /usr/bin/busybox awk
/usr/lib/dracut/dracut-init.sh@1004(ln_r): ln -sfnr /var/tmp/dracut.Xxhyr8/initramfs//usr/bin/busybox /var/tmp/dracut.Xxhyr8/initramfs/awk

find_binary found awk in $dracutsysrootdir/bin/awk, and prints "awk". It looks like it should print "/bin/awk" instead.

Please let me know if you need additional information or logs.

Comment 1 Harald Hoyer 2020-05-29 17:55:41 UTC
https://github.com/dracutdevs/dracut/pull/825 merged into master

Comment 2 Fedora Update System 2020-05-29 19:00:42 UTC
FEDORA-2020-e7e6d3badb has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e7e6d3badb

Comment 3 Fedora Update System 2020-05-30 04:04:13 UTC
FEDORA-2020-e7e6d3badb has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e7e6d3badb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e7e6d3badb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 4 Fedora Update System 2020-06-01 01:24:51 UTC
FEDORA-2020-e7e6d3badb has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.