Bugzilla – Bug 1067503
plymouth can fail to build the initrd during the installation
Last modified: 2017-12-13 12:37:29 UTC
After a standard installation, I found this error in /var/log/zypp/history: # 2017-11-09 08:51:25 plymouth-branding-openSUSE-13.3-8.8.noarch.rpm installed ok # Additional rpm output: # dracut: Cannot find module directory /lib/modules/4.13.9-1-default/ # dracut: and --no-kernel was not specified # warning: %post(plymouth-branding-openSUSE-13.3-8.8.noarch) scriptlet failed, exit status 1 # 2017-11-09 08:51:25|install|plymouth-branding-openSUSE|13.3-8.8|noarch||openSUSE-20171104-0|8e627ac7ffa7b9ddc9faec03b4552dbe01c6ff2c| What happens is the following: the post install scriptlet of plymouth-branding-openSUSE calls: plymouth-set-default-theme which in turn calls: /usr/lib/plymouth/plymouth-update-initrd which executes: dracut -f which fails with the error message showed above. The reason for the failure is that the kernel running during the installation (the one present in http://download.opensuse.org/tumbleweed/repo/oss/boot/x86_64/loader/initrd, currently version 3.13.9) may be different from the one in the installed system (currently http://download.opensuse.org/tumbleweed/repo/oss/suse/x86_64/kernel-default-4.13.10-1.4.x86_64.rpm) So the command dracut -f try to build a initrd for kernel 3.13.9 but such kernel does not exist in the installed system, therefore the error message. This error message started to appear recently when the script plymouth-update-initrd changed the command it executes from mkinitrd -B to dracut -f The script mkinitrd does the proper thing by checking which kernels are installed before generating initrd. I suggest to revert back to mkinitrd or add more logic in plymouth-update-initrd to make dracut generate the initrd for the appropriate kernel version.
Hi Josef: Sorry to involve you in this issue. Because as you are the Yast-installation expert, I have a question must ask you: In this bug, I want the RPM post-installation script has a judgment to act as different behavior between openSUSE installation period and normal system period, Is there any *Maintained* flag/environment value/interface I can use. I mean this flag will always enable in the releases in future time. Thanks so much!
Hi zhao, it is more question for steffen winterfeld, which maintain installation images. There is e.g. /.packages.root file and others, but I am not sure which one is maintained and guaranteed.
(In reply to Josef Reidinger from comment #2) Thanks for the information, I don't know much about YAST team's work division. sorry for the noise. :-)
dracut runs chroot-ed I think. So checking for some files would not help. But for grub2 setup we use this check: if [ "$YAST_IS_RUNNING" = instsys ]; then # ... fi Maybe this would also help in your case.
(In reply to Zhao Qiang 赵强 from comment #1) > In this bug, I want the RPM post-installation script has a judgment to act > as different behavior between openSUSE installation period and normal system > period, You probably don't, it's the wrong condition. Calling "dracut -f" is wrong anyway, it only recreates an initramfs for the currently running kernel, so if a new kernel got installed it'll keep the wrong theme. The correct way IMO is: - Replace dracut -f in /usr/lib/plymouth/plymouth-update-initrd with mkinitrd -B - Don't call /usr/lib/plymouth/plymouth-update-initrd with -R in the .spec file - Instead, add %post %regenerate_initrd_post and %posttrans %regenerate_initrd_posttrans That way it also won't do unnecessary initramfs rebuilds.
(In reply to Fabian Vogt from comment #5) > (In reply to Zhao Qiang 赵强 from comment #1) > You probably don't, it's the wrong condition. > Calling "dracut -f" is wrong anyway, it only recreates an initramfs for the > currently running kernel, so if a new kernel got installed it'll keep the > wrong theme. > > The correct way IMO is: > - Replace dracut -f in /usr/lib/plymouth/plymouth-update-initrd with > mkinitrd -B > - Don't call /usr/lib/plymouth/plymouth-update-initrd with -R in the .spec > file > - Instead, add %post %regenerate_initrd_post and %posttrans > %regenerate_initrd_posttrans > > That way it also won't do unnecessary initramfs rebuilds. Thank you for your detailed support information. Yes, Replace with "mkinitrd -B" is also the reporter Mr. Giacomo focused on. But I still have a little concern: "mkinitrd -B" will make the initrd update but not refresh the bootloader, the user might need to refresh it manually. But this bug's real requirement is to assign the correct kernel edition which same as after installation. So, is there any help with the "-B" option? Sorry, I didn't follow you.
(In reply to Zhao Qiang 赵强 from comment #6) > (In reply to Fabian Vogt from comment #5) > > (In reply to Zhao Qiang 赵强 from comment #1) > > You probably don't, it's the wrong condition. > > Calling "dracut -f" is wrong anyway, it only recreates an initramfs for the > > currently running kernel, so if a new kernel got installed it'll keep the > > wrong theme. > > > > The correct way IMO is: > > - Replace dracut -f in /usr/lib/plymouth/plymouth-update-initrd with > > mkinitrd -B > > - Don't call /usr/lib/plymouth/plymouth-update-initrd with -R in the .spec > > file > > - Instead, add %post %regenerate_initrd_post and %posttrans > > %regenerate_initrd_posttrans > > > > That way it also won't do unnecessary initramfs rebuilds. > > Thank you for your detailed support information. > Yes, Replace with "mkinitrd -B" is also the reporter Mr. Giacomo focused on. > But I still have a little concern: > "mkinitrd -B" will make the initrd update but not refresh the bootloader, > the user might need to refresh it manually. But this bug's real requirement > is to assign the correct kernel edition which same as after installation. > So, is there any help with the "-B" option? > Sorry, I didn't follow you. Refreshing the bootloader is not needed when calling just "plymouth-set-default-theme", which is the only way to end up in plymouth-update-initrd. The only place when refreshing the bootloader is really necessary is at the end of zypper runs, where the package's %posttrans takes care of it.
Thank you very much for your explanation. Yes, the idea is logically correct. So, I have reviewed the "mkinitrd" process again, and I found that it will judge if there has a "-B" option, if the answer is Yes, it only show a message to reminding the user, if the answer is No, it will call "update-bootloader" to refresh. at last, it calls dracut --force to re-install the initramfs. So, maybe the author omitted that dracut is sure to refresh the bootloader. and In fact, mkinitrd refresh bootloader for 2 times without "-B" option. Beyond this, mkinitrd just keep some log with dracut. So I think the reasons for switch dracut to mkinitrd are not sufficient currently. From another point of view，This bug is primarily a matter of an initramfs edition error which caused by kernel versions non-matching. So I think maybe we will make most of following works focus on the *Search* for the installed kernel edition on the next step?
(In reply to Zhao Qiang 赵强 from comment #8) > Thank you very much for your explanation. Yes, the idea is logically correct. > > So, I have reviewed the "mkinitrd" process again, and I found that it will > judge if there has a "-B" option, if the answer is Yes, it only show a > message to reminding the user, if the answer is No, it will call > "update-bootloader" to refresh. at last, it calls dracut --force to > re-install the initramfs. > So, maybe the author omitted that dracut is sure to refresh the bootloader. > and In fact, mkinitrd refresh bootloader for 2 times without "-B" option. > Beyond this, mkinitrd just keep some log with dracut. So I think the reasons > for switch dracut to mkinitrd are not sufficient currently. You misunderstand. The -B option does not matter here, what matters is that mkinitrd calls dracut --force for all installed kernel versions. > From another point of view，This bug is primarily a matter of an initramfs > edition error which caused by kernel versions non-matching. So I think maybe > we will make most of following works focus on the *Search* for the installed > kernel edition on the next step?