Dracut fails to build initramfs on Fedora 44 due to neovim's broken lpeg.so NEEDED entry

Ask Fedora
, , ,
1

My Setup:

Fedora 44 (KDE), dracut 108-7.fc44, neovim-0.12.4-3.fc44. No nano, vim, or vim-minimal installed — vi/vim were both managed via alternatives, pointing to /usr/bin/nvim (the only registered alternative).

Symptom:
After a routine dnf update that pulled in kernel 7.0.12-201.fc44 and 7.1.3-200.fc44, neither kernel would boot — GRUB loaded vmlinuz, then failed and restarted on Enter. Root cause: no initramfs was ever generated for either kernel (/boot/initramfs-*.img missing for both).

Running dracut manually failed with:

dracut-install: ERROR: could not locate dependency /usr/lib64/lua/5.1/lpeg.so requested by '/var/tmp/dracut.XXXXX/initramfs/usr/bin/nvim'
xargs: /usr/lib/dracut/dracut-install: exited with status 255; aborting
dracut\[F\]: Resolving executable dependencies failed

Root cause:
Fedora’s dracut default config (/usr/lib/dracut/dracut.conf.d/01-dist.conf) always attempts to optionally stage vi:

install_optional_items+=" vi /usr/libexec/vi /etc/virc ps grep cat rm "

On systems where vi/vim resolve to nvim via alternatives, dracut-install tries to resolve nvim’s full dependency chain. readelf -d /usr/bin/nvim shows:

NEEDED   Shared library: [/usr/lib64/lua/5.1/lpeg.so]

That’s an absolute path in the NEEDED entry, unlike every other dependency (libluv.so.1 , libtree-sitter.so.0.26 , etc., which use bare sonames). lpeg.so is a Lua C module with no SONAME.

Workaround:
I installed nano and overrode dracut’s install list to use it in place of vi, without changing what vi/vim point to system-wide:

dnf install nano

/etc/dracut.conf.d/99-editor-override.conf:

install_optional_items=" nano ps grep cat rm "

After that, dracut --force regenerated both initramfs images successfully and both kernels boot normally.

Should this be reported? If so, where? I believe this is a packaging bug in Fedora’s neovim RPM (or possibly a dracut-install limitation), but I’m not sure which project owns the fix. Some direction would be appreciated.

2

Maybe this is a neovim issue if its symlinking to /usr/bin/vi which is breaking dracut. My thought is that if the user wants a alias to neovim called vi then the user can add that to there .bashrc as a alias.

3

Probably not a neovim issue. I think it’s just an issue with my setup. I used alternatives to manage vi/vim and link them to nvim. It’s not something that happened by default when installing nvim. I like being able to use nvim when I accidentally type vi/m in my root shell or if something doesn’t respect the $EDITOR variable. Little did I know that lua and dracut don’t play nice out of the box.

4

Installing neovim will cause the file /usr/lib64/lua/5.1/lpeg.so to be installed as a dependency, so if is missing on your system, that is another problem.

5

It is installed. The bis is the way in which nvim states that dependency:

readelf -d /usr/bin/nvim

Dynamic section at offset 0x52cfc0 contains 37 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libluv.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [/usr/lib64/lua/5.1/lpeg.so]
 0x0000000000000001 (NEEDED)             Shared library: [libtree-sitter.so.0.26]
 0x0000000000000001 (NEEDED)             Shared library: [libutf8proc.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libunibilium.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libluajit-5.1.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libuv.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

lpeg.so is the outlier here.

That being said: I don’t know if I’d want a full nvim in my initramfs …

6

The preferred way in Fedora to define an alternative for vi is to create an alias. In a default installation you have
type vi

vi is aliased to `vim'

Then the real /usr/bin/vi is the minimal vim variant that is included in the initramfs.

7

So the prefered fix is to re-install true vi, revert my dracut changes, and configure my root and personal users with aliases. Is using alternatives to point vi to nvim alone my problem or is my issue that I used alternatives and removed vi.

Also, is this worth escalating to the packagers of nvim?

 0x0000000000000001 (NEEDED)             Shared library: [/usr/lib64/lua/5.1/lpeg.so]
8

I won’t tell you you should do. Your fix by installing nano into the initrd is also fine. In Fedora it is preferred to use an alias, but as far as I know, Ubuntu would use alternatives for alternative vi commands. Maybe creating a symbolic link to /usr/bin/nvim in /usr/local/bin/vi would work as well.

Your original analysis is correct as far as I can tell.