$ sudo grub-install
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
x86_64-efi will be installed for your platform.
installation finished. No errors occurred.
. . . .
Yes, have you seen pacsafe?
Now you understand why your method doesn't work?
Thank You so much!!
what is the legal way to change the grub-menu-entry:
-# DO NOT EDIT THIS FILE
-### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (auf /dev/sda2)'
"Windows 10 Bootloader"
Error: Command could not be executed correctly
. . . .
IMO, the right way is whichever way the user wants.
If you want to change grub.cfg, just go ahead.
If you understand that will revert whenever there's an update-grub.
I personally think there's nothing wrong in manually changing grub.cfg.
But the 'official' way is to do that through /etc/default/grub and never try to change /etc/grub.d.
Of course, when we have a bad grub.d written, like the fedora grub or by grub-customizer... your other choice is to use systemd-boot or refind. I have not heard any here use what I do do when I had been doing this since grub-legacy.
Oh in kde, it is more difficult changing grub.cfg, but sueridgepipe can tell you it is simple enough.
what is the legal way to change the grub-menu-entry:
copy the (complete) menuentry of "Wind**fs" inside /boot/grub/grub.cfg
into /etc/grub.d/40_custom. Edit / change entry as needed.
Then go to /etc/default/grub
and add the line:
That all except the grub-menu is not shown on first reboot
Then press shift on reboot to make the menu visible again...
So it is code related. Therefore I've to see what upstream changed. However I'll provide 2.03.4 in a new packaging to rule issues with the new way out.
grub 2.03.4 - the last working version -
the locale for the grub-menu is NOT generated by, for example, /boot/grub/locale/de.mo
BUT by the system-language, for example german or english.
The language of the grub-menu will only change after "sudo update-grub" !!!!!!!!!!!!!!!!!!
(for example, IF NOT EXISTS the directory /boot/grub/locale, and the system-language is "german",
grub-menu is in german - if system-language is "english", then grub-menu is in english).
Not correct. I'm busy at the moment, will reply in an hours time. Had been busy the last one week . wanted to stay out for longer, but here you are..
Please don't, it's no longer available in AUR. I'm using it for years and it works well. I just applied some theme and update entries, sometimes changing default settings and thus far there is no bigger issues with that, Maybe grub-customizer should be discouraged, but it doesn't seem to create any real problems. I don't recall technical issues topic here that would point to grub-customizer as the source of the problem.
I already assumed that in my previous comment. I rather expected to have the answer as to why we need a patched grub - in layman terms. Commits in git tell me nothing.
The correct key is 'esc'.
'shift' and 'F8' is fedora added and may not work with many motherboards and if not working will result in another useless grub_env variable that makes the user wait 1 minute (or 2?) the next reboot. 'esc' will always work and is the 'grub' key to use whatever OS grub versions in use.
And (as said above somewhere) .. we can use
so that we do not need to press any key to see the menu.
Also... even if we want to hide the menu (and press 'esc' to see it)
we should use
In other words, in this fedora grub that we adopted
it is preferable it is there.
In other non-fedora grubs, without this line, the default is 'menu'.
There are many other 'default' settings if not specified in (upstream) grub to keep things simple.
If you have language modules in locale directory (/boot/grub/locale) and they should be there.
And if grub-customizer is not in play (many uninstalled but still in play)
And if OS modified grub do not mess up workings of /etc/grub.d (I have not check if this fedora grub mess up the language but it shouldn't - this fedora grub developer is showing off his coding skills making unnecessary twists and turns)
insmod gettext LANG=zh_CN or LANG=de_DE
will make grub use the correct language.
grub does not and can not use OS system settings.
It is (in a way) independent of the OS (and that is why we can use any other OS grub or upstream).
Re: grub-customizer (not specifically to GaVenga)
As said many times, we (should I say 'I'?) don't care what the user wants to use or not to use. The trouble is coming here to complain something (else) broke when what he (he, alright! don't care) did something else to the thing he broke.
And furthermore, the people clamouring for the things that break do not (or can not?) help the person having trouble with it. Is it not the people who help thinks the damage done can be reversed by the actual things breaking it?
Right, I'm still tied up some where (doing world domination, heh heh heh.. not rescuing the world from itself) and I shall be sparce. See you around.
So the language for GRUB depends from /etc/default/locale?
(grub2.03.4 language works even without /boot/grub/locale/de.mo)
OK, in general grub has still locales. However I never got them to german for the menu. Description is fine, also with latest grub 2.03.6 release. This is what I did to get german locales for the menu description:
phil@development /var/cache/manjaro-tools/pkg/unstable/x86_64 $ sudo grep lang /boot/grub/grub.cfg set lang=en_US phil@development /var/cache/manjaro-tools/pkg/unstable/x86_64 $ sudo LANG=de_DE update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.2-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.2-x86_64.img Found initrd fallback image: /boot/initramfs-5.2-x86_64-fallback.img Found linux image: /boot/vmlinuz-5.1-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.1-x86_64.img Found initrd fallback image: /boot/initramfs-5.1-x86_64-fallback.img Found linux image: /boot/vmlinuz-5.0-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.0-x86_64.img Found initrd fallback image: /boot/initramfs-5.0-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.20-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.20-x86_64.img Found initrd fallback image: /boot/initramfs-4.20-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.19-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.19-x86_64.img Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.18-rt-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.18-rt-x86_64.img Found initrd fallback image: /boot/initramfs-4.18-rt-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.16-rt-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.16-rt-x86_64.img Found initrd fallback image: /boot/initramfs-4.16-rt-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.14-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.14-x86_64.img Found initrd fallback image: /boot/initramfs-4.14-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.14-rt-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.14-rt-x86_64.img Found initrd fallback image: /boot/initramfs-4.14-rt-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.9-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.9-x86_64.img Found initrd fallback image: /boot/initramfs-4.9-x86_64-fallback.img Found linux image: /boot/vmlinuz-4.4-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-4.4-x86_64.img Found initrd fallback image: /boot/initramfs-4.4-x86_64-fallback.img Found linux image: /boot/vmlinuz-3.18-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-3.18-x86_64.img Found initrd fallback image: /boot/initramfs-3.18-x86_64-fallback.img Found linux image: /boot/vmlinuz-3.16-x86_64 Found initrd image: /boot/amd-ucode.img /boot/initramfs-3.16-x86_64.img Found initrd fallback image: /boot/initramfs-3.16-x86_64-fallback.img Found Manjaro Linux (18.0-alpha-1) on /dev/sda5 Found memtest86+ image: /boot/memtest86+/memtest.bin done phil@development /var/cache/manjaro-tools/pkg/unstable/x86_64 $ sudo grep lang /boot/grub/grub.cfg set lang=de_DE sudo grub-emu
This results in the following:
I can still try to compile some grub packages. What changed in grub lately was the update of gnulib. However, my menu entries stayed in English also with 2.03.4 version of grub. I don't use grub-customizer at all.
So @GaVenga, if you want I can compile some grub packages for you to test out. grub-emu I've to include in those packages to test them easier.
I managed to get a full german grub-menu with following script and latest grub 2.03.6 package. I called it update-grub-de:
#! /bin/sh LANG=de_DE grub-mkconfig -o /boot/grub/grub.cfg sed -i -e 's|Advanced options for|Erweiterte Optionen für|g' /boot/grub/grub.cfg
Here's my proof. Believe me, it is in Chinese.
Nothing unusual I have to do. just set lang=zh_CN and insmod gettext.
@gohlip: with 2.03.6 we have grub-emu. So you can simply fire up a terminal and experiment via
sudo grub-emu. What @GaVenga might miss is the in German translated menu entries of grub.cfg. Are these automatically in Chinese on your end or still in English?
This is from the 'real' grub, not grub-emu. And like in many other languages, many 'words' are not in Chinese, but in English, like above...'emacs', 'Ctl-x', 'Tab', 'GNU GRUB'.... I've also in the past used other languages as some users reported they could not see their languages... in Spanish, I think.. but they all work for me.
BTW, last I used grub-emu, many functions do not work. Don't know now but this is the real deal.
@gohlip: I only ment if you have still Advanced options for in your grub.cfg file after updating your grub menu? That grub is using Chinese itself is clear to me. Only the entries in the menu get written during creation via update-grub.
Oh... I see. Let me come back to you.