http://bugzilla.opensuse.org/show_bug.cgi?id=1137064 http://bugzilla.opensuse.org/show_bug.cgi?id=1137064#c1 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jreidinger@suse.com, | |loiblp@gmx.de, | |mchang@suse.com Flags| |needinfo?(loiblp@gmx.de) --- Comment #1 from Jiri Srain --- Well, it clearly is a bug that /etc/default/grub contains that many copies of the same append. Could you, please, attach the logs from upgrade (assuming that you upgraded from 15.0 to 15.1 with YaST, meaning booting the installation media)? https://en.opensuse.org/openSUSE:Report_a_YaST_bug The log should show how/when the command-line became broken. About GRUB2 behavior if the cmdline is that long: I added Michael to CC, maybe he has can comment on the limits. However, it is not the root cause of the problem. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137064 http://bugzilla.opensuse.org/show_bug.cgi?id=1137064#c3 --- Comment #3 from Josef Reidinger --- Hi Peter, let me explain how it works newly in 15.1. During upgrade we read original configuration, allow user to change it ( due to new cpu mitigation option ) and then write it. Issue is that it is written after upgrade. And we do want to lose any modifications done by rpm post install scripts, so for safety we simply append kernel command line ( other options are just rewritten ). And if you see, in 15.0 you already have quite big append line ( do not see from logs why ) and it is duplicated, which result in this issue. We definitively need to find way how to reasonable merge duplications. Like keep only the last occurence of parameter? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137064 http://bugzilla.opensuse.org/show_bug.cgi?id=1137064#c5 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mchang@suse.com) --- Comment #5 from Josef Reidinger --- (In reply to Peter Loibl from comment #4)

Hi Josef, thanks for clarifying. I just want to stress out three points:

1. I never edited /etc/defaults/grub, so there must have been some uderlying bug in the past ... but this is not the issue here

2. I am having some 25 years development experience in an area where software bugs are not really acceptable. So, my quality expectations might be on the upper end. But your bug caused me to search for several hours for a solution ... Appending parameters to an existing configuration without checking what is already there never has been a good implementation decision (what about conflicting paramter?)

kernel does not have conflicting params beside "noresume" which is handled now. Others should be simple overwritten, like if there is "quite verbose quite" then the last one wins. But I agree we need to address this issue and solution should be to remove duplicite params. ( so if there is e.g. "quite verbose quite" reduce it to "verbose quite" where we keep always just last param )

3. Why does grub just die and is not eving giving a timeout? Sounds pretty much like a good buffer overflow! Anyone looking for a nice scenario for a not so easy to find code injection attack vector? (Exactly that is the reason why I set the severity to major)

Question for michal. Can you comment grub behavior here? Or maybe it does not die and simply kernel die when it gets those params? -- You are receiving this mail because: You are on the CC list for the bug.