As far as I know, I have never edited /etc/default/grub, and today’s pacman -Syu installed /etc/default/grub.pacnew.
Why is this, what to do, and how do we prevent pacnew files for files from Manjaro that I am not editing?
Here’s the old one, which I believe is what shipped with Manjaro:
/etc/default/grub
GRUB_DEFAULT=saved
GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=hidden
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet apparmor=1 security=apparmor resume=UUID=2d2476ca-269a-41e3-8666-153465a279e5 udev.log_priority=3"
GRUB_CMDLINE_LINUX=""
# If you want to enable the save default function, uncomment the following
# line, and set GRUB_DEFAULT to saved.
GRUB_SAVEDEFAULT=true
# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"
# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y
# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console
# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'
GRUB_GFXMODE=auto
# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep
# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true
# Uncomment and set to the desired menu colors. Used by normal and wallpaper
# modes only. Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"
# Uncomment one of them for the gfx desired, a image background or a gfxtheme
GRUB_BACKGROUND="/usr/share/grub/background.png"
#GRUB_THEME="/path/to/gfxtheme"
# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"
And here is the new one:
/etc/default/grub.pacnew
GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=hidden
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet udev.log_priority=3"
GRUB_CMDLINE_LINUX=""
# If you want to enable the save default function, uncomment the following
# line, and set GRUB_DEFAULT to saved.
GRUB_SAVEDEFAULT=true
# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"
# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y
# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console
# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'
GRUB_GFXMODE=auto
# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep
# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true
# Uncomment and set to the desired menu colors. Used by normal and wallpaper
# modes only. Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"
# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/usr/share/grub/background.png"
#GRUB_THEME="/path/to/gfxtheme"
# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"
# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically
GRUB_ROOT_FS_RO=true
Hello @Yochanan, I know what .pacnew files are, and I know how to generally handle them.
But I mentioned in the OP that I did not edit those files, and therefore there should not be .pacnew files being generated.
If Manjaro is set up correctly, then I believe an end user should never see pacnew files for files maintained by Manjaro that the user never touches.
I installed Manjaro and it created those files, and I should therefore be able to upgrade without having to manually perform Manjaro’s maintenance during the updates.
In a similar vane, then mkinitcpio also has the same issue. This is a file I should not care about: I install Manjaro, and I tell Manjaro to update. pacnew files should be of no concern unless I am manually editing things, but I am not.
I tend to fire up Meld to compare the files - it’s a chore I guess. I never feel comfortable just overwriting or ignoring, though I’ve done that before.
I think it was in May 2020, package filesystem was upgraded, and generated a .pacnew for /etc/shadow. Blindly overwrite/copy that file, and you probably have a major borking on your hands.
Going back to my original install date (4 Jul 19), I only have 24 instances of .pacnew files generated, and only 5 .pacsaves. Not really a lot of work.
See above. (Don’t blindly copy over). Use (or learn) a diff program, and merge them. You can have Manjaro defaults, with your changes as well.
As an end user, I never modified this file, and I therefore never expected to encounter a .pacnew for this file. I am aware of what to do with .pacnew files and diff programs, but I simply didn’t expect this to happen with a file that was installed for me (when I installed Manjaro) and that I did not modify. Pardon my inexperience.
I believe that this, and anything else Manjaro modified during install, is the reason this happened. I have not installed AppArmor before, so I assume Manjaro put that there (see calamares installer code).
There’s a usability issue here, which is what I was trying to point out in the first place: New users will not expect to have to modify something they never touched to begin with, and I’d say that the Manjaro installer modifying something during install does not count as it being a user modification that should require them to modify system files during system upgrades.
When someone installs Windows and chooses options during install (or chooses options after, during the welcome process), subsequent Windows updates never require the user to modify system files. I also have never experienced this with macOS or Debian/Ubuntu.
I understand this is an issue inherited from Arch Linux, but philosophically maybe there’s something that should be done about this sometime, considering that Manjaro aims to be that distro that takes something complicated and barebones and makes it (more) beginner-friendly.
Then you don’t understand how they work even after relevant links were posted explaining them. Whether or not you edit the file, if the file in the updated package has changes, it will not overwrite the existing file. It’s up to you to review it and merge the new changes.
I know (and I knew all along before anyone replied) the technical reason why pacman added a .pacnew file: pacman sees the file as modified.
It happens to be because Manjaro installer modified it.
I wasn’t here to ask about what to do with .pacnew files. I have been using plain Arch Linux for a lot longer than Manjaro so far.
This “issue” causes people (especially those without enough experience, who wish to try the “User-Friendly Arch Linux for Everyone” distro) to wonder why they need to modify system files that they didn’t willfully modify, and that they may know nothing about to begin with.
What I’m saying is that, philosophically, to be as beginner-friendly for “everyone” as possible (f.e. at least as friendly as Ubuntu or Pop_os and others), this problem needs to be solved somehow.
At the moment “Arch Linux for people who know Arch Linux, but with built-in shortcuts, configuration, and delayed package releases to ensure stability” might be more accurate.
Your topic title and posts here contradict you already knowing how everything works as you claim. Why are we here and where is this going after the post was resurrected after your long (apparently undeserved) hiatus?
I could take apart all your posts here with further replies, but I won’t.
That makes sense, could vary per system.