why is gurb-menu hidden as default?

[Reindl Harald]

hi

who decided that it is a good idea to hide the grub-menu?
most questions on mailing-lists and boards is "how can
i boot  a different kernel" and it makes really really tired
to see that no new user is realizing that Fedora has a boot
manager

this results a) in needless questions and b) new users does
learn nothing because they see nothing as default

[Tomasz Torcz]

On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
>  who decided that it is a good idea to hide the grub-menu? 
  It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
I believe showing GRUB2 menu is a regression which will be
fixed before F17 release.

-- 
Tomasz Torcz                 "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl         "God is more forgiving."

[Reindl Harald]

Am 06.02.2012 15:07, schrieb Tomasz Torcz:
>  On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
> > who decided that it is a good idea to hide the grub-menu?
>  
>  It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
>  I believe showing GRUB2 menu is a regression which will be
>  fixed before F17 release. 
what regression?

i speak about that GENERALLY the boot-maanger should be VISIBLE
in Feodra as also in RHEL and not hidden, to hide the option
boot with the previous kernel for everybody since years
degrades the whole OS because if a new kernel does not boot
and a new user does not know how to get the boot menu while
he is owning only this machine prevents him to boot it

on the other hand if we display the boot menu even a totally
new user would see it and have a good chance to start his machine

[Tomasz Torcz]

On Mon, Feb 06, 2012 at 03:16:40PM +0100, Reindl Harald wrote:
>  
>  
>  Am 06.02.2012 15:07, schrieb Tomasz Torcz:
>  > On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
>  >> who decided that it is a good idea to hide the grub-menu?
>  > 
>  > It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
>  > I believe showing GRUB2 menu is a regression which will be
>  > fixed before F17 release.
>  
>  what regression? 
  GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
bugs #737339 and #727831.

-- 
Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton
(LKML)

[drago01]

On Mon, Feb 6, 2012 at 3:16 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 06.02.2012 15:07, schrieb Tomasz Torcz:
> > On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
> >> who decided that it is a good idea to hide the grub-menu?
> >
> > It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
> > I believe showing GRUB2 menu is a regression which will be
> > fixed before F17 release.
>
>  what regression?
>
>  i speak about that GENERALLY the boot-maanger should be VISIBLE
>  in Feodra as also in RHEL and not hidden, to hide the option
>  boot with the previous kernel for everybody since years 
No unless you dual boot another OS the bootloader should not be
visible as the user does not have to care about it.
Other OSs also don't do that for a reason.

[Reindl Harald]

Am 06.02.2012 17:10, schrieb Tomasz Torcz:
>  On Mon, Feb 06, 2012 at 03:16:40PM +0100, Reindl Harald wrote:
> >
> >
> > Am 06.02.2012 15:07, schrieb Tomasz Torcz:
> >> On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
> >>> who decided that it is a good idea to hide the grub-menu?
> >>
> >> It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
> >> I believe showing GRUB2 menu is a regression which will be
> >> fixed before F17 release.
> >
> > what regression?
>  
>  GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
>  See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
>  bugs #737339 and #727831. 
this is a behavior that should never been changed!

[Reindl Harald]

Am 06.02.2012 17:16, schrieb drago01:
>  On Mon, Feb 6, 2012 at 3:16 PM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> >
> >
> > Am 06.02.2012 15:07, schrieb Tomasz Torcz:
> >> On Mon, Feb 06, 2012 at 02:55:38PM +0100, Reindl Harald wrote:
> >>> who decided that it is a good idea to hide the grub-menu?
> >>
> >> It was F10 feature: http://fedoraproject.org/wiki/Features/BetterStartup
> >> I believe showing GRUB2 menu is a regression which will be
> >> fixed before F17 release.
> >
> > what regression?
> >
> > i speak about that GENERALLY the boot-maanger should be VISIBLE
> > in Feodra as also in RHEL and not hidden, to hide the option
> > boot with the previous kernel for everybody since years
>  
>  No unless you dual boot another OS the bootloader should not be
>  visible as the user does not have to care about it.
>  Other OSs also don't do that for a reason. 
and why are there so many noobs with questions like "after a kernel
update my machine does no longer boot" if this decision would
be smart?

it si idiotic having a fallback after kernel updates and hide it
from the users - what do you think how many do not know this, have
no other computer to post any question because no longer inernet
access resulting in delete the whole linux-os and how many of them
never install it again after "killed with standard update"

[Bruno Wolff III]

On Mon, Feb 06, 2012 at 17:22:52 +0100,
  Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  
>  > GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
>  > See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
>  > bugs #737339 and #727831.
>  
>  this is a behavior that should never been changed! 
Some of us think so, but that battle was lost a long time ago and we really
don't need to keep rehashing it. If you are intersted you can go look for
long threads about this in the past. There was at least one, but maybe
a few.

[Reindl Harald]

Am 06.02.2012 17:25, schrieb Bruno Wolff III:
>  On Mon, Feb 06, 2012 at 17:22:52 +0100,
>    Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> >
> >> GRUB2 menu is shown in F16. This is a regression compared to F10÷15.
> >> See https://bugzilla.redhat.com/show_bug.cgi?id=757487 and linked
> >> bugs #737339 and #727831.
> >
> > this is a behavior that should never been changed!
>  
>  Some of us think so, but that battle was lost a long time ago and we really
>  don't need to keep rehashing it. If you are intersted you can go look for
>  long threads about this in the past. There was at least one, but maybe
>  a few. 
it was refreshed for me with the question below
without such idiotic changes this sort of problems
would simply not exist and people would learn to
use their OS instead obfuscate all options from
the users like windows

what does this user if he has no other computer
for his question?

-------- Original-Nachricht --------
Betreff: [CentOS] How to boot into a different kernel

CentOS Community,

Is there a command to boot into a different version of the kernel? I
believe this is setup via grub.conf but unsure. There are a few
different kernels loaded into /boot but I want to see if there is a
command to boot into a different kernel as a single instance or
permanent if needed. Please advise

[root@titanium boot]# ls -ltr
total 62768
-rw-r--r--. 1 root root  2312369 Dec  6 15:35
System.map-2.6.32-220.el6.x86_64
-rw-r--r--. 1 root root   100943 Dec  6 15:35 config-2.6.32-220.el6.x86_64
-rwxr-xr-x. 1 root root  3938288 Dec  6 15:35 vmlinuz-2.6.32-220.el6.x86_64
-rw-r--r--. 1 root root   171087 Dec  6 15:36
symvers-2.6.32-220.el6.x86_64.gz
-rw-r--r--. 1 root root  2313220 Dec 23 04:14
System.map-2.6.32-220.2.1.el6.x86_64
-rw-r--r--. 1 root root   100947 Dec 23 04:14
config-2.6.32-220.2.1.el6.x86_64
-rwxr-xr-x. 1 root root  3940752 Dec 23 04:14
vmlinuz-2.6.32-220.2.1.el6.x86_64
-rw-r--r--. 1 root root   171175 Dec 23 04:17
symvers-2.6.32-220.2.1.el6.x86_64.gz
drwx------. 2 root root    12288 Jan 18 10:36 lost+found
drwxr-xr-x. 3 root root     1024 Jan 18 10:45 efi
-rw-r--r--. 1 root root 14888469 Jan 18 10:45
initramfs-2.6.32-220.el6.x86_64.img
-rw-r--r--. 1 root root 14885287 Jan 18 11:23
initramfs-2.6.32-220.2.1.el6.x86_64.img
-rwxr-xr-x. 1 root root  3940016 Jan 23 22:02
vmlinuz-2.6.32-220.4.1.el6.x86_64
-rw-r--r--. 1 root root  2313117 Jan 23 22:02
System.map-2.6.32-220.4.1.el6.x86_64
-rw-r--r--. 1 root root   100947 Jan 23 22:02
config-2.6.32-220.4.1.el6.x86_64
-rw-r--r--. 1 root root   171175 Jan 23 22:02
symvers-2.6.32-220.4.1.el6.x86_64.gz
-rw-r--r--. 1 root root 14885301 Jan 26 08:13
initramfs-2.6.32-220.4.1.el6.x86_64.img
drwxr-xr-x. 2 root root     1024 Feb  6 01:06 grub
[root@titanium boot]#

[Rahul Sundaram]

On 02/06/2012 10:01 PM, Reindl Harald wrote:

>  
>  it was refreshed for me with the question below
>  without such idiotic changes this sort of problems
>  would simply not exist and people would learn to
>  use their OS instead obfuscate all options from
>  the users like windows
>  
>  what does this user if he has no other computer
>  for his question? 
You should ask the CentOS user that question instead of asking people
who cannot possibly know that and it is off topic here.  Let's limit
discussions to Fedora development in this list.  If you have a GRUB
specific concern, file a bug report.

Rahul

[Matthew Garrett]

On Mon, Feb 06, 2012 at 05:25:08PM +0100, Reindl Harald wrote:

>  and why are there so many noobs with questions like "after a
> kernel
>  update my machine does no longer boot" if this decision would
>  be smart? 
The solution to "My kernel update doesn't boot" should be
"Automatically 
detect that that happened, give the user that information and fall back 
to the old kernel", not "Always show the user a menu that they almost 
always don't care about". Solve the actual problem.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Michael Cronenworth]

Reindl Harald wrote:
>  it was refreshed for me with the question below
>  without such idiotic changes this sort of problems
>  would simply not exist and people would learn to
>  use their OS instead obfuscate all options from
>  the users like windows
>
>  what does this user if he has no other computer
>  for his question? 
Instead of forcing down your opinion down everyone's throats, there are 
nicer alternatives that need attention instead. How about you create a 
patch set (instead of threatening emails) that adds the ability to 
detect a bad boot and have grub prompt the user for an action the next 
time the system boots?

Examples:
"Boot into older kernel?", "Boot with safe graphics mode?", etc.

Then grub can remain hidden by default to provide a nice end-user 
experience and if booting fails a, less technically inclined, user gets 
shown some alternative boot methods.

[Reindl Harald]

Am 06.02.2012 17:35, schrieb Rahul Sundaram:
>  On 02/06/2012 10:01 PM, Reindl Harald wrote:
>  
> >
> > it was refreshed for me with the question below
> > without such idiotic changes this sort of problems
> > would simply not exist and people would learn to
> > use their OS instead obfuscate all options from
> > the users like windows
> >
> > what does this user if he has no other computer
> > for his question?
>  
>  You should ask the CentOS user that question instead of asking people
>  who cannot possibly know that and it is off topic here.  Let's limit
>  discussions to Fedora development in this list.  If you have a GRUB
>  specific concern, file a bug report. 
it is a "Fedora development" discussion and no there is not
a bugreport the right answer because it is a WRONG desicion
made in Fedora some releases ago to hide the boot-menu

[Josh Boyer]

On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrett <mjg59(a)srcf.ucam.org&gt; wrote:
>  On Mon, Feb 06, 2012 at 05:25:08PM +0100, Reindl Harald wrote:
>
> > and why are there so many noobs with questions like "after a kernel
> > update my machine does no longer boot" if this decision would
> > be smart?
>
>  The solution to "My kernel update doesn't boot" should be
> "Automatically
>  detect that that happened, give the user that information and fall back
>  to the old kernel", not "Always show the user a menu that they almost
>  always don't care about". Solve the actual problem. 
Agreed.  Having a simple one-shot boot facility would be awesome.  If anyone
has ideas on how to accomplish this, please let me know.  I'd be willing to
look at implementing this.

josh

[Reindl Harald]

Am 06.02.2012 17:37, schrieb Michael Cronenworth:
>  Reindl Harald wrote:
> > it was refreshed for me with the question below
> > without such idiotic changes this sort of problems
> > would simply not exist and people would learn to
> > use their OS instead obfuscate all options from
> > the users like windows
> >
> > what does this user if he has no other computer
> > for his question?
>  
>  Instead of forcing down your opinion down everyone's throats, there are nicer
> alternatives that need attention
>  instead. How about you create a patch set (instead of threatening emails) that adds the
> ability to detect a bad
>  boot and have grub prompt the user for an action the next time the system boots? 
if it ain't broken do not fix it

why should any magical patch be needed if a working for long time
behavior was changed for dying in beauty? i did even not know that
it was changed sooo bad because the first thing i do is disable quiet
and the whole graphical boot

but it was not clear to me that in the meantime the whole menu
was hidden from the users who do not know about this

"adds the ability to detect a bad boot and have grub prompt the user for an action
the next time the system boots" -> if boot fails you want to write to
a disk without knowing what happens what wozld be needed to know that
it failed the last time -> very bad idea!

[Rahul Sundaram]

On 02/06/2012 10:08 PM, Reindl Harald wrote:

>  it is a "Fedora development" discussion and no there is
> not
>  a bugreport the right answer because it is a WRONG desicion
>  made in Fedora some releases ago to hide the boot-menu 
why a CentOS user wants to boot into a alternative kernel is not a
Fedora development discussion and the GRUB maintainer does not believe
it is wrong to hide the GRUB menu by default.  So be persuasive (that
doesn't involve screaming or yelling) in your arguments if you have any.

Rahul

[Petr Šabata]

On Mon, Feb 06, 2012 at 05:38:51PM +0100, Reindl Harald wrote:
>  
>  
>  Am 06.02.2012 17:35, schrieb Rahul Sundaram:
>  > On 02/06/2012 10:01 PM, Reindl Harald wrote:
>  > 
>  >>
>  >> it was refreshed for me with the question below
>  >> without such idiotic changes this sort of problems
>  >> would simply not exist and people would learn to
>  >> use their OS instead obfuscate all options from
>  >> the users like windows
>  >>
>  >> what does this user if he has no other computer
>  >> for his question?
>  > 
>  > You should ask the CentOS user that question instead of asking people
>  > who cannot possibly know that and it is off topic here.  Let's limit
>  > discussions to Fedora development in this list.  If you have a GRUB
>  > specific concern, file a bug report.
>  
>  it is a "Fedora development" discussion and no there is not
>  a bugreport the right answer because it is a WRONG desicion
>  made in Fedora some releases ago to hide the boot-menu 
I am completely happy with a hidden menu and if it wasn't like that by default,
I'd just change my grub settings.  That's my opinion and taste, different from
yours.  Ha.

Teach them how to display the menu if needed or reconfigure the software to
suit their needs.

Oh, and could stop posting hate emails with insulting tone all the time?

-P


>  -- 
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Reindl Harald]

Am 06.02.2012 17:44, schrieb Petr Šabata:
>  I am completely happy with a hidden menu and if it wasn't like
> that by default,
>  I'd just change my grub settings.  That's my opinion and taste, different from
>  yours.  Ha. 
no problem, configure it
the new user does know nothing about it!

>  Teach them how to display the menu if needed or reconfigure the
> software to
>  suit their needs. 
if you have permanently to teach people about the same default
problem the default is wrong and how will you teach anybody
no longer able to boot his only computer?

>  Oh, and could stop posting hate emails with insulting tone all the
> time? 
jesus if THIS is a "hate email" you never saw hate in your life

[Petr Šabata]

On Mon, Feb 06, 2012 at 05:50:59PM +0100, Reindl Harald wrote:
>  
>  
>  Am 06.02.2012 17:44, schrieb Petr Šabata:
>  > I am completely happy with a hidden menu and if it wasn't like that by default,
>  > I'd just change my grub settings.  That's my opinion and taste, different
> from
>  > yours.  Ha.
>  
>  no problem, configure it
>  the new user does know nothing about it!
>  
>  > Teach them how to display the menu if needed or reconfigure the software to
>  > suit their needs.
>  
>  if you have permanently to teach people about the same default
>  problem the default is wrong and how will you teach anybody
>  no longer able to boot his only computer? 
Maybe those users should read that and understand "Press ESC
to show the menu..." which is displayed for several seconds,
if I'm not mistaken.  If they can't do that, I wouldn't trust
them with selecting the right kernel or anything...

>  
>  > Oh, and could stop posting hate emails with insulting tone all the time?
>  
>  jesus if THIS is a "hate email" you never saw hate in your life 
I live such a happy life, wheee!

-P

[Reindl Harald]

Am 06.02.2012 17:42, schrieb Rahul Sundaram:
>  On 02/06/2012 10:08 PM, Reindl Harald wrote:
>  
> > it is a "Fedora development" discussion and no there is not
> > a bugreport the right answer because it is a WRONG desicion
> > made in Fedora some releases ago to hide the boot-menu
>  
>  why a CentOS user wants to boot into a alternative kernel is not a
>  Fedora development discussion  
it is a GENERAL discussion affecting fedora too and was
introduced in CentOS from fedora

>  and the GRUB maintainer does not believe
>  it is wrong to hide the GRUB menu by default.   
and if this is a well thought decision i wanted to point out again

>  in your arguments if you have any. 
why do you not read the arguments?

* a new user does not know anything about the menu
* a new user fall into a boot problem after update
* the user has only one computer
* the user possibly has no LiveCD
* the user can not go to any documentation because his machine refuses to boot
* you can not educate the user after lost this game

so what is the glory of hide well thought features from users?

[Matthew Garrett]

On Mon, Feb 06, 2012 at 11:40:28AM -0500, Josh Boyer wrote:
>  On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrett
> <mjg59(a)srcf.ucam.org&gt; wrote:
>  > The solution to "My kernel update doesn't boot" should be
> "Automatically
>  > detect that that happened, give the user that information and fall back
>  > to the old kernel", not "Always show the user a menu that they almost
>  > always don't care about". Solve the actual problem.
>  
>  Agreed.  Having a simple one-shot boot facility would be awesome.  If anyone
>  has ideas on how to accomplish this, please let me know.  I'd be willing to
>  look at implementing this. 
Add a byte to the grub config block (wherever setdefault gets written) 
indicating whether a boot was clean or not. Have grub set clear that at 
kernel load, and then have a userspace app that sets it at the 
completion of boot. Check whether it's set or not on next boot and use 
that to run a different config stanza.

In theory I think you could do something with the BIOS simple boot flag, 
but that could get confusing in a dual boot scenario.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Peter Jones]

On 02/06/2012 11:40 AM, Josh Boyer wrote:
>  On Mon, Feb 6, 2012 at 11:36 AM, Matthew
> Garrett<mjg59(a)srcf.ucam.org>  wrote:
> > On Mon, Feb 06, 2012 at 05:25:08PM +0100, Reindl Harald wrote:
> >
> >> and why are there so many noobs with questions like "after a kernel
> >> update my machine does no longer boot" if this decision would
> >> be smart?
> >
> > The solution to "My kernel update doesn't boot" should be
> "Automatically
> > detect that that happened, give the user that information and fall back
> > to the old kernel", not "Always show the user a menu that they almost
> > always don't care about". Solve the actual problem.
>
>  Agreed.  Having a simple one-shot boot facility would be awesome.  If anyone
>  has ideas on how to accomplish this, please let me know.  I'd be willing to
>  look at implementing this. 
So, this is something we could probably do with what we've got now.  It'd
require some changes to kernel's .spec, and probably a few minor changes in
grubby, and something would have to provide a systemd service.  Here's the
basic algorithm:

1) kernel's %post/%posttrans adds the new stanza using new-kernel-package/
    grubby, but doesn't make the new kernel default.
2) kernel's %post saves new kernel version someplace (/etc/sysconfig/newkernel
    for the purpose of this text, we can decide if there's a more appropraite
    place)
3) set next boot kernel to the new kernel with grub2-reboot
4) during boot up, a systemd service compares uname to /etc/sysconfig/newkernel
  a) if they match, it worked - use grubby to make it the default
  b) if they don't match, it failed - do whatever it is you guys want to do.

The only problem here is that when we get to 4b, we don't *really* know
that we've attempted to boot the new kernel - the user could have manually
intervened and booted the old (or some other) kernel.  Dunno how to avoid that.

-- 
         Peter

[Jarosław Górny]

Hi,

Wiadomość napisana w dniu 2012-02-06, o godz. 17:55, przez Reindl  
Harald:
> > in your arguments if you have any.
>
>  why do you not read the arguments?
>
>  * a new user does not know anything about the menu
>  * a new user fall into a boot problem after update 

If we are considering such a newbie user as you describe, I bet this  
user does not know if system update installed a new kernel or not.  
(S)he probably does not know what the kernel is.
So, why do you assume, such a user, having grub menu *not* hidden,  
will guess, that in case of boot problem (s)he should try to boot  
another kernel?

Another thing is:
I like breaking things. A lot. But since a *long*  time (read: couple  
of years) I didn't have kernel crash after reboot on *stock* kernel  
provided by *stable* Fedora release. And with CentOS, this statement  
is even more true, due to the nature of this distribution.
Only problems I had, were with custom made kernels.

So, really, I don't see any problem here. And based on comments of  
other users, I'm not alone here.

regards,

-- 
Jarosław Górny
RHCE: 805008212834187

[Rahul Sundaram]

On 02/06/2012 10:25 PM, Reindl Harald wrote:

>  it is a GENERAL discussion affecting fedora too and was
>  introduced in CentOS from fedora 
If Fedora users are affected, . be more direct.  CentOS or RHEL
discussions here are not appropriate.

>  why do you not read the arguments? 
Because it was mixed with all the yelling which is a consistent strategy
of yours which you need to drop. It is not effective.
>  
>  * a new user does not know anything about the menu
>  * a new user fall into a boot problem after update 
Then let's address this boot problem.

Rahul

[Reindl Harald]

Am 06.02.2012 18:02, schrieb Jarosław Górny:
>  Hi,
>  
>  Wiadomość napisana w dniu 2012-02-06, o godz. 17:55, przez Reindl Harald:
> >> in your arguments if you have any.
> >
> > why do you not read the arguments?
> >
> > * a new user does not know anything about the menu
> > * a new user fall into a boot problem after update
>  
>  
>  If we are considering such a newbie user as you describe, I bet this user does not know
> if system update installed
>  a new kernel or not. (S)he probably does not know what the kernel is.
>  So, why do you assume, such a user, having grub menu *not* hidden, will guess, that in
> case of boot problem (s)he
>  should try to boot another kernel? 
because i learned it exactly this way long time ago
with FC3 after a machine did not boot and it was
absolutely logical for me what this boot-menu means
and even if not totally - if my machine does not boot
without interaction and i have a menu at startup i
would simply try the other option

and having this example from the centos-list does make it
very clear - this users question was explictly how to
boot with another kernel, so he found out somehow that
there is more than once and even then needed help!

[Przemek Klosowski]

On 02/06/2012 11:58 AM, Peter Jones wrote:

>  grubby, and something would have to provide a systemd service. 
> Here's the
>  basic algorithm:
>
>  1) kernel's %post/%posttrans adds the new stanza using new-kernel-package/
>       grubby, but doesn't make the new kernel default.
>  2) kernel's %post saves new kernel version someplace (/etc/sysconfig/newkernel
>       for the purpose of this text, we can decide if there's a more appropraite
>       place)
>  3) set next boot kernel to the new kernel with grub2-reboot
>  4) during boot up, a systemd service compares uname to /etc/sysconfig/newkernel
>     a) if they match, it worked - use grubby to make it the default
>     b) if they don't match, it failed - do whatever it is you guys want to do.
>
>  The only problem here is that when we get to 4b, we don't *really* know
>  that we've attempted to boot the new kernel - the user could have manually
>  intervened and booted the old (or some other) kernel.  Dunno how to avoid that.
>  
Would this be solved by writing down the version (output of 'uname -r' 
and/or 'cat /proc/cmdline' ) of the kernel after it successfully boots? 
if it worked last time, it should work again.

[Miloslav Trmač]

About a year ago Harald had a talk about a "smart initrd" /
"integrated rescue mode" along similar lines. Is this still under
development?
   Mirek

[Peter Jones]

On 02/06/2012 02:01 PM, Przemek Klosowski wrote:
>  On 02/06/2012 11:58 AM, Peter Jones wrote:
>
> > grubby, and something would have to provide a systemd service. Here's the
> > basic algorithm:
> >
> > 1) kernel's %post/%posttrans adds the new stanza using new-kernel-package/
> > grubby, but doesn't make the new kernel default.
> > 2) kernel's %post saves new kernel version someplace (/etc/sysconfig/newkernel
> > for the purpose of this text, we can decide if there's a more appropraite
> > place)
> > 3) set next boot kernel to the new kernel with grub2-reboot
> > 4) during boot up, a systemd service compares uname to /etc/sysconfig/newkernel
> > a) if they match, it worked - use grubby to make it the default
> > b) if they don't match, it failed - do whatever it is you guys want to do.
> >
> > The only problem here is that when we get to 4b, we don't *really* know
> > that we've attempted to boot the new kernel - the user could have manually
> > intervened and booted the old (or some other) kernel. Dunno how to avoid that.
> >
>
>  Would this be solved by writing down the version (output of 'uname -r' and/or
>  'cat /proc/cmdline' ) of the kernel after it successfully boots? if it worked
>  last time, it should work again. 
No - the problem isn't that we can't spot success, the problem is that we
can't
actually detect failure.  But Matthew's suggestion effectively solves that.

-- 
         Peter

[Adam Williamson]

On Mon, 2012-02-06 at 18:02 +0100, Jarosław Górny wrote:
>  Hi,
>  
>  Wiadomość napisana w dniu 2012-02-06, o godz. 17:55, przez Reindl  
>  Harald:
>  >> in your arguments if you have any.
>  >
>  > why do you not read the arguments?
>  >
>  > * a new user does not know anything about the menu
>  > * a new user fall into a boot problem after update
>  
>  
>  If we are considering such a newbie user as you describe, I bet this  
>  user does not know if system update installed a new kernel or not.  
>  (S)he probably does not know what the kernel is.
>  So, why do you assume, such a user, having grub menu *not* hidden,  
>  will guess, that in case of boot problem (s)he should try to boot  
>  another kernel? 
Well, they do. Generally what people do when something is broken and
they don't really know what or how to fix it is twiddle: they look for
something they can poke, and poke it. A boot menu is an excellent
example of a twiddle-able interface, if you always show it: it's right
there, on boot. It's actually just about the only thing the user CAN
twiddle, if booting the default kernel doesn't work - the only bit where
they feel they can influence the process. So, in my experience, that's
what they do: they try a different menu entry. They don't actually
_need_ the knowledge of what the hell they're doing. All they need is
the knowledge that 'this is a menu with different entries and choosing
one of the other ones might make something different happen'.

Obviously this tweaking reflex can lead to disaster in _some_ cases, but
in the case of recovering from a bad kernel, it actually serves people
rather well.

I agree with the kernel team that a better option would be some kind of
smart recovery from failed boot, though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Harald Hoyer]

Am 06.02.2012 20:17, schrieb Miloslav Trmač:
>  About a year ago Harald had a talk about a "smart initrd"
> /
>  "integrated rescue mode" along similar lines. Is this still under
>  development?
>     Mirek 
Not yet developed, but still on my agenda

[Peter Jones]

Matthew said:
>  Add a byte to the grub config block (wherever setdefault gets
> written) 
>  indicating whether a boot was clean or not. Have grub set clear that at 
>  kernel load, and then have a userspace app that sets it at the 
>  completion of boot. Check whether it's set or not on next boot and use 
>  that to run a different config stanza. 
With this in mind, I'm sending the following patch for grub2 upstream.  It
implements something analogous to this for UEFI systems.  With this, a
change to how we generate grub2 configuration files (just adding a call),
and small amount of userland hacking, we can effectively cause the bootloader
to use a large timeout when the previous boot has failed.

[PATCH] Add check_completed_boot command on EFI systems.

[Peter Jones]

check_completed_boot <guid> [<timeout>]

checks for a 1-byte integer in an EFI variable guid:CompletedBoot and sets
a command-line specified timeout, with a default of 30s, if the variable is
not equal to 1.  This can be used to enter the grub menus in the event that
your OS did not correctly boot on the previous boot.  It also unconditionally
sets the value to 0.
---
 grub-core/Makefile.core.def           |    6 ++
 grub-core/commands/efi/eficompleted.c |  117 +++++++++++++++++++++++++++++++++
 2 files changed, 123 insertions(+)
 create mode 100644 grub-core/commands/efi/eficompleted.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index d0c06d5..0a21838 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -582,6 +582,12 @@ module = {
 };
 
 module = {
+  name = eficompleted;
+  efi = commands/efi/eficompleted.c;
+  enable = efi;
+};
+
+module = {
   name = blocklist;
   common = commands/blocklist.c;
 };
diff --git a/grub-core/commands/efi/eficompleted.c
b/grub-core/commands/efi/eficompleted.c
new file mode 100644
index 0000000..77a856a
--- /dev/null
+++ b/grub-core/commands/efi/eficompleted.c
@@ -0,0 +1,117 @@
+/* completed.c - Check if previous boot was successful. */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2012  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>;.
+ */
+#include <grub/types.h>
+#include <grub/mm.h>
+#include <grub/misc.h>
+#include <grub/efi/api.h>
+#include <grub/efi/efi.h>
+#include <grub/command.h>
+
+GRUB_MOD_LICENSE ("GPLv3+");
+
+static grub_err_t
+grub_efi_parse_guid(char *arg, grub_efi_guid_t *outguid)
+{
+  grub_err_t status = GRUB_ERR_NONE;
+  grub_efi_guid_t guid;
+  char *s = arg;
+  grub_uint64_t guidcomp;
+  int i;
+
+  guid.data1 = grub_cpu_to_le32 (grub_strtoul(s, &s, 16));
+  if (*s != '-')
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid guid `%s'", arg);
+  s++;
+
+  guid.data2 = grub_cpu_to_le16 (grub_strtoul(s, &s, 16));
+  if (*s != '-')
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid guid `%s'", arg);
+  s++;
+
+  guid.data2 = grub_cpu_to_le16 (grub_strtoul(s, &s, 16));
+  if (*s != '-')
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, "invalid guid `%s'", arg);
+  s++;
+
+  guidcomp = grub_strtoull (s, 0, 16);
+  for (i = 0; i < 8; i++)
+    guid.data4[i] = (guidcomp >> (56 - 8 * i)) & 0xff;
+
+  grub_memcpy(outguid, &guid, sizeof (*outguid));
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_cmd_completed (grub_command_t cmd __attribute__ ((unused)),
+		  int argc __attribute__ ((unused)),
+		  char **args __attribute__ ((unused)))
+{
+  grub_efi_uint8_t *old_completed_boot;
+  grub_efi_uint8_t completed_boot = 0;
+  unsigned long timeout = 30;
+  grub_efi_guid_t guid;
+  grub_err_t status;
+  grub_size_t cb_size;
+
+  if (argc < 2)
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, "too few arguments");
+
+  if (argc > 3)
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, "too many arguments");
+
+  status = grub_efi_parse_guid(args[1], &guid);
+  if (status != GRUB_ERR_NONE)
+    return status;
+
+  if (argc > 2)
+    {
+      char *s = args[2];
+      timeout = grub_strtoul(s, &s, 0);
+      if (grub_errno != GRUB_ERR_NONE)
+	return grub_errno;
+    }
+
+  old_completed_boot = grub_efi_get_variable("CompletedBoot", &guid,
&cb_size);
+  status = grub_efi_set_variable("CompletedBoot", &guid,
&completed_boot,
+				 sizeof (completed_boot));
+
+  if (old_completed_boot == NULL)
+    {
+      /* We assume this means it's our first boot after installation. */
+      return GRUB_ERR_NONE;
+    }
+
+  if (cb_size != sizeof(*old_completed_boot) || *old_completed_boot != 1)
+    grub_env_set("timeout", timeout);
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_command_t cmd = NULL;
+
+GRUB_MOD_INIT(eficompleted)
+{
+  cmd = grub_register_command("check_completed_boot", grub_cmd_completed,
"",
+			      "Check if the last boot completed successfully.");
+}
+
+GRUB_MOD_FINI(eficompleted)
+{
+  grub_unregister_command (cmd);
+}
-- 
1.7.10.1

[Adam Williamson]

On Fri, 2012-05-25 at 11:35 -0400, Peter Jones wrote:
>  Matthew said:
>  > Add a byte to the grub config block (wherever setdefault gets written) 
>  > indicating whether a boot was clean or not. Have grub set clear that at 
>  > kernel load, and then have a userspace app that sets it at the 
>  > completion of boot. Check whether it's set or not on next boot and use 
>  > that to run a different config stanza.
>  
>  With this in mind, I'm sending the following patch for grub2 upstream.  It
>  implements something analogous to this for UEFI systems.  With this, a
>  change to how we generate grub2 configuration files (just adding a call),
>  and small amount of userland hacking, we can effectively cause the bootloader
>  to use a large timeout when the previous boot has failed. 
Since this is an old thread I forget who's said what, but I'm guessing
you know Ubuntu implements something similar for BIOS boots? I don't
know if they've submitted it upstream.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net