Description of problem: https://fedoraproject.org/wiki/Features/SysVtoSystemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
is it possible to split kexec and kdump?
Note that you need to package the old sysv init script separately or drop it as stated but the packaging guidelines. "SysV Initscripts Packages may also provide a SysV initscript file, but are not required to do so. This format is considered legacy, but Fedora still contains init mechanisms such as upstart which do not support the systemd unit file format. If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here: Packaging:SysVInitScript" https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd http://fedoraproject.org/wiki/Packaging:Tmpfiles.d Currently there's about 60/40 drop/keep ratio...
Hence hacks like these dont cut it... [Unit] Description=Crash recovery kernel arming After=network.target [Service] Type=oneshot ExecStart=/etc/init.d/kdump start <--- wtf ;) RemainAfterExit=yes
I've flagged Kexec as done on https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd and you can close this as FIXED to get it off the alpha blocker bug Thanks for quick responces.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Could you please close this bug now that you have shipped a native systemd unit file so it goes of the bug trackers radar Any addtional changes can be submitted via update.. Thanks.
kexec-tools-2.0.2-29.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kexec-tools-2.0.2-29.fc16
Package kexec-tools-2.0.2-29.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kexec-tools-2.0.2-29.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/kexec-tools-2.0.2-29.fc16 then log in and leave karma (feedback).
kexec-tools-2.0.2-29.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
How is automatic kdump-start-at-boot supposed to work with these unit files? # systemctl enable kdump.service Warning: unit files do not carry install information. No operation executed.
If that happens the unit is missing an install section as in... [Install] WantedBy=multi-user.target Just note that in some cases this can be intentionally left out just add the above is that is not the case.
s/is that/if that/
(In reply to comment #11) > If that happens the unit is missing an install section as in... > > [Install] > WantedBy=multi-user.target > > Just note that in some cases this can be intentionally left out just add the > above is that is not the case. Hello Johann With this WantedBy line kdump service still fails start-at-boot, because it depends on /boot/ mounted, I tried add local-fs.target to Wants seems it does not help. Do you have idea about this?
The WantedBy line in the [Install] section of the unit is only relevant to which boot target you want the service to be enable in. You order startup ordering of units with After= or Before=. So the After= line should go from this "After=network.target" to this.., "After=local-fs.target network.target" To be order after local mount points and this... After=local-fs.target remote-fs.target network.target" if for some reason /boot is an remote filesystem. Try changing that and see if that fixes your problem Now you might also want to add condition checks in the [Unit] section of the the unit as in.. ConditionPathExists=/boot If the above condition is not met as in /boot does not exist the unit will fail ConditionKernelCommandLine=crashkernel If crashkernel is not set on the kernel command line the unit will fail Probably with this option you could request exception from fesco to enable the service by default. Putting this altogether you can test this unit file... [Unit] Description=Crash recovery kernel arming ConditionPathExists=/boot ConditionKernelCommandLine=crashkernel After=local-fs.target remote-fs.target network.target [Service] Type=oneshot ExecStart=/usr/bin/kdumpctl start ExecStop=/usr/bin/kdumpctl stop RemainAfterExit=yes [Install] WantedBy=multi-user.target
Johann, Thanks It still fails with your service content,I found my tested version is Fedora 17 beta, I tried F17 GA today the original kdump.service works just ok except a ldconfig problem of dracut: ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied E: ldconfig exited ungracefully
(In reply to comment #16) > Johann, Thanks > > It still fails with your service content,I found my tested version is Fedora > 17 beta, I tried F17 GA today the original kdump.service works just ok > except a ldconfig problem of dracut: > > ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission > denied > E: ldconfig exited ungracefully The unit I mentioned there in comment 15 will fail if. A) /boot does not exist B) crashkernel kernel parameter does not exist on the kernel command line. These "local-fs.target remote-fs.target" should not be necessary I just added that to ensure you did not hit any kind of ordering problem [Unit] Description=Crash recovery kernel arming ConditionKernelCommandLine=crashkernel After=network.target [Service] Type=oneshot ExecStart=/usr/bin/kdumpctl start ExecStop=/usr/bin/kdumpctl stop RemainAfterExit=yes [Install] WantedBy=multi-user.target I suggest you test your unit on F16 so you aren't hitting some fallout from /usr move then you know remove "ro" from the kernel command line put "enforce=0" to rule out selinux etc. stuff like that to debug those permission errors.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19