A nice improvement could be a new parameter for /etc/default/grub :
GRUB_LABELS_STRING=""
(If not specified or empty, update-grub or scripts behaviour should be
as today)
This new parameter should support some variables in it:
"${FS_LABEL} ${OS_NAME} (${KERN_NAME} ${KERN_VER}) - ${PARTITION}"
El 10/02/18 a les 06:55, Jordan Uggla ha escrit:
> There are multiple ways to approach this problem, and my personal
> preference for your case would be to disable os-prober and write
> custom menuentries manually. These menuentries would then use
> configfile to load the grub.cfg from your other OSs, rather than
> having your custom menuentries include commands that directly load a
> kernel. This way, your menus always stay up to date, and you can make
> the titles whatever makes the most sense to you.
>
> For some details, to disable os-prober in the OS that's controlling
> the grub menu add GRUB_DISABLE_OS_PROBER=true to /etc/default/grub and
> re-run grub-mkconfig to generate a new grub.cfg. You'll probably also
> want to make a reasonable name for GRUB_DISTRIBUTOR to know which
> installation the menuentries from the controlling OS will boot.
>
> To add custom entries, create a new file /boot/grub/custom.cfg (*not*
> grub.cfg) to store your entries. I prefer this to editing
> /etc/grub.d/40_custom because you can make changes without having to
> re-run grub-mkconfig and because I generally think that users
> shouldn't touch anything in /etc/grub.d/ .
>
> Two menuentry examples would be:
>
> menuentry "Debian Stretch, the Foobar one" {
> search --set=root --fs-uuid UUID_HERE
> configfile /boot/grub/grub.cfg
> }
>
> menuentry "Debian Stretch, but with more baz" {
> search --set=root --fs-uuid BAZ_UUID_HERE
> configfile /boot/grub/grub.cfg
> }
>
>
> Another solution would be to modify the scripts in /etc/grub.d/ to use
> labels in generated menuentries. I would not recommend this because
> whenever an improvement to these scripts is made, your new changes
> will need to be merged with the new grub.d scripts, including hassle
> from your package manager when the upgrade happens (even if the merge
> would be trivial). You might also get good results by just changing
> GRUB_DISTRIBUTOR in each distro's /etc/default/grub . I am writing
> this email quickly so I haven't checked if that would solve your
> problem.
>
>
> If I have some time tomorrow I'll also post a snippet that you could
> add to your custom.cfg that will check at boot for all
> /boot/grub/grub.cfg files on all volumes and generate menuentries for
> them where the menuentry title contains the filesystem's label.
>
___
Help-grub mailing list
Help-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/help-grub
