Description of problem: After kernel upgrade to 4.8.10-300 I saw info about load modules fail. System boots I've checked systemd-modules-load.service as there was an info about it. There were no errors. I didn't make any changes in /etc/dracut.conf, /etc/dracut.conf.d/ or /etc/modules-load.d/ dmesg shows some problems with pptp https://paste.fedoraproject.org/493846/578148/ There is one config file in /usr/lib/modules-load.d/pptp.conf # Load nf_conntrack_pptp.ko at boot nf_conntrack_pptp I have add config file to dracut.conf.d add_drivers+=" nf_conntrack_pptp " Then rebuild initramfs. Now there is no error. Version-Release number of selected component (if applicable): How reproducible: install pptp and upgrade to newest kernel Steps to Reproduce: 1. 2. 3. Actual results: Working with config in dracut.conf.d folder Expected results: Fix Additional info: Sorry for my english
Have the same problem after update to kernel 4.8.10. systemd-modules-load[231]: Failed to find module 'nf_conntrack_pptp' With kernel 4.8.8 no problems.
Same but shouldn't this be filed against dracut? I posted about this last night before finding the output containing any reference to pptp. https://bugzilla.redhat.com/show_bug.cgi?id=1254340#c7 Kernel4.8.10-300.fc25.x86_64 Nov 30 23:33:33 KABINI.fedora systemd-modules-load[187]: Failed to find module 'nf_conntrack_pptp' Manifestation: [FAILED] failed to start load kernel modules See 'systemctl status systemd-modules-load.service' for details . Output of suggested status check seems to indicate no problem when the boot process completes: systemctl status systemd-modules-load.service ● systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled) Active: active (exited) since Thu 2016-12-01 07:44:36 GMT; 4min 24s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 700 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Main PID: 700 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) CGroup: /system.slice/systemd-modules-load.service
IIRC there was an problem with selinux policy blocking the systemd service to load the modules. I think it's fixed now in selinux policy. Adding the modules to dracut image just workaround the problem, because there is no selinux. I think you usually don't need the module in dracut image.
Thanks for the input, it's interesting that your bug was re-assigned to dracut then. so do you think selinux is to blame this time as well? https://bugzilla.redhat.com/show_bug.cgi?id=1254340#c3
(In reply to Mike Simms from comment #4) I have currently trouble to reproduce the problem, could the reporter or somebody try to reboot with selinux disabled to verify that the error is caused by selinux? And if yes please retry with the latest selinux-policy. > Thanks for the input, it's interesting that your bug was re-assigned to > dracut then. so do you think selinux is to blame this time as well? > > https://bugzilla.redhat.com/show_bug.cgi?id=1254340#c3 No, I think the bug 1254340 is different problem. It's manifests with some akmods packages, i.e.: - update of kernel regenerates dracut image - old version of module is loaded and old module is on disk, new module is not in new kernel path thus it is not inserted to the dracut image - reboot occurs, module doesn't exists in dracut image thus it cannot be loaded by systemd service, which resulted in error - akmods rebuild the module during reboot - you have to regenerate the dracut image by hand to get rid of the error (which is usually harmless, because the module gets inserted later when not ).
Disabling selinux had no effect (temporarily done via grub2 using kernel command line option selinux=0 and verified Disabled with /usr/sbin/getenforce) neither did updating to selinux-policy-3.13.1-225.fc25.noarch and selinux-policy-targeted-3.13.1-225.fc25.noarch which lead to a file system relabel.
Same issue here: Version-Release number of selected component (if applicable): kernel-4.8.6-300.fc25.x86_64 kernel-4.8.8-300.fc25.x86_64 kernel-4.8.10-300.fc25.x86_64 systemd-231-10.fc25.x86_64 How reproducible: on every boot on one machine Steps to Reproduce: 1. boot Kernel 4.8.10 instead of 4.8.8 Actual results: At boot, right before I'm prompted for my cryptsetup password, just after systemd is being started, I'm getting a scary warning that systemd-modules-load.service has failed and that I should consult `systemctl status systemd-modules-load.service` for details, but it looks clean after boot: $ systemctl status systemd-modules-load.service ● systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled) Active: active (exited) since Do 2016-12-01 12:34:07 CET; 13min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 670 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Main PID: 670 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) CGroup: /system.slice/systemd-modules-load.service I couldn't note any other problem while running the 4.8.10 kernel. Expected results: Boot without errors, as does 4.8.8. Additional info: This bug might be a duplicate of or cause for bug #1399775 because I'm getting same firewalld log messages. But note that that bug is happening with 4.8.8 already… $ systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Do 2016-12-01 12:34:11 CET; 10min ago Docs: man:firewalld(1) Main PID: 889 (firewalld) Tasks: 3 (limit: 4915) CGroup: /system.slice/firewalld.service └─889 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid Dez 01 12:34:08 hostname systemd[1]: Starting firewalld - dynamic firewall daemon... Dez 01 12:34:11 hostname systemd[1]: Started firewalld - dynamic firewall daemon. Dez 01 12:34:11 hostname firewalld[889]: WARNING: FedoraServer: INVALID_SERVICE: cockpit Dez 01 12:34:11 hostname firewalld[889]: WARNING: INVALID_HELPER: 'nf_conntrack_netbios_ns' not available in kernel
(In reply to Doaxan from comment #1) > Have the same problem after update to kernel 4.8.10. > systemd-modules-load[231]: Failed to find module 'nf_conntrack_pptp' > > With kernel 4.8.8 no problems. I should have added that I'm seeing the exact same line in my syslog during boot at the time systemd-modules-load is failing.
Created attachment 1226800 [details] from journalctl -b (In reply to Jaroslav Škarvada from comment #5) > (In reply to Mike Simms from comment #4) > I have currently trouble to reproduce the problem, could the reporter or > somebody try to reboot with selinux disabled to verify that the error is > caused by selinux? And if yes please retry with the latest selinux-policy. I'm running selinux-policy-3.13.1-224.fc25.noarch and adding "selinux=0" to kernel command line doesn't work around this bug. I've noted that dmesg shows this right before the bug happens: [ 2.944377] audit: type=1130 audit(1480594097.759:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-modules-load comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' more details (syslog) attached. For providing more info I probably need to know how to get to a rescue shell.
lsinitrd shows that the 4.8.8 kernel initramfs doesn't include any file related to pptp. lsinitrd shows that the 4.8.10 kernel initramfs ships a file /usr/lib/modules-load.d/pptp.conf which just contains these two lines: # Load nf_conntrack_pptp.ko at boot nf_conntrack_pptp but the 4.8.10 initramfs doesn't ship the nf_conntrack_pptp.ko file. The file is correctly located in my fully booted system's rootfs under /usr/lib/modules/4.8.10-300.fc25.x86_64/kernel/net/netfilter/nfxconntrack_pptp.ko.xz. The /usr/lib/modules-load.d/pptp.conf file is provided by pptp-1.8.0-9.fc25 but was not provided by pptp-1.8.0-8.fc25. So this is the place where the regression happened: https://pkgs.fedoraproject.org/cgit/rpms/pptp.git/commit/?h=f25&id=4c030e05b7bc939b97cca5023032af2879eb9ae8 which was intended to fix bug #1373689.
(In reply to Christian Stadelmann from comment #10) > lsinitrd shows that the 4.8.8 kernel initramfs doesn't include any file > related to pptp. > > lsinitrd shows that the 4.8.10 kernel initramfs ships a file > /usr/lib/modules-load.d/pptp.conf which just contains these two lines: > > # Load nf_conntrack_pptp.ko at boot > nf_conntrack_pptp > > but the 4.8.10 initramfs doesn't ship the nf_conntrack_pptp.ko file. > > The file is correctly located in my fully booted system's rootfs under > /usr/lib/modules/4.8.10-300.fc25.x86_64/kernel/net/netfilter/ > nfxconntrack_pptp.ko.xz. > > The /usr/lib/modules-load.d/pptp.conf file is provided by pptp-1.8.0-9.fc25 > but was not provided by pptp-1.8.0-8.fc25. So this is the place where the > regression happened: > https://pkgs.fedoraproject.org/cgit/rpms/pptp.git/commit/ > ?h=f25&id=4c030e05b7bc939b97cca5023032af2879eb9ae8 which was intended to fix > bug #1373689. Thanks for info. The error itself should be harmless, AFAIK the modules are loaded twice, so it should be correctly loaded later from file system. We could add dracut config file to /etc/dracut.conf.d, but I am currently not sure whether it is the right way to go. I think that you don't need this module in dracut image. I also think that the systemd should support a way how to control that some module needn't be loaded from the dracut. Or if dracut uses and automatically includes all systemd modules load config files it could parse them and add all the listed modules automatically.
(In reply to Jaroslav Škarvada from comment #11) > The error itself should be harmless, AFAIK the modules are > loaded twice, so it should be correctly loaded later from file system. We > could add dracut config file to /etc/dracut.conf.d, but I am currently not > sure whether it is the right way to go. I think that you don't need this > module in dracut image. I also think that the systemd should support a way > how to control that some module needn't be loaded from the dracut. Or if > dracut uses and automatically includes all systemd modules load config files > it could parse them and add all the listed modules automatically. I think it is harmless, too. And I share your opinion that this module isn't needed in initramfs. From `man 5 modules-load.d`: systemd-modules-load.service(8) reads files from the above directories which contain kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/program.conf. Note that it is usually a better idea to rely on the automatic module loading by PCI IDs, USB IDs, DMI IDs or similar triggers encoded in the kernel modules themselves instead of static configuration like this. In fact, most modern kernel modules are prepared for automatic loading already. Couldn't pptp use modprobe instead? Isn't pptp running as root anyway?
(In reply to Christian Stadelmann from comment #12) > (In reply to Jaroslav Škarvada from comment #11) > > The error itself should be harmless, AFAIK the modules are > > loaded twice, so it should be correctly loaded later from file system. We > > could add dracut config file to /etc/dracut.conf.d, but I am currently not > > sure whether it is the right way to go. I think that you don't need this > > module in dracut image. I also think that the systemd should support a way > > how to control that some module needn't be loaded from the dracut. Or if > > dracut uses and automatically includes all systemd modules load config files > > it could parse them and add all the listed modules automatically. > > I think it is harmless, too. And I share your opinion that this module isn't > needed in initramfs. > > From `man 5 modules-load.d`: > > systemd-modules-load.service(8) reads files from the above directories which > contain kernel modules to load during boot in a static list. Each > configuration file is named in the style of > /etc/modules-load.d/program.conf. Note that it is usually a better idea to > rely on the automatic module loading by PCI IDs, USB IDs, DMI IDs or similar > triggers encoded in the kernel modules themselves instead of static > configuration like this. In fact, most modern kernel modules are prepared > for automatic loading already. > > Couldn't pptp use modprobe instead? Isn't pptp running as root anyway? We could workaround it in the code by using exec modprobe or by linking with libkmod or maybe by using shell wrapper, this should be discussed upstream, because it's not fedora specific. I am going to open the discussion. I think this is not only pptp problem. There should be a mechanism how to specify which modules to load or not to load in dracut or dracut should grab all the listed modules automatically (but probably better to have modules-load config which is not used by dracut). Reassigning to dracut.
(In reply to Christian Stadelmann from comment #9) > Created attachment 1226800 [details] > from journalctl -b > > (In reply to Jaroslav Škarvada from comment #5) > > (In reply to Mike Simms from comment #4) > > I have currently trouble to reproduce the problem, could the reporter or > > somebody try to reboot with selinux disabled to verify that the error is > > caused by selinux? And if yes please retry with the latest selinux-policy. > > I'm running selinux-policy-3.13.1-224.fc25.noarch and adding "selinux=0" to > kernel command line doesn't work around this bug. @Christian - That was not a workaround, I was simply describing the method I used to check if selinux policy was responsible as requested by Jaroslav. I put the method in the post in case anyone else wanted to try the same in future. If you read my post in full you would realise it of course did not make any difference disabling selinux policy. I thought I made that clear enough.
(In reply to Mike Simms from comment #14) > (In reply to Christian Stadelmann from comment #9) > > I'm running selinux-policy-3.13.1-224.fc25.noarch and adding "selinux=0" to > > kernel command line doesn't work around this bug. > > @Christian - That was not a workaround, I was simply describing the method I > used to check if selinux policy was responsible as requested by Jaroslav. I > put the method in the post in case anyone else wanted to try the same in > future. I know that but I failed to express exactly what I meant. Thanks for the clarification.
dracut --regenerate-all --force solve this problem for me.
(In reply to Doaxan from comment #16) > dracut --regenerate-all --force > solve this problem for me. This too worked for me. Maybe this helps point to the bug.
Thanks for confirming my original suspicion that this is dracut is related or Dracula as my tablet wants to call it. They have their similarities...
FWIW and on F24, not F25 here: Had the same issue; I upgraded to latest pptp package out of upgrades-testing, forced initrd rebuild (by dnf --reinstall of the kernel - overkill, I know) and this went away.
Installed kernel 4.8.11-300.fc25.x86_64 (which appears to be working well) from updates-testing along with the latest build of pptp. problem resolved here as a result of that. Thanks for sharing those commands though as they may come in handy in the future.
Here is my input for the kernel: 4.8.14-300.fc25.x86_64, for the selinux policy: selinux-policy-3.13.1-225.3.fc25.noarch [intel@localhost ~]$ uname -r 4.8.14-300.fc25.x86_64 [intel@localhost ~]$ rpm -qa | grep selinux-policy selinux-policy-3.13.1-225.3.fc25.noarch selinux-policy-targeted-3.13.1-225.3.fc25.noarch [intel@localhost ~]$ systemctl status systemd-modules-load ● systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disable Active: failed (Result: exit-code) since Mon 2016-12-19 06:50:02 CET; 4h 51min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 601 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 601 (code=exited, status=1/FAILURE) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. [intel@localhost ~]$ echo $? 3 [intel@localhost ~]$ Problem not solved! Thank you, _nobody_
Hi All! After trying to install amdpgu-pro driver , the installation failed because there was not support for amd R7x card. after that when updating kernel there was error dracut-install: Failed to find module 'amdgpuamdgpuamdgpu' after reading this topic I suggest to look in /etc/dracut.conf.d/ and found 3 files created on every kernel update amdgpu-pro-4.8.11-300.fc25.x86_64.conf amdgpu-pro-4.8.12-300.fc25.x86_64.conf amdgpu-pro-4.8.13-300.fc25.x86_64.conf Removing these files and rebuilding dracut, the problem was fixed!
So this is mostly a cosmetic issue. I don't know if it is worth fixing, since rebuilding the dracut image fixes it, so it will be fixed "automagically" when the kernel is upgraded.
what is the contents of amdgpu-pro-4.8.12-300.fc25.x86_64.conf and to which rpm does it belong?
(In reply to Harald Hoyer from comment #24) > what is the contents of amdgpu-pro-4.8.12-300.fc25.x86_64.conf and to which > rpm does it belong? I dont remember all message, but there was some about firmware radeon and error message on load was: Failed to load firmware "radeon/OLAND_pfp.bin" after that vga was not worked correctly until I dont make commands in /etc/rc.d/rc.local modprobe -r radeon modprobe radeon
Well, if you installed a custom kernel driver, you have to regenerate the initramfs. And if this custom install adds *.conf files for dracut in the wrong format, this custom install script/rpm should be fixed instead.
> Harald Hoyer 2017-01-30 05:00:03 EST > > And if this custom install adds *.conf files for dracut in the wrong > format, this custom install script/rpm should be fixed instead. Hello Harald, The same problem persists in F26 (rawhide). CLI transcript follows as reply to your latest message! :-( [root@localhost ~]# dracut --regenerate-all --force [root@localhost ~]# cd /boot/ [root@localhost boot]# cd d81b98af83e44563a3d3287a82b0a33c/ [root@localhost d81b98af83e44563a3d3287a82b0a33c]# ls -al total 16 drwxr-xr-x. 4 root root 4096 Jan 30 13:39 . dr-xr-xr-x. 8 root root 4096 Jan 26 09:44 .. drwxr-xr-x. 2 root root 4096 Jan 30 13:16 4.10.0-0.rc4.git2.1.fc26.x86_64 drwxr-xr-x. 2 root root 4096 Jan 30 13:16 4.10.0-0.rc5.git1.1.fc26.x86_64 [root@localhost d81b98af83e44563a3d3287a82b0a33c]# cd 4.10.0-0.rc5.git1.1.fc26.x86_64 [root@localhost 4.10.0-0.rc5.git1.1.fc26.x86_64]# ls -al total 19968 drwxr-xr-x. 2 root root 4096 Jan 30 13:16 . drwxr-xr-x. 4 root root 4096 Jan 30 13:39 .. -rw-------. 1 root root 20435499 Jan 30 13:16 initrd [root@localhost 4.10.0-0.rc5.git1.1.fc26.x86_64]# reboot --- [REBOOT] ---> [user@localhost ~]$ cd /etc [user@localhost etc]$ cat dracut.conf # PUT YOUR CONFIG IN separate files # in /etc/dracut.conf.d named "<name>.conf" # SEE man dracut.conf(5) for options [user@localhost etc]$ cd dracut.conf.d [user@localhost dracut.conf.d]$ ls -al total 16 drwxr-xr-x. 2 root root 4096 Dec 8 18:02 . drwxr-xr-x. 162 root root 12288 Jan 30 12:52 .. [user@localhost dracut.conf.d]$ [user@localhost dracut.conf.d]$ systemctl status systemd-modules-load ● systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2017-01-30 12:52:04 CET; 5min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 600 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 600 (code=exited, status=1/FAILURE) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. [user@localhost dracut.conf.d]$ uname -r 4.10.0-0.rc5.git1.1.fc26.x86_64 [user@localhost dracut.conf.d]$ dnf list installed | grep selinux-policy Last metadata expiration check: 4 days, 3:46:01 ago on Thu Jan 26 09:22:48 2017 CET. selinux-policy.noarch 3.13.1-235.fc26 @rawhide selinux-policy-targeted.noarch 3.13.1-235.fc26 @rawhide [user@localhost dracut.conf.d]$ Could you, please, elaborate more: what should be in /etc/dracut.conf? Any additional advise? Thank you, _nobody_
Fedora 25 on bare metal (on host, since I changed the SDDs in my notebook): [user@localhost ~]$ uname -r 4.9.6-200.fc25.x86_64 [user@localhost ~]$ systemctl status systemd-modules-load.service ● systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled) Active: active (exited) since Tue 2017-01-31 14:53:54 CET; 16min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 591 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Main PID: 591 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) CGroup: /system.slice/systemd-modules-load.service Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. [user@localhost ~]$ echo $? 0 [user@localhost ~]$ dnf list installed | grep selinux-policy selinux-policy.noarch 3.13.1-225.6.fc25 @updates selinux-policy-targeted.noarch 3.13.1-225.6.fc25 @updates [user@localhost ~]$ Still, at the very beginning problems: Failed to load modules during boot _nobody_
(In reply to niemand from comment #27) > > Harald Hoyer 2017-01-30 05:00:03 EST > > > > And if this custom install adds *.conf files for dracut in the wrong > > format, this custom install script/rpm should be fixed instead. > Could you, please, elaborate more: what should be in /etc/dracut.conf? $ for i in /usr/lib/dracut/dracut.conf.d/*.conf /etc/dracut.conf.d/*.conf; do rpm -qf "$i" | sed -e 's#^#'"${i}"': #';done /usr/lib/dracut/dracut.conf.d/01-dist.conf: dracut-044-178.fc27.x86_64 /usr/lib/dracut/dracut.conf.d/02-rescue.conf: dracut-config-rescue-044-178.fc27.x86_64 /usr/lib/dracut/dracut.conf.d/50-nss-softokn.conf: nss-softokn-freebl-3.30.0-2.fc27.x86_64 /usr/lib/dracut/dracut.conf.d/50-nss-softokn.conf: nss-softokn-freebl-3.30.0-2.fc27.i686 /etc/dracut.conf.d/my.conf: file /etc/dracut.conf.d/my.conf is not owned by any package
I have the following there: [user@localhost memmap]$ for i in /usr/lib/dracut/dracut.conf.d/*.conf /etc/dracut.conf.d/*.conf; do echo "$i"; rpm -qf "$i";done/usr/lib/dracut/dracut.conf.d/01-dist.conf dracut-044-181.fc26.x86_64 /usr/lib/dracut/dracut.conf.d/02-rescue.conf dracut-config-rescue-044-181.fc26.x86_64 /usr/lib/dracut/dracut.conf.d/50-nss-softokn.conf nss-softokn-freebl-3.30.2-1.0.fc26.x86_64 /etc/dracut.conf.d/*.conf error: file /etc/dracut.conf.d/*.conf: No such file or directory [user@localhost memmap]$ for i in /usr/lib/dracut/dracut.conf.d/*.conf /etc/dracut.conf.d/*.conf; do rpm -qf "$i" | sed -e 's#^#'"${i}"': #';done /usr/lib/dracut/dracut.conf.d/01-dist.conf: dracut-044-181.fc26.x86_64 /usr/lib/dracut/dracut.conf.d/02-rescue.conf: dracut-config-rescue-044-181.fc26.x86_64 /usr/lib/dracut/dracut.conf.d/50-nss-softokn.conf: nss-softokn-freebl-3.30.2-1.0.fc26.x86_64 error: file /etc/dracut.conf.d/*.conf: No such file or directory [user@localhost memmap]$ I guess, I have correct files... _nobody_
I have a similar problem with a deleted kernel module that the system persist to try to load on boot, even after an upgrade. That was because the module load was baked in the initramfs image. To fix it rebuild the initramfs. # dracut -f /boot/initramfs-4.12.11-300.fc26.x86_64.img 4.12.11-300.fc26.x86_64 Of course you have to change the kernel release version to your current version. To check your current version: $ uname -r
> # dracut -f /boot/initramfs-4.12.11-300.fc26.x86_64.img 4.12.11-300.fc26.x86_64 Better to use the following command: # dracut -f /boot/initramfs-$(uname -r).img `uname -r` This is generic one, leaves everyone without the guessing troubles/doubts. > That was because the module load was baked in the initramfs image. To fix it rebuild the > initramfs. Does Fedora have the rule in place, while introducing the new kernel, the kernel script should make also associated initramfs (from scratch), doesn't it??? _nobody_
(In reply to niemand from comment #32) niemand is right, this is much clear and better. # dracut -f /boot/initramfs-$(uname -r).img $(uname -r) > Does Fedora have the rule in place, while introducing the new kernel, the > kernel script should make also associated initramfs (from scratch), doesn't > it??? I do not know why, but I have to continue doing this with every kernel update, because the error reappears. It seems like the system doesn't make the initramfs from scratch on a kernel update. There are no more traditional init scripts on /etc/init.d/, they have been replaced by native systemd services files. Maybe there is a deprecated configuration on a systemd service.
I decided to verify your theory, Franco. I recall that today I upgraded my Fedora 26 bare metal, and upon upgrade (upgrade script created it, I guess), the new initramfs was created. It was @ 13:34 today: -rw-------. 1 root root 24660143 Sep 24 13:34 initramfs-4.12.13-300.fc26.x86_64.img I did after the following: [root@localhost boot]# cp initramfs-4.12.13-300.fc26.x86_64.img initramfs-4.12.13-300.fc26.x86_64.img.genesis [root@localhost boot]# ls -al total 281656 ... -rw-------. 1 root root 24660143 Sep 24 13:34 initramfs-4.12.13-300.fc26.x86_64.img -rw-------. 1 root root 24660143 Sep 24 19:43 initramfs-4.12.13-300.fc26.x86_64.img.genesis ... [root@localhost boot]# dracut -f /boot/initramfs-$(uname -r).img $(uname -r) [root@localhost boot]# ls -al total 281836 ... -rw-------. 1 root root 24843565 Sep 24 19:44 initramfs-4.12.13-300.fc26.x86_64.img -rw-------. 1 root root 24660143 Sep 24 19:43 initramfs-4.12.13-300.fc26.x86_64.img.genesis ... [root@localhost boot]# diff -c initramfs-4.12.13-300.fc26.x86_64.img.genesis initramfs-4.12.13-300.fc26.x86_64.img Binary files initramfs-4.12.13-300.fc26.x86_64.img.genesis and initramfs-4.12.13-300.fc26.x86_64.img differ [root@localhost boot]# Boooomer! Upgrading script (size 24660143) and dracut (size 24843565) after all created different initramfs-4.12.13-300.fc26.x86_64.img (but should create The SAME, and the same size)??? Things to look upon, don't you agree, dracut-maint-list?! _nobody_
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.