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
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.
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
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.
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!
On Mon, Feb 06, 2012 at 17:22:52 +0100, Reindl Harald h.reindl@thelounge.net 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.
Am 06.02.2012 17:25, schrieb Bruno Wolff III:
On Mon, Feb 06, 2012 at 17:22:52 +0100, Reindl Harald h.reindl@thelounge.net 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]#
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
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
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
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?
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,
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!
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.
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
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 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.
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!
On Mon, Feb 6, 2012 at 3:16 PM, Reindl Harald h.reindl@thelounge.net 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.
Am 06.02.2012 17:16, schrieb drago01:
On Mon, Feb 6, 2012 at 3:16 PM, Reindl Harald h.reindl@thelounge.net 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"
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.
On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrett mjg59@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.
josh
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@srcf.ucam.org 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 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.
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); +}
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.
On 02/06/2012 11:40 AM, Josh Boyer wrote:
On Mon, Feb 6, 2012 at 11:36 AM, Matthew Garrettmjg59@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.
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:
- kernel's %post/%posttrans adds the new stanza using new-kernel-package/ grubby, but doesn't make the new kernel default.
- 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)
- set next boot kernel to the new kernel with grub2-reboot
- 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.
About a year ago Harald had a talk about a "smart initrd" / "integrated rescue mode" along similar lines. Is this still under development? Mirek
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:
- 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.
-
Adam Williamson -
Bruno Wolff III -
drago01 -
Harald Hoyer -
Jarosław Górny -
Josh Boyer -
Matthew Garrett -
Michael Cronenworth -
Miloslav Trmač -
Peter Jones -
Petr Šabata -
Przemek Klosowski -
Rahul Sundaram -
Reindl Harald -
Tomasz Torcz