Created attachment 311593 [details] 40_custom Hi, since I upgraded from gub-2.00_beta3 to beta5 I cannot boot any menuentry without getting asked for a password. I've set up a superuser and password so people cannot mess with the menuentries themselves but none of the menuentries are restricted (no --user option is given) so users can boot the menuentries as they wish. This worked flawlessly with grub-2.00_beta3 but not anymore with beta5. I'm only using /etc/grub.d/40_custom file to generate the grub config file, which I've attached here.
I can confirm that. I am nor generating grub.cfg at all, and the same grub.cfg which was working with earlier grub-betas now requires a password for every entry, not only for the protected ones.
Alright this seems to be an intentional change done by upstream: # bzgrep -A 2 "Default to restricted" /usr/share/doc/grub-2.00_beta5/ChangeLog.bz2 * grub-core/commands/legacycfg.c (legacy_file): Default to restricted entries. * grub-core/commands/menuentry.c (grub_cmd_menuentry): Likewise. So adding "--unrestricted" to the menuentries is fixing the issue. Mike, how about adding some kind of elog message to >=grub-2.00_beta5 reflecting this change?
I understand that this was probably a bit frustrating. However, I have a feeling that a small number people use this feature, so an elog message would just be noise that may actually confuse some users. Can you provide a way to identify whether a user is actually affected by this change?
Now that I know that it is not a bug but an interface change, I suggest to close it as INVALID: Users of beta software have to expect such changes, and new users will not be affected. In fact, the --unrestricted example is now given on the info page. (BTW: In emacs info, most automatically generated entries want to load a nonexistent grub info file instead of the valid grub2 info file, so I guess something wrong with the info DIR generation yet? But this is almost not worth to open a new bug...). Anyway: (In reply to comment #3) > Can you provide a way to identify whether a user is actually affected by > this change? Probably most reliable is something like grep -q superusers /boot/grub2/grub.cfg /etc/grub.d/* && ewarn ...
(In reply to comment #4) > (BTW: In emacs info, most automatically generated entries want to > load a nonexistent grub info file instead of the valid grub2 info file, > so I guess something wrong with the info DIR generation yet? But this is > almost not worth to open a new bug...). I don't use emacs, so I have no way to test this. Can the issue be reproduced using the normal info command? There is a sed call in grub-1.99-r2.ebuild that looks like it may have resolved this; however, I think this broke the install target in the build system so I removed it. Please file a separate bug and preferably provide a patch if you would like this to be fixed.
