Description of problem: Fedora 18 introduces new macros - %systemd_post, %systemd_preun and %systemd_postun; With these macros, kdump service need to be covered by the default Fedora preset policy. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: After kexec-tools installation, kdump.service is not enabled automatically. Expected results: After kexec-tools installation, kdump.service is enabled automatically. Additional info:
Hmm, that doesn't sound right to me. That way every install of "kexec-tools" will get kdump enabled. I am pretty sure more people use kexec than kdump, so what's the reason of enabling this by default? If this really should be enabled by default, could you at least split the kdump parts out of kexec-tools so that people who just want kexec do not have to also use kdump?
Yeah, fedora may focus on desktop/personal users, it's true more people use kexec than kdump. However, for enterprise users kdump means more than kexec. As you know kdump is based on kexec, even though enabled by default kexec still can be used. kdump only works when exceptions happen. Anyway, it's fine if systemd component refuses to make kdump enabled by default after kexec-tools installation, maybe we can add it to enterprise version alone. Baoquan Thanks
(In reply to Baoquan He from comment #2) > Anyway, it's fine if systemd component refuses to make kdump enabled by > default after kexec-tools installation, maybe we can add it to enterprise > version alone. > > Baoquan > Thanks Yes, we should add that to the RHEL presets and not Fedora.
(In reply to Lennart Poettering from comment #1) > Hmm, that doesn't sound right to me. That way every install of "kexec-tools" > will get kdump enabled. I am pretty sure more people use kexec than kdump, > so what's the reason of enabling this by default? > > If this really should be enabled by default, could you at least split the > kdump parts out of kexec-tools so that people who just want kexec do not > have to also use kdump? This service only loads kdump parts. Does not take care of usual kexec parts. Users must be loading kexec kernel with right options using command line. But agreed that for general case of fedora, enabling kdump by default might not be very useful. That's the reason we don't reserve memory for second kernel by default in fedora. So I am fine with keeping kdump service disabled by default in fedora. But we need to enable it by default in rhel. So we might have to carry a patch in rhel tree.
(In reply to Vivek Goyal from comment #4) > (In reply to Lennart Poettering from comment #1) > > Hmm, that doesn't sound right to me. That way every install of "kexec-tools" > > will get kdump enabled. I am pretty sure more people use kexec than kdump, > > so what's the reason of enabling this by default? > > > > If this really should be enabled by default, could you at least split the > > kdump parts out of kexec-tools so that people who just want kexec do not > > have to also use kdump? > > This service only loads kdump parts. Does not take care of usual kexec > parts. Users must be loading kexec kernel with right options using command > line. > > But agreed that for general case of fedora, enabling kdump by default might > not be very useful. That's the reason we don't reserve memory for second > kernel by default in fedora. > > So I am fine with keeping kdump service disabled by default in fedora. But > we need to enable it by default in rhel. So we might have to carry a patch > in rhel tree. I would guess, RHEL will have a preset file shipped in a different package than systemd. Either a specialized rpm by RHEL product or redhat-release...
See also bug 903690
Hmm, I'd still prefer if even on RHEL we could offer kexec easily without implying kdump. But anyway, that's probably something to discuss elsewhere. For now I assume that adding this to the default preset policy is not necessary anymore, as by comment #4? I can close this bug hence?
(In reply to Lennart Poettering from comment #7) > Hmm, I'd still prefer if even on RHEL we could offer kexec easily without > implying kdump. One can create a new service "kexec" to offer kexec functionality in an easy way. Nobody has asked for it so far. But I can see it can be useful if one is using kexec frequently. > > But anyway, that's probably something to discuss elsewhere. > > For now I assume that adding this to the default preset policy is not > necessary anymore, as by comment #4? I can close this bug hence? Yes, that's fine. For fedora, it is fine that kdump service is not enabled by default.
(In reply to Vivek Goyal from comment #8) > (In reply to Lennart Poettering from comment #7) > > Hmm, I'd still prefer if even on RHEL we could offer kexec easily without > > implying kdump. > > One can create a new service "kexec" to offer kexec functionality in an easy > way. Nobody has asked for it so far. But I can see it can be useful if one > is using kexec frequently. Not following here. A new "service" kexec? What would that do? Note that systemd supports rebooting via kexec out-of-the-box. If kexec-tools is installed you can just do "systemctl kexec" and that's it. This functionality is highly useful, and I'd like to make this available on RHEL too, without also having to enabled kdump by default.
(In reply to Lennart Poettering from comment #9) > (In reply to Vivek Goyal from comment #8) > > (In reply to Lennart Poettering from comment #7) > > > Hmm, I'd still prefer if even on RHEL we could offer kexec easily without > > > implying kdump. > > > > One can create a new service "kexec" to offer kexec functionality in an easy > > way. Nobody has asked for it so far. But I can see it can be useful if one > > is using kexec frequently. > > Not following here. A new "service" kexec? What would that do? > > Note that systemd supports rebooting via kexec out-of-the-box. If > kexec-tools is installed you can just do "systemctl kexec" and that's it. > This functionality is highly useful, and I'd like to make this available on > RHEL too, without also having to enabled kdump by default. Hm.., I did not know that we have "systemctl kexec" command too. I will play with it. I was thinking that kexec service will just keep a kexec kernel loaded so that when somebody reboots, it uses that kernel. Thining more abou tit, keeping a kernel pre-loaded with the help of a service is not making much sense. It is unnecessarily eating system ram. What will help though that allows selecting a kernel from grub.cfg (using index) and associated kernel, initramfs and command line options are automatically retrieved and passed to "kexec -l" so user does not have to type that manually. Well, let me first play with "systemctl kexec".
I tried "systemctl kexec" and it fails. I see following messages. Nothing has been loaded! [ 201.105325] dracut Warning: kexec failed! dracut Warning: kexec failed! What systemctl kexec is supposed to do? Does it load currently running kernel automatically? On same machine I did following and that worked. #kexec -l /boot/vmlinuz-3.9.2-301.fc19.x86_64 --initrd=/boot/initramfs-3.9.2-301.fc19.x86_64.img --append="BOOT_IMAGE=/vmlinuz-3.9.5-301.fc19.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root console=tty0 console=ttyS0,115200 crashkernel=128M LANG=en_US.UTF-8" #reboot
Also what's the difference between calling "systemctl reboot" and "reboot".
No "systemctl kexec" will expect that you already loaded a kernel. It might make sense to have a service in place which does that during shutdown or so, to make this just work. The difference between "systemctl reboot" and "reboot" is pretty much that the former is the systemd command, and the latter as the traditional sysv command which we also support.
(In reply to Lennart Poettering from comment #13) > No "systemctl kexec" will expect that you already loaded a kernel. It might > make sense to have a service in place which does that during shutdown or so, > to make this just work. So what's the difference between "systemctl reboot" and "systemctl kexec". How about merging these together and "systemctl reboot" will do kexec reboot if a kexec kernel is loaded. (like sysv reboot command) otherwise will continue with bios reboot.
Well, with the current separation we could allow kexec to drop in a service that gets run *only* on kexec reboots and quickly loads the kernel before booting into it.
I guess "systemctl reboot" could do the same thing. Launch kexec service on shutdown. This service will load a kernel if configured (service will a configuration file somehere, say /etc/kexec.conf). After service exits, reboot can check if kexec kernel was loaded. If yes, it continues to do kexec reboot otherwise regular reboot.
kernel exports through sys whether kexec kernel is loaded or not. (/sys/kernel/kexec_loaded).
(In reply to Vivek Goyal from comment #16) > This service will load a kernel if configured (service will a > configuration file somehere, say /etc/kexec.conf). I'm pretty sure that we want this to work without any manual configuration by default, loading the "default" kernel, with "default" commandline ("default" probably means latest in case of kernel, and current in case of commandline). If this is hooked into systemctl reboot, we should also grow a way to disable kexec (possibly adding a new setting to /etc/systemd/sleep.conf). > Well, with the current separation we could allow kexec to drop in a service that gets run *only* on kexec reboots and quickly loads the kernel before booting into it. That would be nice.
Close this bug, as we are ok without preset kdump in Fedora. If you feel it's still a problem please reopen it.