| Summary: | sys-boot/grub-2.00_beta5 asks for password on unrestricted menuentries | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c> |
| Component: | [OLD] Core system | Assignee: | Mike Gilbert <floppym> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | base-system, martin |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | 40_custom | ||
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. |
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.