|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2-kdump: Does not add crashkernel parameters to grub2 bootloader configuration | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.3 | Reporter: | Jeff Mahoney <jeffm> |
| Component: | YaST2 | Assignee: | Steffen Winterfeldt <snwint> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | arvidjaar, fcrozat, jreidinger, mchang, mpluskal, rmilasan |
| Version: | RC 1 | Flags: | coolo:
SHIP_STOPPER-
|
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
YaST logs
YaST2 logs after enabling crashdump And screenshot of YaST2 y2logs strace yast kdump |
||
I've added Michael for grub2 to CC - I suggest to assign to yast2-kdump maintainer so that s/he talks with Michael. I think the issue is that y2bl (resp. pbl) doesn't provide a default section when reading the config, so it doesn't know where to put the kdump options. E.g.: [YCP] Kdump.ycp:881 Default boot section is [YCP] Kdump.ycp:560 i386, x86_64, ia64 and ppc64 platforms are without offset [YCP] Kdump.ycp:571 builded crashkernel value is 64M-:32M [YCP] Bootloader.ycp:418 Writing bootloader configuration [YCP] Bootloader.ycp:1069 name of default section: [YCP] Bootloader.ycp:512 Saving configuration files Michael, could you check? Steffen, Jeff In my testing the default boot section was provided but it fails in writing bootloader config to specific section's kernel append, which is no feasible settings in current grub2's config (/etc/default/grub). We could try to direct crashkernel parameters writing to global's append rather than section's append for grub2's case. This would result in sub-optimal result as crashkernel parameters be in other kernel entries, but to be honest I didn't know we have other choice as writing grub.cfg is prohibited. And still not know why default section is missing in your testing. :( I'm almost done. The pbl will now read grub.cfg and extract each section's information in order to export to yast. Yast utilities now should not be fail due to lack of these information. And when it attempts to modify, for example the kernel's parameter, pbl will direct it's writing to the corresponding global option. This is, IMHO, our best effort to fit to the logic of grub2 config. I tested yast2 dump worked with above changes, and only pbl was modified. I'll try to provide the testing packages. Hi Jeff, Could you test the package here? http://download.opensuse.org/repositories/home:/michael-chang:/bnc766456/openSUSE_Factory/ If the test is positive I'll try submit to Steffen for review. Thanks. I can see this issue on 12.3RC1 *** Bug 772928 has been marked as a duplicate of this bug. *** Michael, could you repost the repository to test, it is no longer available. Still valid with 12.3 RC1 That patch has been included in 12.3 RC1 so there must be other reason it fails. Weird. Works for me on 12.3 RC1 fresh installation. $ zypper in yast2-kdump $ yast2 kdump Check "Enable Kdump" and press "OK" to quit. $ grep crashkernel ... crashkernel=256M-:128M $ yast2 kdump Check "Disable Kdump" and press "OK" to quit. $ grep crashkernel -- nothing output -- I missed the chance to verify the very first time enabling kdump, so above are results based on second and third time, I'm not sure that mattered or not. Just removed and re-installed packages trying to catch the very first time chance of enabling it. It works for me as well. :-/ Hi Martin, Would you please help to provide more elaborate procedure on how to reproduce? Thanks. I tested with 12.3 RC1 and crashkernel wasn't added to grub2 configuration at any time. For me it worked, but everything I start yast2-kdump, even when kdump is enable, it will always show disabled. Sorry, every time I start yast2-kdump, I meant to say. (In reply to comment #15) > For me it worked, but everything I start yast2-kdump, even when kdump is > enable, it will always show disabled. I see the same problem but I thought that was yast2 kdump's not bootloader. If you reboot it actually works if you manually trigger a crash. At least should be another bug report. (In reply to comment #14) > I tested with 12.3 RC1 and crashkernel wasn't added to grub2 configuration at > any time. Strange. I have no idea right now. :( Created attachment 525465 [details]
YaST2 logs after enabling crashdump
Just tried it on 12.3 with minimal text install.
zypper dup
zypper in yast2-kdump
yast2 - tried to enable kdump and confirm. Got "Adding crashkernel parameter to bootloader fault." (BTW this does not sound like correct English to me). y2logs attached.
Created attachment 525466 [details]
And screenshot of YaST2
When I observed this issue, it occurred on UEFI machine, which contains as far as I remember grub grub2 and grub2-efi in /boot directory, could this be related to issue? This one is UEFI too. I'm testing on non-UEFI hardware (but grub2-efi might be installed, due to me working on Secure Boot) I tested it in non-UEFI VM after removing grub2-efi (which is automatically installed even on legacy BIOS systems) and still have the same problem. Created attachment 525521 [details]
y2logs
The reason it fails to add crashkernel parameter is apparently it fails to find default section: 2013-02-20 19:31:07 <1> linux-o0ic.site(12926) [YCP] Kdump.ycp:347 Command: /bin/chmod 644 /etc/sysconfig/kdump finish successful. 2013-02-20 19:31:07 <1> linux-o0ic.site(12926) [YCP] Kdump.ycp:881 Default boot section is And if I go to bootloader configuration in YaST2 default section is indeed empty. In /etc/default/grub GRUB_DEFAULT=saved. I did not change it, so I assume it is put there by installer/YaSt2. But I do not have any saved section in grub2 environment (grub2-editenv list) which probably explains why it fails. Why saved section is empty is likely outside of scope of this bug, but at the very least YaST2 function that computes default bootloader section should fallback to 0 which is what grub2 does in this case. Created attachment 525522 [details]
strace yast kdump
Not sure if it contains any useful information ...
Steps to reproduce (on UEFI x86_64 machine) 1) Start yast2 kdump 2) Click checkbox "enable kdump" 3) Ok, save I see popup that says "you need to reboot ...", after I click ok, another popup says "Adding crashkernel parameter to bootloader fault" see also attachments (y2logs and strace). Go to System - Bootloader, select default entry, save. After that System - Kdump works, but even after reboot when I start it I *still* have "Disable" checked. So there are two problems 1. enabling kdump fails if default boot menu entry is not defined. It should in this case default to the very first entry which is what grub2 does 2. It is not clear what check boxes in Kdump YaST2 module mean. If "Disable"/"Enable" means "disable/enable kdump as result of this invocation", then current behavior correct but it is very confusing. It is better when checkboxes reflect actual enabled/disbaled status. (In reply to comment #29) > 1. enabling kdump fails if default boot menu entry is not defined. It should in > this case default to the very first entry which is what grub2 does > Fixed with https://github.com/openSUSE/perl-bootloader/pull/14 You can test updated perl-Bootloader in home:arvidjaar:bnc:773143/standard Thanks all helping this. That explained why I can't reproduce as in my settings I have default entry set. :) Hi Martin, Please help to test Andrey's fix in comment#30 ? Thanks. Notice that this patch will have side effects. It makes YaST2 bootloader module to think there is explicit default entry set - while it is not. So the following is possible - user starts YaST2 bootloader, sees "Some entry title" which happens to be the first one and thinks it is OK. yast2-bootloader does *not* update grub2 (i.e. does not write saved_entry) because it believes nothing was changed (is it true?) - after that grub2-mkconfig is run which now changes boot entries order so "Some entry title" is no more the first one - now the effective default is no more "Some entry title" but whatever happens to become the first menu entry after grub2-mkconfig Also if user changes GRUB_DEFAULT from "saved" to explicit menu entry this is going to be totally off mark. But adding notion of "not explicitly set, but bootloader default" menu entry to YaST2 is definitely beyond my abilities. (In reply to comment #29) > 2. It is not clear what check boxes in Kdump YaST2 module mean. If > "Disable"/"Enable" means "disable/enable kdump as result of this invocation", > then current behavior correct but it is very confusing. It is better when > checkboxes reflect actual enabled/disbaled status. It has been that way from my memory, but I could be wrong. (In reply to comment #33) > Notice that this patch will have side effects. It makes YaST2 bootloader module > to think there is explicit default entry set - while it is not. So the > following is possible > > - user starts YaST2 bootloader, sees "Some entry title" which happens to be the > first one and thinks it is OK. yast2-bootloader does *not* update grub2 (i.e. > does not write saved_entry) because it believes nothing was changed (is it > true?) If you haven't touched SetSettings() I think it's the reason why changes not be saved eventually. > > - after that grub2-mkconfig is run which now changes boot entries order so > "Some entry title" is no more the first one This seems to me a generic problem if we set an explicit entry. If we set it to, say "Advanced options for .... > openSUSE 12.2 with Linux 3.4.6-2.10-desktop" And received an kernel updates to different version ... would grub2-mkconfig handle that by updating the saved_entry as well as the config ? > > - now the effective default is no more "Some entry title" but whatever happens > to become the first menu entry after grub2-mkconfig But I suppose your patch will show the new default .. right ? If yes this is not a big problem to me. :) > > Also if user changes GRUB_DEFAULT from "saved" to explicit menu entry this is > going to be totally off mark. I doubt any better people want to do that? It blows out things like grub2-reboot which used in hibernation (and other circumstance). PBL need to improve to support that, but not urgent to me. > > But adding notion of "not explicitly set, but bootloader default" menu entry to > YaST2 is definitely beyond my abilities. Ok. This change involves ybl .. But I would treat it as enhancement and this bug can be cured with your patch (ie I dont think the side effects is really that hurt to us. :) thanks. (In reply to comment #35) > If you haven't touched SetSettings() I think it's the reason why changes not be > saved eventually. > No I did not. I only made it return "0" if saved_entry is missing in grubenv. > > > > - after that grub2-mkconfig is run which now changes boot entries order so > > "Some entry title" is no more the first one > > This seems to me a generic problem if we set an explicit entry. If we set it > to, say "Advanced options for .... > openSUSE 12.2 with Linux > 3.4.6-2.10-desktop" And received an kernel updates to different version ... > would grub2-mkconfig handle that by updating the saved_entry as well as the > config ? > Yes if it is using titles or (better) menuentry ids. No if it using numbers. As far as I see, it is using titles today (I did not check whether it builds correct entry for submenus though). > > > > - now the effective default is no more "Some entry title" but whatever happens > > to become the first menu entry after grub2-mkconfig > > But I suppose your patch will show the new default .. right ? If yes this is > not a big problem to me. :) > Sure, yast2-bootloader will display the (new) first entry next time it is called. > > > > Also if user changes GRUB_DEFAULT from "saved" to explicit menu entry this is > > going to be totally off mark. > > I doubt any better people want to do that? It blows out things like > grub2-reboot which used in hibernation (and other circumstance). > This is offtopic, but I still do not understand why grub-once depends on saved menu entry. I actually sent patch to upstream for discussion which is using separate grubenv variable for this. Zero response so far :) (In reply to comment #30) > (In reply to comment #29) > > 1. enabling kdump fails if default boot menu entry is not defined. It should in > > this case default to the very first entry which is what grub2 does > > > > Fixed with https://github.com/openSUSE/perl-bootloader/pull/14 > > You can test updated perl-Bootloader in home:arvidjaar:bnc:773143/standard I would love to try it, but I don't see anything in your home repository, did you set publish flag on? (In reply to comment #37) > I would love to try it, but I don't see anything in your home repository, did > you set publish flag on? Yes. I actually installed from it yesterday so I know it works. zypper ar obs://home:arvidjaar:bnc:774143/standard bnc773143 zypper refresh bnc773143 zypper dup -r bnc773143 (In reply to comment #38) > zypper ar obs://home:arvidjaar:bnc:774143/standard ^ Oops, 773143 of course http://download.opensuse.org/repositories/home:/arvidjaar:/bnc:/773143/standard/ Ah thanks, I was looking at build.suse.de (In reply to comment #39) > (In reply to comment #38) > > > zypper ar obs://home:arvidjaar:bnc:774143/standard > ^ Oops, 773143 of course > > http://download.opensuse.org/repositories/home:/arvidjaar:/bnc:/773143/standard/ I mean build.opensuse.org (In reply to comment #40) > Ah thanks, I was looking at build.suse.de > (In reply to comment #39) > > (In reply to comment #38) > > > > > zypper ar obs://home:arvidjaar:bnc:774143/standard > > ^ Oops, 773143 of course > > > > http://download.opensuse.org/repositories/home:/arvidjaar:/bnc:/773143/standard/ Will try as soon as possible BTW, as we are on the subject, setting elevator (or I/O scheduler) in 12.2 and 12.3 doesn't work, but not sure who suppose to be responsible for it. Does anybody know who is responsible for yast2 system-settings? (In reply to comment #42) > BTW, as we are on the subject, setting elevator (or I/O scheduler) in 12.2 and > 12.3 doesn't work, but not sure who suppose to be responsible for it. > It is yast2-tune. Same reason, set default menu entry in yast2-bootloader and it will magically work. Works for me We reworked whole bootloader parameter settings now, so it should work reliable, as it do not depends on finding default section. Closing. If it still happen on Leap or TW, please reopen with fresh logs. |
Created attachment 500021 [details] YaST logs yast2-kdump doesn't add the crashkernel parameters to the grub2 bootloader configuration. Since crashkernel isn't setup, there's no place to load the kexec kernel and initramfs, so kdump can't be used. Since I added the ability to only capture an Oops using kdump, this is a pretty big problem for triaging kernel bugs.