This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 840204 - grub2 ask for the password at each boot
grub2 ask for the password at each boot
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
20
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 840160 866393 (view as bug list)
Depends On:
Blocks: 1030176
  Show dependency treegraph
 
Reported: 2012-07-14 06:53 EDT by Heldwin
Modified: 2015-01-09 12:28 EST (History)
42 users (show)

See Also:
Fixed In Version: grub2-2.00-26.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-30 17:56:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for /etc/grub.d/10_linux as workaround for unrestricted boot (1.96 KB, patch)
2013-05-28 23:31 EDT, Edgar Hoch
no flags Details | Diff
Patch for /etc/grub.d/30_os-prober as workaround for unrestricted boot (2.27 KB, patch)
2013-05-28 23:32 EDT, Edgar Hoch
no flags Details | Diff

  None (edit)
Description Heldwin 2012-07-14 06:53:38 EDT
Description of problem:
I updated my system wih the new grub2-beta6, and forced it in my system.
Now it is asking for the grub2 username and password at each boot.


Version-Release number of selected component (if applicable):
grub2-2.0-0.37.beta6.fc17.x86_64

How reproducible:
Not sure.

Steps to Reproduce:
1. set a password to grub2 or install F17 adding a password to grub2
2. yum update grub2
3. grub2-install /dev/sda
4. grub2-mkconfig -o /boot/grub2/grub.cfg
  
Actual results:
Every boot, it asks for the grub2 username and password.

Expected results:
System boot normally if not trying to modify grub2 entries.

Additional info:
I added the grub2 password with anaconda during installation.
Entry in grub2 doesn't show others installed kernels anymore, but list them in grub.cfg.
Comment 1 Heldwin 2012-07-15 16:00:20 EDT
I added an equivalent bug report, but reported for anaconda, in the external trackers, but the link created doesn't open the correct page. So I removed it and added the link here.

https://bugzilla.redhat.com/show_bug.cgi?id=840160
Comment 2 Bert DeKnuydt 2012-07-17 07:03:29 EDT
Apparently, to allow an entry to be booted by anyone, it now needs to be labeled
'--unrestricted' in grub2.cfg, on the 'menuentry' line.

See https://www.gnu.org/software/grub/manual/html_node/Security.html#Security

So this should work:

menuentry 'Fedora' --class fedora --class gnu-linux --class gnu --class os --unrestricted ...

But it doesn't.  The only way out I found, is to downgrade to 
grub2-2.0-0.25.beta4.fc17, and force a grub2-install.  

Later you can upgrade it back, (if you want the theme to be broken
and fonts to be nuked), but you can still boot without password.
Comment 3 Jason Tibbitts 2012-07-17 15:46:31 EDT
Wow, this is bad, and is causing significant problems here.  Guess I'll just rebuild beta4 with an epoch.
Comment 4 Mads Kiilerich 2012-07-31 13:01:55 EDT
This functionality depends a lot on deep customizations done by anaconda.

FWIW: Upstream and I don't know anaconda and don't know exactly which tweaks it makes for password auth.

Please attach (possibly with masked password hashes) /etc/default/grub, any custom scripts in /etc/grub.d, and /boot/grub2/grub.cfg .


When would you expect grub2 to prompt for password - how did it work before the upgrade?
Comment 5 Josh Trutwin 2012-07-31 16:32:18 EDT
I am also currently fighting this one - the old behavior from grub1 is desired, where you only have to put in a password to EDIT the grub menu item so you cannot have someone modify the line to boot into single-user mode.  Right now you have to enter a password just to even boot up the default menu item (well an ANY menu item for that matter). 

Thanks,

Josh
Comment 6 Josh Trutwin 2012-07-31 16:38:12 EDT
Use case for this would be a computer lab - as an administrator I want the ability to be able to come in and modify boot options - or even give certain trusted faculty this ability.  But students should not have the ability to edit any of the boot options.  The smarter ones do try....

(In reply to comment #5)
> I am also currently fighting this one - the old behavior from grub1 is
> desired, where you only have to put in a password to EDIT the grub menu item
> so you cannot have someone modify the line to boot into single-user mode. 
> Right now you have to enter a password just to even boot up the default menu
> item (well an ANY menu item for that matter). 
> 
> Thanks,
> 
> Josh
Comment 7 Heldwin 2012-07-31 19:39:23 EDT
a) I have installed a test environment for F17 in a virtual machine and I have backuped /etc and /boot.

1) If I install grub2-2.0-0.37.beta6.fc17.x86_64, replace the /etc and /boot directories with the backup and reinstall grub2 in /dev/sda, I get the asking password entry at boot.

2) If I remove grub2-tools, with: rpm -e grub2-tools --nodeps, downgrade grub2 to the beta4, and reinstall grub2 on /dev/sda, I still get the asking password entry.

3) If I remove grub2-tools, with: rpm -e grub2-tools --nodeps, downgrade grub2 to the beta4, replace the /etc and /boot directories with the backup, and reinstall grub2 on /dev/sda, I don't get the asking password entry.

I can still provide you the configuration files if you still need them.


b) Before the upgrade, we were able to only edit the grub with the password, but it would boot normally.
Comment 8 Heldwin 2012-07-31 19:58:07 EDT
Sorry... too much testing...
point 2 is wrong.

It seems the /boot and /etc directories are the same.

After you upgrade to grub2-beta6, and reinstall grub2 on /dev/sda, it will ask for the password at boot.

After that, If you remove grub2-tools, with: rpm -e grub2-tools --nodeps, downgrade grub2 to the beta4, and reinstall grub2 on /dev/sda, it doesn't ask for the password at boot.

So, it looks like the configuration files are the same, but seems it is grub2-beta6 and grub2-tools that handle them differently.
Comment 9 Bert DeKnuydt 2012-08-02 05:39:49 EDT
To reply to #4:

1) I drop a file 03_security in /etc/grub.d

#! /bin/sh
echo 'set superusers="root"'
echo password_pbkdf2 root grub.pbkdf2.sha512.10000.XXXXHASHED_PASSWD_HEREXXXX

2) /etc/default/grub should be pretty standard

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0  KEYTABLE=us  rd.lvm.lv=vg_eyedonnix/LogVol00 rd.lvm.lv=vg_eyedonnix/LogVol01 rd.luks=0 LANG=en_US.UTF-8 rhgb quiet"
#GRUB_THEME="/boot/grub2/themes/system/theme.txt"
GRUB_CMDLINE_LINUX+=" nouveau.modeset=0 rdblacklist=nouveau"
GRUB_DISABLE_RECOVERY=true

The rest is untouched... This worked flawlessly up to the last update.

What behavious I'd like: 
 
-- Minimally what was in grub 0.99 and in the previous version of grub2:
   the ability to set a password to command-line access.  Reason is
   exactly as poster #6 says: kiosk PC's/ classrooms etc.

-- Ideally the full 'user-management' _as described somewhere in the grub2 
   manual_, i.e. to set a password per 'user', (e.g.: root, service).  
   Ask the root password for editing/command line, ask the service password to 
   boot specific things (e.g. DOS shell, memcheck, known-buggy kernel, windows).
   Let everyone boot the remainder (e.g. std. Fedora boot)
Comment 10 Mads Kiilerich 2012-08-03 08:29:02 EDT
Everybody: Make sure you run grub2-install and grub2-mkconfig after up/downgrading grub2 if you want to use the new version. Otherwise you might get a confusing result.

Quoting http://www.gnu.org/software/grub/manual/grub.html#Security :
  The grub-mkconfig program does not yet have built-in support for generating
  configuration files with authentication.

I don't know what happened between beta4 and beta6 that can have made a difference.

As a workaround edit /etc/grub.d/10_linux line 29 and change to
  CLASS="--class gnu-linux --class gnu --class os --unrestricted"
Comment 11 JM 2012-08-06 12:25:31 EDT
The workaround from comment #10 works for me (dont't forget to run grub2-mkconfig -o /boot/grub2/grub.cfg after you changed /etc/grub.d/10_linux) but I still have to enter a username and password when I try to *select* (not edit) the menu 'Advanced options for Fedora'.
Comment 12 JM 2012-08-06 13:02:39 EDT
I changed line 239 (ib file /etc/grub.d/10_linux) so that it looks like this:

    echo "submenu '$(gettext_printf "Advanced options for %s" "${OS}" | grub_quote)' --unrestricted \$menuentry_id_option 'gnulinux-advanced-$boot_device_id' {"

Dont't forget to run 'grub2-mkconfig -o /boot/grub2/grub.cfg' after you changed /etc/grub.d/10_linux.

the 'submenu' needs the '--unrestricted' option as well or you can't select anything inside the submenu... but of course you can't go back with 'Esc' from the submenu because for the way back you need again the username and password... looks like a bug to me :-).
Comment 13 Frank Crawford 2012-09-09 05:17:56 EDT
(In reply to comment #2)

I though I might mention that one of the original issues, i.e. use of --unrestricted didn't work is fixed in the latest grub2 release, i.e. grub2-2.0-0.38.beta6.fc17.i686.  Of course you do have to rerun grub2-install, etc, before it is fixed.

However, the issue that --unrestricted is not currently set by grub2-mkconfig is still an issue.
Comment 14 Mads Kiilerich 2012-10-15 05:26:46 EDT
*** Bug 866393 has been marked as a duplicate of this bug. ***
Comment 15 David Jansen 2012-12-12 05:36:29 EST
I'm experiencing this same bug in Fedora 18 beta, with a slight twist: immediately after installing Fedora, the system boots fine without a password. But once updates are installed, every boot requires a password.
The fix to add '--unrestricted' fixes this.

Unfortunately, I haven't kept a copy of the grub files from directly after install, so I'm not sure what causes the problem later.
Comment 16 David Jansen 2012-12-12 10:51:36 EST
Correction on my previous note (#15): Fedora 18 beta has this issue, if a password was set. The one occasion when I thought the bug was absent, was when I forgot to set a password during installation. The bug occured later not due to updates, but due to creating a /etc/grub.d/01_users with user and password, and running grub2-mkconfig to activate that change.
So, it's as ugly and clumsy as in Fedora 17, and I hope the --unrestricted options will be added in the proper place as an update, since I cannot imagine that requirering a password to boot the system is the intended behaviour of the bootloader.
Comment 17 Harald Reindl 2012-12-12 11:04:37 EST
in fact it was damaged somewhere after F16
this did work initially after switch to GRUB2

some random update replaced the config-file where i defined it
and renamed it to ".rpmsave", i do not remember this time
but i found how to protect the setup with GRUB2 again somewhere

so this is a really ugly behavior because:
* it did work
* it replaced my configuration and unprotected the machines
* after find out they are unproctected and restore it you
  are terrible fucked on remote-machines which never reboots again

protect grub and single-user-mode is a BASIC and MANDATORY
mechnism if somebody cares about security
Comment 18 Ferry Huberts 2012-12-28 10:44:43 EST
I ihave this problem too.

Due to some experimentation I had to reinstall grub2.
Now my machine asks for a password on every boot, while it didn't do this when I originally installed F17 (with a grub2 password)

I'd say this is a regression.
Comment 19 Ferry Huberts 2012-12-28 11:13:39 EST
I played around a bit with the config file generation:

After adding '--unrestricted' on _every_ menu entry and sub-menu I not longer need to enter a password for booting the menu entries or for entering the sub-menus.

HOWEVER: I do have to enter a password to enter the main menu!

This smells like the default setting that is controlled by '--unrestricted' was flipped in the code from 'unrestricted' to 'restricted'.
Comment 20 Ferry Huberts 2012-12-28 11:14:49 EST
(In reply to comment #19)
> HOWEVER: I do have to enter a password to enter the main menu!

...when I'm in a sub-menu.

No password is required to enter the main menu when booting the machine
Comment 21 Harald Reindl 2012-12-28 11:58:19 EST
the password should only be needed if you EDIT any entry and not for untouched boots and/or select a entry - currently GRUB2 is horrible broken in F17, nobody cares, nobody updates beta-crap to final and fix bugs
Comment 22 Gilboa Davara 2013-01-07 05:53:40 EST
Any chance of fixing this bug for F18?
As others pointed out this is a *major* issue for servers.

- Gilboa
Comment 23 Trever Adams 2013-01-15 19:59:28 EST
It would be good for the owner of this bug to change the version to 18 as it still exists. This is a REAL pain with VMs.
Comment 24 Mads Kiilerich 2013-01-15 20:03:43 EST
Fedora 17 still exists.
Comment 25 Harald Reindl 2013-01-15 20:39:57 EST
> Fedora 17 still exists

cool - the bug exists also in F18

did you ever consider to fix it since it was NOT THERE at the begin of GRUB2 or does nobody care about GRUB bugs at all?
Comment 26 Heldwin 2013-01-17 16:08:08 EST
Changed to F18, as once they have found how to fix it, it should be backported to F17 ?
Comment 27 Rodolfo Alcazar 2013-01-23 21:25:12 EST
This is perfectly functional GRUB2 on F18, with password for me:

# /usr/bin/grub2-mkpasswd-pbkdf2 # (Copy hash)

# cat /etc/grub.d/01_users # (create file, paste hash, requires cat & EOFs, not documented as this!; CAREFUL! if you fail copying hash, perhaps you lose access completely!)
cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.                                                                                                                 D51A...
export superusers
EOF

# cat /etc/grub.d/10_linux # (add --unrestricted option)
...
CLASS="--class gnu-linux --class gnu --class os --unrestricted"
...

# cat /etc/default/grub # (requires GRUB_DISABLE_RECOVERY=true for --unrestricted)
...
GRUB_DISABLE_RECOVERY="true"
...

# LANG=C grub2-mkconfig -o /boot/grub2/grub.cfg # (rebuild conf, LANG=C fixes #817187)

Now grub2 is finally usable and secure.
Comment 28 Daniel Laczi 2013-02-02 16:18:53 EST
I also have this problem on every upgraded system. I've just installed a new one and at first this problem didn't occure. But after I set a grub password manually (the installer doesn't allow you to set one!) I ran into this again.

As already mentioned before this workaround works:
Edit /etc/grub.d/10_linux line 29 and change to
  CLASS="--class gnu-linux --class gnu --class os --unrestricted"
Comment 29 Harald Reindl 2013-02-02 16:54:20 EST
and why is teh maintainer not fixing "/etc/grub.d/10_linux"?

the last time i set the password in "/etc/grub.d/00_header" it was overwritten by a radnom update and the machine unsafe at all - so no i do not trust anyting in "/etc/grub.d/" because it gets overwritten or may cause troubles if not and something of this GRBU2-crap is updated later

a boot manager has to work out of the box and sicne fedora offered OVER YEARS grub-password in the initial installer this all is a stupid regression nobody cares at distro-level
Comment 30 David Jansen 2013-03-01 11:05:19 EST
And while we're at it, the same fix may be added in /etc/grub.d/30_os-prober so booting windows, or other detected operating systems, will also not require a username and password. but i can imagine that this is something that should be configurable; in some cases, you want to be able to password-protect booting to another operating system.
Comment 31 Bill Perkins 2013-03-11 17:55:46 EDT
I am seeing the described problem only on one of three systems I have that are running Fedora 18.  That system was built with a fresh install from DVD.  

The other two systems were running fresh installs with all updates of Fedora 17, until they were upgraded to Fedora 18 using the Yum upgrade process.  The grub2 boot initial menu header at boot time on these systems says that the version being used is "2.00~beta4".  The third system with its fresh install of Fedora 18 indicates that it is version "2.00".

To get around the problem on that third system, I just deleted the /etc/grup.d/01_users file and reran the grub2-mkinstall.  I would like this system to be able to password protect the boot edit options, but it is not a public system and is only used for testing.
Comment 32 James A. Peltier 2013-03-14 15:42:01 EDT
I am offering up a possible solution to this problem that works for me.  Seemingly the problem is that the default, once a password has been defined, is too restrictive, requiring a user to enter a password just to be able to boot the system.  I propose that we change /usr/sbin/grub2-mkconfig to have an option that is toggled.

if test -f /etc/grub.d/01_grub ; then
  . /etc/grub.d/01_grub
else
  export GRUB_RESTRICTED=false
fi

and then we alter /etc/grub.d/10_linux to read this GRUB_RESTRICTED value

if [ ${GRUB_RESTRICTED} == "true" ]; then
  CLASS="--class gnu-linux --class gnu --class os"
else
  CLASS="--class gnu-linux --class gnu --class os --unrestricted"
fi

if a user wishes to have all entries be password protected for both boot and editing they can create the /etc/grub.d/01_grub with the following content

#! /bin/sh
set -e

export GRUB_RESTRICTED=true

This allows for easy integration with tools like puppet/chef and I think it would also work for other OSs that use GRUB2.  I could be incorrect in my thinking and if so please feel free to correct


/usr/sbin/grub2-mkconfig.patch
==============================

--- grub2-mkconfig        2013-03-14 12:40:13.644413095 -0700
+++ grub2-mkconfig.new        2013-03-14 12:39:55.457535804 -0700
@@ -144,6 +144,12 @@
   . ${sysconfdir}/default/grub
 fi
 
+if test -f /etc/grub.d/01_grub ; then
+  . /etc/grub.d/01_grub
+else
+  export GRUB_RESTRICTED=false
+fi
+
 # XXX: should this be deprecated at some point?
 if [ "x${GRUB_TERMINAL}" != "x" ] ; then
   GRUB_TERMINAL_INPUT="${GRUB_TERMINAL}"


/etc/grub.d/10_linux.patch
==========================

--- 10_linux        2013-03-14 12:35:41.549248949 -0700
+++ 10_linux.new        2013-03-14 12:09:57.290668386 -0700
@@ -23,10 +23,16 @@
 
 . "/usr/share/grub/grub-mkconfig_lib"
 
+#. "/etc/grub.d/01_grub"
+
 export TEXTDOMAIN=grub
 export TEXTDOMAINDIR="${datarootdir}/locale"
 
-CLASS="--class gnu-linux --class gnu --class os"
+if [ ${GRUB_RESTRICTED} == "true" ]; then
+  CLASS="--class gnu-linux --class gnu --class os"
+else
+  CLASS="--class gnu-linux --class gnu --class os --unrestricted"
+fi
 
 if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
   OS="$(sed 's, release .*$,,g' /etc/system-release)"
Comment 33 Bill Perkins 2013-03-14 16:52:19 EDT
(In reply to comment #32)
> I am offering up a possible solution to this problem that works for me. 
> Seemingly the problem is that the default, once a password has been defined,
> is too restrictive, requiring a user to enter a password just to be able to
> boot the system.  I propose that we change /usr/sbin/grub2-mkconfig to have
> an option that is toggled.
> <<< Patch info from comment #32 deleted >>>

I have tried Mr. Peltier's patches from comment #32 on my 64 bit test system that has a fairly standard install of Fedora 18, and that system now only ask for the password when you try to edit an entry.  This, of course, is the old expected behavior from previous versions of Grub Two.  These patches are at least an example of how to resolve the unwanted password problem when booting.
Comment 34 James A. Peltier 2013-03-14 19:40:46 EDT
This patch to /usr/sbin/grub2-mkconfig would make use of the custom GRUB options that could be added in /etc/default/grub .  There are some benefits to this method as well since there is a augeas lens for the /etc/default/grub file that could easily be manipulated with puppet


/usr/sbin/grub2-mkconfig patch 2
================================

--- /usr/sbin/grub2-mkconfig        2012-11-27 12:30:57.000000000 -0800
+++ grub2-mkconfig.new        2013-03-14 16:33:08.531566925 -0700
@@ -216,7 +216,8 @@
   GRUB_INIT_TUNE \
   GRUB_SAVEDEFAULT \
   GRUB_ENABLE_CRYPTODISK \
-  GRUB_BADRAM
+  GRUB_BADRAM \
+  GRUB_RESTRICTED
 
 if test "x${grub_cfg}" != "x"; then
   rm -f "${grub_cfg}.new"


This would of course be more Red Hat specific than the previous patch but perhaps a bit cleaner as there is no need to create a /etc/grub.d/01_grub file *AND* a /etc/grub.d/ custom file that contains the user and password values.  Same basic concept just a bit different approach.
Comment 35 Edgar Hoch 2013-05-28 23:31:23 EDT
Created attachment 754125 [details]
Patch for /etc/grub.d/10_linux as workaround for unrestricted boot

I use this patch (together with the patch for 30_os-prober)
in my kickstart file in the %post section with the command
  patch -p0 -d ${ROOT_DIR}/etc/grub.d < patchfile

This patch is a workaround for Fedora 18.

For a final solution the file /usr/sbin/grub2-mkconfig should be patched to allow and use the option
  GRUB_RESTRICTED="true"
or
  GRUB_RESTRICTED="false"
in file /etc/default/grub .
Comment 36 Edgar Hoch 2013-05-28 23:32:56 EDT
Created attachment 754126 [details]
Patch for /etc/grub.d/30_os-prober as workaround for unrestricted boot

I use this patch (together with the patch for 10_linux)
in my kickstart file in the %post section with the command
  patch -p0 -d ${ROOT_DIR}/etc/grub.d < patchfile

This patch is a workaround for Fedora 18.

For a final solution the file /usr/sbin/grub2-mkconfig should be patched to allow and use the option
  GRUB_RESTRICTED="true"
or
  GRUB_RESTRICTED="false"
in file /etc/default/grub .
Comment 37 Nils Philippsen 2013-06-26 04:24:16 EDT
Just for the record, the issue still exists in grub2-2.00-22.fc19.x86_64 (Fedora 19 post-beta).
Comment 38 Harald Reindl 2013-06-27 09:35:23 EDT
it is ridiculous that nobody cares about this while password-protection without forcing you to drive some hundret miles if you forgot manually fix the grub-config on a remote-machine worked over decades and was even offered in the installer
Comment 39 Harald Reindl 2013-07-08 16:05:19 EDT
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |fche@redhat.com
>            Version|18                          |19

seriously?
Comment 40 Frank Ch. Eigler 2013-07-08 16:09:39 EDT
(Just protecting the bug from autoexpiry a few extra months, not claiming the bug does not exist in f18.)
Comment 41 Harald Reindl 2013-07-08 16:11:54 EDT
thx, i am shortly before move production machines to F18 which will stay at F18 until short after F19 release and it is really annoying permenently take care not lock out of remote machines after grub2-mkconfig and reboot
Comment 42 David Allen 2013-08-28 01:43:35 EDT
I have recently upgraded from F17 to F19 using Fedup. This apparent bug still exists: I am required to enter the root username and associated password in order to even get to the bootloader. A PITA.

What am I, as a *normal* user, supposed to do the fix this? And why is this still a bug after apparently F16 (I upgraded from F15 to F17 using a fresh install before using Fedup for F17 -> F19)?
Comment 43 Josh Trutwin 2013-08-28 10:00:10 EDT
Frustrating to still see this still open and still biting people that have to use systems in an actual work environment, even though it appears someone has posted patches to fix it (comments #32 - #36).  I switched our systems all over to CentOS 6 due to this and other unaddressed issues with Fedora.  I don't know if EL7 is going to have grub2 - I certainly hope not.  If so, maybe then someone will finally care about this...
Comment 44 Chad Feller 2013-08-28 10:59:14 EDT
(In reply to Bert DeKnuydt from comment #2)
...
> But it doesn't.  The only way out I found, is to downgrade to 
> grub2-2.0-0.25.beta4.fc17, and force a grub2-install.  
> 
> Later you can upgrade it back, (if you want the theme to be broken
> and fonts to be nuked), but you can still boot without password.

To everyone still struggling with this: 

This workaround mentioned in comment #2 (quoted here for convenience) works fine.  I've got several Fedora 18 & 19 servers in production, with a password set in grub2, and I am _not_ prompted for a password at each boot.  Just downgrade to this grub version, force a grub2-install. Reboot, make sure it works.

After this you can then let yum upgrade the grub2 version back with no issues.  As long as you don't then do a grub2-install with the later version everything will remain fine.
Comment 45 Harald Reindl 2013-08-29 07:55:45 EDT
how is downgrade of grub2 a workaround?
just add the --unrestricted in grub.cfg does the same

oh and do not touch "grub2-mkconfig" which is only a pitty at all
by clutter the configuration with useless submenus and for this
also exists a bugreport and even a solution but who cares about
F18 if there is F19 and people can work on new bugs for F20

the problem is that Fedora calls itself a "Linux Distribution" while 
it becomes more and more a careless together thrown piece of crap 
which is poorly maintained 

THE JOB OF A DISTRIBUTION IS TO AVOID REGRESSIONS OF RANDOMLY INSTALLED SOFTWARE

otherwise *it would never* have happened that a bootloader with such troubles is the dedfault while over many years even the grub-password was part of the grapical install process
Comment 46 Edgar Hoch 2014-01-07 10:40:54 EST
The problem still exists with Fedora 20.

I still have to patch the files in /etc/grub.d/ in the %post part of my kickstart file if I use the kickstart option "bootloader --location=mbr --md5pass=grub.pbkdf2.sha512....." to avoid a hanging boot process by grub2 username and password request.

I think this should be fixed before a new release, and it should be a blocker bug for new releases.
Comment 47 Josh Trutwin 2014-01-07 10:44:23 EST
Ugh.  So does this problem now exist with the RHEL 7 beta?  I'm going to check and if so open a ticket with Red Hat.
Comment 48 Harald Reindl 2014-01-07 10:48:02 EST
what i do not understand is that *over years* Anaconda offerded to protect the bootloader with a password, the first release with GRUB2 did not have the option but it was possible to do it manually *and later* this stupid regression was introduced and nobody cares over years

until now i have not faced anything but troubles with GRUB2 and no benefit
Comment 50 John Horne 2014-02-25 16:57:37 EST
Wow! Just been trying to resolve this problem on my F20 PC when I came across this bug report. Using a password worked okay for me on F17, but jumping to F20 and finding the problem still not resolved is not good.
Comment 51 Gilboa Davara 2014-05-13 07:16:55 EDT
Any work-around / patch for this issue in F20?
Comment 52 Jason Tibbitts 2014-05-13 10:58:32 EDT
Not one that's any different from the one that's always been useful.
Comment 53 Ian Collier 2014-05-13 11:13:55 EDT
It seems to me this is partially fixed on Fedora 20 in that /etc/grub.d/10_linux contains the line

CLASS="--class gnu-linux --class gnu --class os --unrestricted"

Therefore running grub2-mkconfig should make your Fedora boot without a password.  However, 30_os-prober doesn't unrestrict the OSs it finds.
Comment 54 Adam Williamson 2014-06-19 18:32:42 EDT
Ian: are you sure you checked Fedora 20? I don't see that in F20. I *do* see it in Rawhide and in RHEL 7, but not in F20. It was fixed in response to a RHEL bug report (#1030176 , but it's locked) as a downstream patch, and that patch was brought over to Rawhide, but doesn't appear to be in Fedora 20.

We could mark this as CLOSED RAWHIDE, or we can leave it open and backport the fix to F20 and possibly F19. For now I'll leave it open and ask pjones what he thinks.
Comment 55 Edgar Hoch 2014-06-19 19:03:06 EDT
(In reply to Adam Williamson from comment #54)
> We could mark this as CLOSED RAWHIDE, or we can leave it open and backport
> the fix to F20 and possibly F19. For now I'll leave it open and ask pjones
> what he thinks.

I think an update to F20 and F19 would help all these users who have the line

repo --name=updates

in there kickstart file and have a working internet connection while doing kickstart installation. Then the updated grup2 package is installed instead of the release package while kickstart package installation.

I am not sure, but I think that the grub installation is done after all packages are installed, then an updated grub2 package can solve the problem for F20 and F19 too, and not only for future releases.
Comment 56 Adam Williamson 2014-06-19 19:57:06 EDT
Yeah, I believe it would take effect for fresh network installs.
Comment 57 Axel Sommerfeldt 2014-06-20 04:30:40 EDT
Please please please backport the bugfix to F20. Thanks.
Comment 58 josef radinger 2014-06-21 10:23:15 EDT
(In reply to Axel Sommerfeldt from comment #57)
> Please please please backport the bugfix to F20. Thanks.

+1
it's a shame
Comment 59 Harald Reindl 2014-06-21 10:42:31 EDT
the *real shame* is that this crap worked until Fedora 16, was broken *2 years* where all the time before set a grub-password was even a *standard option* in the installer and *then* developers are wondering why users are that angry about all the half-baken changes propsoed day for day with no benfit than damage user expierience 

DAMNED - somoe broke taht shit two years ago, the same had to fix that shit shot after *or just roll back* and *THAT* is why the linux-kernel has that much success - becauseit has the policy FIX OR REVERT IT

the fedora policy the last few years is "go ahead, who cares what breaks left and right - users - who cares about users - we developers decide what works for us"
Comment 60 Adam Williamson 2014-06-21 14:46:23 EDT
harald: given that the bug is already fixed and I just asked pjones whether he thinks we should backport it to f20..what the hell is the point of your rant?
Comment 61 Harald Reindl 2014-06-21 14:52:34 EDT
> given that the bug is already fixed

no - not for any regular Fedora user

> he thinks we should backport it to f20

may i propose to remove the version field in the Fedora Bugzilla because it annoys me over years that nobody of the maintainers cares about 

> what the hell is the point of your rant?

that this was reported *years ago* for Fedora 17 and there is still a discussion *if it* should be backported to the current stable release? there is no need for such a question, on my PC this burgreport currently shows "Version: 20"
Comment 62 Adam Williamson 2014-06-21 15:09:00 EDT
it has nothing to do with the version field on the bugzilla. i just don't want to go around throwing patches into someone else's package without their approval.
Comment 63 Harald Reindl 2014-06-21 15:13:39 EDT
that bug should have never become F20 in the version field, it was introduced two years ago with Fedora 17 and to be honest i personally gave up with bootloader-password because i have no time to drive 300 kilometers to type the password into a remote machine i maintain where lights-out-management is no topic

i only was frightened about the bugzilla notifies that this is still a topic
Comment 64 Edgar Hoch 2014-06-21 16:38:34 EDT
Ok, the past is gone, we cannot change it, lets hope that this bug will be fixed for the current Fedora releases soon.

But what can we learn for the future?

I think, the base problem is that some bugs that are important to Fedora users but the maintainers does not provide a solution for current Fedora users (or onöy with a long delay).

I don't know a solution, but there should be a process that should prevent such long unsolved bugs that are important to users in the future. Some ideas:

- Users should be able to "raise" the importance of a bug if it is not solved.
  For example, they schould be able to "vote" that the bug is still important for them, after a delay of a month or so, and repeat it after another period if it is still unsolved.

- The number of users on the cc list can also be an indication of "importance".

- The maintainers should be notified about there long unsolved bugs, ordered by importance and priority.

- Someone, or a group, should monitor about such long unsolved bugs and check whats the problem why it isn't solved. (May be, for example, its a problem of man power, or the problem is hard to solve, or it isn't really important.)


Adam, I think this is a general problem that should be discussed in the Fedora boards and discussion groups. Please would you address this problem in the appropriate discussion groups - I think you have the contacts to do it.
Comment 65 Adam Williamson 2014-06-23 20:26:23 EDT
Bugzilla has a voting mechanism. It is intentionally disabled in RHBZ (and many other bugzillas) because it's fundamentally flawed: there is no incentive for *disinterested* voting. No-one goes around reading every bug report and carefully considering how important it is in assigning their votes; everyone just votes for the bugs that affect them. It becomes more or less an exact proxy for the CC field.

We *do* keep track (though mostly informally) of bugs with large CC fields.

Most maintainers have a much larger bug load than they can handle; they'd likely find nag mails about long-unsolved issues mostly to be a nuisance and just disable them. It might be something to look at, though, and I think RHBZ admins are experimenting in this direction; RHBZ recently started sending out mails to people with very longstanding needinfo requests open against them. Note that the 'severity' and 'priority' fields in RHBZ are rarely relevant; we don't have an active triage team at present and most maintainers / maintainer groups do not set those fields for their own purposes. Most bugs have the default values, or sometimes get bumped up in a very haphazard way by reporters or CC list people who happen to have the relevant privileges. There's a policy about what they're *supposed* to mean, but no enforcement mechanism.

"Someone, or a group, should monitor about such long unsolved bugs and check whats the problem why it isn't solved."

This is kind of a triage task; it's certainly something that could possibly be done with interesting results, but I can see some problems with it too. A lot of such bugs may need considerable background to understand, for instance (hi there, https://bugzilla.redhat.com/show_bug.cgi?id=998 !)

Still, I think it's an interesting idea and something we could look at; I can't exactly say I definitely have the time to look at it myself, though. It *is* something you wouldn't particularly need anyone's permission to do. All it requires is the ability to run a Bugzilla search and type up the results. Just sayin'. ;)
Comment 66 Fedora Update System 2014-06-24 13:14:39 EDT
grub2-2.00-26.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/grub2-2.00-26.fc19
Comment 67 Fedora Update System 2014-06-24 13:18:09 EDT
grub2-2.00-26.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/grub2-2.00-26.fc20
Comment 68 Henrique Martins 2014-06-24 14:25:03 EDT
(Also posted to bohdi)
After downloading the corresponding RPMs to the ones I have installed and running:
  yum localinstall grub2-2.00-26.fc20.i686.rpm grub2-starfield-theme-2.00-26.fc20.x86_64.rpm grub2-tools-2.00-26.fc20.i686.rpm errors out with:
Transaction check error: 
file /etc/grub.d/10_linux from install of grub2-tools-1:2.00-26.fc20.i686 conflicts with file from package grub2-tools-1:2.00-25.fc20.x86_64 
file /usr/share/doc/grub2-tools/grub-dev.html from install of grub2-tools-1:2.00-26.fc20.i686 conflicts with file from package grub2-tools-1:2.00-25.fc20.x86_64
file /usr/share/doc/grub2-tools/grub.html from install of grub2-tools-1:2.00-26.fc20.i686 conflicts with file from package grub2-tools-1:2.00-25.fc20.x86_64
file /usr/share/info/grub2-dev.info.gz from install of grub2-tools-1:2.00-26.fc20.i686 conflicts with file from package grub2-tools-1:2.00-25.fc20.x86_64 
file /usr/share/info/grub2.info.gz from install of grub2-tools-1:2.00-26.fc20.i686 conflicts with file from package grub2-tools-1:2.00-25.fc20.x86_64
Comment 69 Harald Reindl 2014-06-24 14:30:35 EDT
@Henrique Martins: on multilib-installs you need to have *all* multilib installed packages in the *exactly* same version and besides that "localinstall" is wrong for a update that means you have to update "grub2-tools-1:2.00-26.fc20.i686" *and* "grub2-tools-1:2.00-26.fc20.x86_64" in one transaction - that's how multilib works all the time
Comment 70 Henrique Martins 2014-06-24 14:39:23 EDT
Sorry, screwed up.
Enablerepo=updates-testing didn't pick it up, and seems like I picked and chosed a  mixed bag.
Blame the WC game going in the background :-)
Comment 71 Harald Reindl 2014-06-24 14:44:49 EDT
on a x86_64 system you don't need the i686 packages at all, hence is why you should use "yum update *.rpm" instead of "yum localinstall" - it would tell you that there is nothing to update in case of wrong downloads and most important skip non-installed sub-packages if you downloaded un-used too
Comment 72 Fedora Update System 2014-06-25 21:57:56 EDT
grub2-2.00-26.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 73 Fedora Update System 2014-06-25 21:58:14 EDT
Package grub2-2.00-26.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing grub2-2.00-26.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7752/grub2-2.00-26.fc19
then log in and leave karma (feedback).
Comment 74 Fedora Update System 2014-07-30 17:56:33 EDT
grub2-2.00-26.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 75 Adam Williamson 2015-01-09 12:28:12 EST
*** Bug 840160 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.