Hello!
English is not my main language, so I apologize for any mistakes.
I installed rEFInd and uninstalled Grub2. As a result, initramfs.img and vmlinuz for new kernels are no longer generated.
I tried to do this manually with the command:
sudo dracut --regenerate-all --force
and
sudo dracut --force
How can I get initramfs.img and vmlinuz generation back for current and new kernels?
The package kernel-core-${VER} claims to own/provide /boot/vmlinuz-${VER} and /boot/initramfs-${VER}.img
The vmlinuz file ought to be installed (copied) from package to /boot/
The initramfs file is apparently generated by a line in posttrans script of the package:
/bin/kernel-install add ...
I presume that the /bin/kernel-install invokes dracut.
If the kernel-install or dracut acts on only when something (from GRUB packages) is present, then that would explain the lack of initramfs, but not the lack of vmlinuz.
The /bin/kernel-install script has a number of tests to determine what kind of system it is on and from those tests makes an assumption as to where to install the kernel and initramfs. It may be that the kernel is being installed to a different location now that you have removed grub2. Maybe in /boot/efi/EFI/ somewhere. As far as I know rEFInd does not require the removal of grub2. This may take a lot of time to figure out and fix.
Yes, you are right, kernel-install is trying to install in /boot/efi:
kernel-install add 6.10.3-200.fc40.x86_64 /usr/lib/modules/6.10.3-200.fc40.x86_64/vmlinuz
cp: error writing '/boot/efi/e77df060298e4fd5aa3b415c3ed06017/0-rescue/initrd': No space left on device
dracut[F]: Creation of /boot/efi/e77df060298e4fd5aa3b415c3ed06017/0-rescue/initrd failed
/usr/lib/kernel/install.d/51-dracut-rescue.install: line 91: /boot/efi/loader/entries/e77df060298e4fd5aa3b415c3ed06017-0-rescue.conf: No such file or directory
/usr/lib/kernel/install.d/51-dracut-rescue.install failed with exit status 2.
How to specify the correct directory?
The 51-dracut-rescue.install is from package dracut-config-rescue and for creating “rescue” version. The logic in it is probably same as in other kernel-install scripts. It asks “does directory exists?”. If not, fallback is the /boot. For some reason you seem to have /boot/efi/${MACHINE_ID}/ – that is not in default. This script gets the name of directory as argument, so some other script calls it.
Do you really have /boot/efi/${MACHINE_ID}/ and what is in it?
Why fc40? ELRepo offers kernel-ml – currently 6.10.4-1.el9.elrepo – and that is built for el9.
Yes, there is such a directory.
tree /boot/efi/9d29011577c3487396876de00eb4b763/
/boot/efi/9d29011577c3487396876de00eb4b763/
├── 5.14.0-427.26.1.el9_4.x86_64
│ └── initrd
├── 5.14.0-427.28.1.el9_4.x86_64
│ └── initrd
└── 6.9.8-1.el9.elrepo.x86_64
└── initrd
I created it manually after I got an error the first time I tried to generate the necessary files.
Sorry, it’s my bad. I have Fedora (my workstation) and Rocky Linux (my test server).
In other words, dracut did try to write where we don’t want it to write to. Then you did help it to “do the wrong thing”, which did not make things better. Perhaps reinstall of the GRUB packages would be a better solution.
An issue is that the ESP (EFI System Partition) mounted on /boot/efi is smaller than /boot. The latter defaults to 1 GB and some people manage to fill even that with kernels …
@nihi1ist @jbkt23
Let me add an interesting fact - that also solves the problem in 2 minutes: using dracut with “-f” parameter followed by a directory results in new initrd saved in that directory.
(I just tested it to be sure - works like a charm).
Proof:
Result:
(in the next post, new user restriction)
dnf up will not call dracut with -f snafusnafu/initramfs.img, then only the last would have valid initramfs image. That is why the two approaches that we have seen have either /boot/initrd-$kver.img or snafu/$kver/initrd.imgPS. Copy-paste of text is at least as easy to obfuscate as bitmap images.
How can I run drakut for a specific kernel?
See man dracut
It has examples:
dracut foobar.img 2.6.40-1.rc5.f20
dracut --kver 2.6.40-1.rc5.f20
There is also the note:
If
<image>is omitted or empty, depending on bootloader specification, the default location can be/efi/<machine-id>/<kernel-version>/initrd,/boot/<machine-id>/<kernel-version>/initrd,/boot/efi/<machine-id>/<kernel-version>/initrd,/lib/modules/<kernel-version>/initrdor/boot/initramfs-<kernel-version>.img.
The /usr/bin/dracut is a Bash script and seems to have something like:
if [[ -d "$dracutsysrootdir"/efi/loader/entries || -L "$dracutsysrootdir"/efi/loader/entries ]] \
&& [[ $MACHINE_ID ]] \
&& [[ -d "$dracutsysrootdir"/efi/${MACHINE_ID} || -L "$dracutsysrootdir"/efi/${MACHINE_ID} ]]; then
# 1
outfile="$dracutsysrootdir/efi/${MACHINE_ID}/${kernel}/initrd"
elif [[ -d "$dracutsysrootdir"/boot/loader/entries || -L "$dracutsysrootdir"/boot/loader/entries ]] \
&& [[ $MACHINE_ID ]] \
&& [[ -d "$dracutsysrootdir"/boot/${MACHINE_ID} || -L "$dracutsysrootdir"/boot/${MACHINE_ID} ]]; then
# 2
outfile="$dracutsysrootdir/boot/${MACHINE_ID}/${kernel}/initrd"
elif [[ -d "$dracutsysrootdir"/boot/efi/loader/entries || -L "$dracutsysrootdir"/boot/efi/loader/entries ]] \
&& [[ $MACHINE_ID ]] \
&& [[ -d "$dracutsysrootdir"/boot/efi/${MACHINE_ID} || -L "$dracutsysrootdir"/boot/efi/${MACHINE_ID} ]]; then
# 3
outfile="$dracutsysrootdir/boot/efi/${MACHINE_ID}/${kernel}/initrd"
elif [[ -f "$dracutsysrootdir"/lib/modules/${kernel}/initrd ]]; then
# 4
outfile="$dracutsysrootdir/lib/modules/${kernel}/initrd"
elif [[ -e $dracutsysrootdir/boot/vmlinuz-${kernel} ]]; then
# 5
outfile="$dracutsysrootdir/boot/initramfs-${kernel}.img"
elif [[ -z $dracutsysrootdir ]] \
&& [[ $MACHINE_ID ]] \
&& mountpoint -q /efi; then
# 6
outfile="/efi/${MACHINE_ID}/${kernel}/initrd"
elif [[ -z $dracutsysrootdir ]] \
&& [[ $MACHINE_ID ]] \
&& mountpoint -q /boot/efi; then
# 7
outfile="/boot/efi/${MACHINE_ID}/${kernel}/initrd"
else
# 8
outfile="$dracutsysrootdir/boot/initramfs-${kernel}.img"
fi
The Rocky default is apparently #5. The #2 would be ok too.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.