# Disable generating menu entries for other EFI boot manager entries detected
GRUB_DISABLE_BOOTNEXT=true
# Skip EFI boot manager entries that are marked inactive
# when when generating bootnext entries
GRUB_BOOTNEXT_OMIT_INACTIVE=true
I am very sceptical for this way of communication to the user for GRUB especially. There are thousand ways of how /etc/default/grub should be configurated - depending on how the system is set up - and consequently a pacnew for grub is confusing average user as they not necessarily following all graduate changes.
Please note, I’m not talking about other pacnew files, only about grub.
Since grub is Manjaro packaged, could the pacnew file contain new in the comments such as:
#New with 2:2.16-4
#Disable generating menu entries for other EFI boot manager entries detected
GRUB_DISABLE_BOOTNEXT=true
The official grub documentation should cover that, but it isn’t for the latest updates…
EDIT 2 days later: I dared to suggest that there is an oppertunity for improvement. A TINY oppertunity, oppertunities to make Manjaro better.
Breath taking suggestions to use manjaro-pacnew-checker instead… To prove that I’m wrong with my suggestion (with a simple suggestion…).
At the end it is just a simple question of how its mindset is set: constructive or destructive (I believe every individual claims to be constructive)
If it were that simple, such a resolution would already be in place. User configuration files are typically not overwritten during an update – and rightly not, because doing so would replace user configuration with defaults and not a user’s preferences.
.pacnew files are a viable method of delivery for recommended defaults as they change periodically – the caveat being that users must become more aware of their configurations in order to understand which portions of a .pacnew to merge or replace in their existing system counterparts.
It is by necessity a learning curve for some, but nonetheless required to avoid users blindly merging/replacing an entire configuration file.
There already exist frequent references to handling .pacnew files throughout the forum, along with howto’s and the wiki article, plus a large number of guides and walk-throughs available on the wider Internet.
In every update Announcement thread they are referenced as well – beyond these, I’m uncertain what other forms of communication to the user might be more effective.
I have given ONE simple example on how to improve. Please read.
It is important to see that there is room for improvement around grub. As long as Arch adopts versions of release candidate (of grub), that might not be easy though. Example was a while ago the 2.12rc or so where the changes messed up all systems with luks encryption.
As for adding the word “new” in the comments in a pacnew, it doesn’t make much sense. If the user tends to his pacnews as per many tutorials in the forum, when he opens the file in meld the new parts will be marked bright green or blue anyways.
Generally on braking changes we do include them in the announcement (as it is the case with mkinit). Those are not breaking changes in this particular case. Grub will work if it doesn’t see those in config, just with the new defaults.
But the real problem is to motivate the users to check the pacnews. It is massively overlooked although even a popup notifier was made (at that place i wonder if it is automatically included in the new isos?).
To add one more observation: On my system (installed a couple years ago) there were so many changes made to grub config (because of upstream changes) that a diff program is no longer usefull. All in very different order.
But your current post is not about encryption but about boot entries menu.
I struggle to get what you mean.
It is the very essence of a rolling release distro. And if you have merged the changes regularly there werent be a mess. That is why pacnews have to be acted upon in due time, not after 5 years.
I do not see how this is an improvement. Anyone using pacdiff, meld or kcompare to merge .pacnew files would be able to see new features.
If the package maintainer added #New with 2:2.16-4 to conky configuration, it would need to be removed with another .pacnew in the near future.
Failure to merge GRUB_DISABLE_BOOTNEXT and GRUB_BOOTNEXT_OMIT_INACTIVE is not as critical as failure to merge changes in GRUB_CMDLINE_LINUX_DEFAULT.
If BOOTNEXT options are not merged, user may have more entries in GRUB boot menu, but it would still be possible to boot Manjaro or another installed OS normally.
But if GRUB_CMDLINE_LINUX_DEFAULT was not updated correctly, system may not be able to boot Manjaro and chroot may be needed to correct grub configuration
Communication can be very difficult - and you being a non-native speaker.
Pacnew is not a communication channel that anyone chooses; it is what pacman does automatically when a package ships an updated version of a file, and it’s up to you to review to check if it’ll wipe out any edits you’ve made.
The ‘What’s new’ markers are already there, in the diff.
A comment such as #New with 2:2.16-4 would duplicate information the diff already carries, and it would need editing at every version bump. That annotation then becomes its own source of stale or wrong comments, and each edit regenerates another pacnew, which is the problem you started with.
What you must do is to read the diff, and merge only the lines that apply to your setup.
Announcements are things that are made in the package changelog and in the forum announcement thread, not in the shipped file…
Overall, this is one reason we frequently ask users if Manjaro is really for them. It’s an Arch based system, and despite what PewDiePie thinks, it is not suitable for folks who lack the ability to work things out for themselves - though in many ways it’s easier than Arch, in some ways it isn’t.
What was meant is that IF your Grub config file is totally different from the Pacnew, it’s on you, the user, who did not attend to his pacnews on every update and now has a mess of a config file compared to the pacnew. No effense here, just facts. I see your point in trying to improve things but I don’t believe what you ask for improves anything, if you keep your system up to date, and follow pacnew files changes, and/or read the announcement and update threads regularly.
Exactly. It was assumption, pardon me if incorrect. But since there are currently only 2 or 3 changes in the last update, the statement that the pacdiff is sooo different that nothing helps tells me you don’t have the previous latest version and i suppose you are many versions behind. Then yes, it can be unrecognizable if you compare it with a version from like 5 years ago.
It is indeed. It looks messy when you look, but how many people look. I know my partner doesn’t, as a rule, not until I tell her to select a different kernel.
As it is I get the honour of updating her pacnews.
I’m late to the conversation because time difference, but I feel OP’s main issue is one of documentation and of knowing how to access it. Marking entries in configuration files with version numbers doesn’t really accomplish anything, what you really want to know is how to configure the version you have now. And this is exactly why grub (and most other packages) install documentation along with their other files.
The answer is in the documentation installed with grub. All the configuration file options can be found on your machine via the GNU documentation system texinfo. From the terminal use the command info grub from a terminal. For the configuration options in /etc/default/grub see the section “Configuration” then “Simple configuration”.
EDIT: If the info interface isn’t to your liking and you have KDE Plasma installed, Plasma’s HelpCenter includes the info topics also. You can find them under Contents/Browse Info Pages.
And for that matter, it’s the factory default — i.e. as it comes from the developers upstream.
It is distribution-agnostic, and even operating-system-agnostic, because the grub developers believe that grub is the single-most important piece of software on your computer. I kid you not.
Indeed. There is no update to the grub documentation yet, not even at gnu.org, where grub is developed.
It does have to be said that this is uncharacteristic for the GNU people, though. Usually their documentation is up-to-date and, um, rather elaborate.
New (short version) in 2.16:
* New efibootnext module and 31_efi_bootnext script for one-shot boot entries.
New (long version) in 2.16:
* New/improved platform support:
* New `efibootnext' module and 31_efi_bootnext script for one-shot boot
entries, keyed off the ESP PARTUUID and vendor directory. (3d0a81dc0,
6b8d690e3, 53b7b754b, ba20519fc, 9cc5ebba6, 69a08ed5f)
If set to ‘true’, grub-mkconfig will not generate bootnext menu entries for other EFI boot manager entries detected via efibootmgr. This disables the entire 31_efi_bootnext script.
‘GRUB_BOOTNEXT_OMIT_INACTIVE’
If set to ‘true’, grub-mkconfig will skip EFI boot manager entries that are marked inactive (i.e. not flagged active with ‘*’ in efibootmgr output) when generating bootnext menu entries. By default inactive entries are included, since ‘BootNext’ can target them even when they are absent from ‘BootOrder’.
I may have missed something, but what exactly is missing?
From the info grub documentation installed with the current grub package ( grub 2:2.16-4):
‘GRUB_DISABLE_BOOTNEXT’
If set to ‘true’, ‘grub-mkconfig’ will not generate ‘bootnext’ menu
entries for other EFI boot manager entries detected via
‘efibootmgr’. This disables the entire ‘31_efi_bootnext’ script.
‘GRUB_BOOTNEXT_OMIT_INACTIVE’
If set to ‘true’, ‘grub-mkconfig’ will skip EFI boot manager
entries that are marked inactive (i.e. not flagged active with ‘*’
in ‘efibootmgr’ output) when generating ‘bootnext’ menu entries.
By default inactive entries are included, since ‘BootNext’ can
target them even when they are absent from ‘BootOrder’.
Frap, you’re right, I forgot about the GNU info pages. But this must be a very recent addition then, because the documentation had certainly not been updated yet by the time grub 2.16 hit the Testing branch.
I noticed “updated October 30”, or similar – one supposes that updating the documentation may have been low on somebody’s to-do list, however, it invariably does get done.
As it’s likely others searching for information about pacnew files and how they are handled, will find this thread, passers-by please find below several links that may be useful;