My system isn't quite right after "dealing" with .pacnew files

General system Newbie
1

Hey folks.

I’ve been running using EndeavourOS on my laptop for over four years, the same installation this whole time, and it’s been running great.

This morning, I decided that I was going to free up some disk space, and because I always forget the terminal commands, I went back to this handy guide on the forum:

While reading through that guide, I realized that in 4+ years, I’ve never done anything with pacnew files. I occasionally see them being creating when updating my system, but never gave it any thought or attention. Well, after reading (a little) more about pacnew file, I thought I should get my system up to date. I used the “pacdiff & diff” part of the EOS Welcome application, and it found 8 or 10 pacnew files. I didn’t recall changing any of the files, so I thought it would be OK to overwrite the old files with the pacnew files.

which now brings me here. Although I’ve been using EOS for 4+ years, I definitely feel like a newbie today.

There are two primary issues that I’ve noticed so far, plus a 3rd question:

1. GRUB issue

One of the pacnew files was related to GRUB. I remember the unbootable grub update from a couple years ago, so I figured that I would update the GRUB config file before rebooting. I ran these two:
sudo grub-install --no-nvram
sudo grub-mkconfig -o /boot/grub/grub.cfg

My system boots up fine, but when I’m in GRUB, I see that I no longer have a choice for Linux-LTS. just the “Regular” linux kernel. While I typical use the “regular” kernel, I like having the option for boot into the LTS should the need arise. How can I fix the GRUB settings to give me the option to boot into the regular kernel or the LTS kernel? And, despite GRUB not showing the LTS option, when I look, I see that I’m currently running the LTS kernel (specifically 6.12.19-1-lts), so it looks like I need to figure out how to restore the previous GRUB settings, to allow me to boot into either the “regular” linux kernel (currently 6.13.7-arch1-1), or the LTS kernel, and default to boot into the regular kernel.

I currently have both kernels installed (6.13.7-arch1-1 and 6.12.19-1-lts).

2. EndeavourOS repository

When running a system update, it looks like I no longer have the EndeavourOS repository.

[jason@xps139310 ~]$ yay -Syu
[sudo] password for jason: 
:: Synchronizing package databases...
 core is up to date
 extra is up to date
:: Searching AUR for updates...
:: Searching databases for updates...
 -> yad: local (14.1-2.1) is newer than extra (14.1-2)
 -> Packages not in AUR: akm  endeavouros-branding  endeavouros-keyring  endeavouros-mirrorlist  eos-bash-shared  eos-hooks  eos-log-tool  eos-qogir-icons  eos-quickstart  eos-translations  eos-update-notifier  keyserver-rank  lib32-audit  lib32-brotli  lib32-bzip2  lib32-e2fsprogs  lib32-freetype2  lib32-glib2  lib32-harfbuzz  lib32-keyutils  lib32-krb5  lib32-libcap  lib32-libffi  lib32-libgcrypt  lib32-libgpg-error  lib32-libldap  lib32-libnsl  lib32-libpng  lib32-libtirpc  lib32-libxcrypt  lib32-openssl  lib32-pam  lib32-pcre2  lib32-systemd  lib32-util-linux  lib32-xz  lib32-zlib  lib32-zstd  welcome
 -> reflector-simple: local (2024.8.1-1) is newer than AUR (3.3-1)
 there is nothing to do

What’s the best way to get that back?

3. is there an easy way to check which files I updated when “dealt” with the pacnew files? Is it possible that I’ve messed up something else with my system, and just haven’t noticed yet?

2

Concerning problem 2 : you probably overwrote pacman.conf with pacman.conf.pacnew.
You can find a sulotion to this problem below.

3

Thank you for linking me to that thread! I’ve updated my pacman.conf file with the EndeavourOS default, and that worked for problem #2.

4

There is a reason why pacman installs a .pacnew config file for a package.

If the version of the file currently in the filesystem has been modified from the version originally installed by the package, pacman cannot know how to merge those changes with the new version of the file. Therefore, instead of overwriting the modified file when upgrading, pacman saves the new version with a .pacnew extension and leaves the modified version untouched.

The user should therefore always compare the content of the two files. Sometimes it is only needed to merge them and add a few new configurations if they are relevant. Sometimes there is no need at all. Just overwriting them without reviewing is not a good decision.

1 Like
5

Err yes, my sarcastic side (not sure if I have a non-sarcastic side) wants to say the OP didn’t ‘deal’ with the pacnews at all.

2 Likes
6

cactux, thank you for chiming in.

I realize that now, and hence this post asking for help.

The reason that I thought it would be OK is the part in bold here:

I didn’t recall modifying the version originally installed by the package, and therefore I thought I’d be OK with using the pacnew files. But I guess I was wrong.

7

Actually, the more required updates to the conf files are due to version/syntax changes, best practices, and the like. The arch philosophy is not to overwrite your files (modified or not), because many things just require the human touch to interpret and configure correctly.

So..this goes in the typical Arch direction, research, maintenance, and thought required. Some people may throw up their hands in horror, but it’s really the only way to understand your system (active involvement) (imo).

I personally run a diff, and may or may not read the entire file(s) original and pacnew to decide what I need to do. Sometimes spot research is required, because if I don’t understand it, how can I make the right choices.

8

Most probably you didn’t modify them but sometimes the OS you are using ships with own set of configurations when you install the system. In this case, for example pacman.conf for EndeavourOS. Then later when the package pacman is updated, it will install the “default” pacman.conf for the package in form of pacman.conf.pacnew. The existence of .pacnew should alert you that something is different between your current config and the new one.

Here is some more explanation from man pacman

HANDLING CONFIG FILES
Pacman uses the same logic as rpm to determine action against files that are designated to be backed up. During an upgrade, three MD5 hashes are used for each backup file to determine the required action: one for the original file
installed, one for the new file that is about to be installed, and one for the actual file existing on the file system. After comparing these three hashes, the following scenarios can result:

   original=X, current=X, new=X
       All three files are the same, so overwrites are not an issue. Install the new file.

   original=X, current=X, new=Y
       The current file is the same as the original, but the new one differs. Since the user did not ever modify the file, and the new one may contain improvements or bug fixes, install the new file.

   original=X, current=Y, new=X
       Both package versions contain the exact same file, but the one on the file system has been modified. Leave the current file in place.

   original=X, current=Y, new=Y
       The new file is identical to the current file. Install the new file.

   original=X, current=Y, new=Z
       All three files are different, so install the new file with a .pacnew extension and warn the user. The user must then manually merge any necessary changes into the original file.

   original=NULL, current=Y, new=Z
       The package was not previously installed, and the file already exists on the file system. Install the new file with a .pacnew extension and warn the user. The user must then manually merge any necessary changes into the
       original file.
9

pacman -Q | grep -E "dracut|mkinitcpio|grub|linux"

What is the output?

cat /etc/default/grub | eos-sendlog
cat /boot/grub/grub.cfg | eos-sendlog

Post the urls.

10

no need to invoke cat you can just redirect to eos-sendlog

eos-sendlog < /etc/default/grub

will do the same thing.

1 Like
11

cactux - thanks again for your help.

Here is the info on my system:

[jason@xps139310 ~]$ pacman -Q | grep -E "dracut|mkinitcpio|grub|linux"
archlinux-keyring 20250123-1
grub 2:2.12.r226.g56ccc5ed-1
lib32-util-linux 2.40.4-1
linux 6.13.7.arch1-1
linux-api-headers 6.13-1
linux-atm 2.5.2-9
linux-firmware 20250311.b69d4b74-2
linux-firmware-whence 20250311.b69d4b74-2
linux-headers 6.13.7.arch1-1
linux-lts 6.12.19-1
linux-lts-headers 6.12.19-1
mkinitcpio 39.2-3
mkinitcpio-busybox 1.36.1-1
mkinitcpio-nfs-utils 0.3-8
mkinitcpio-openswap 0.1.0-3
util-linux 2.40.4-1
util-linux-libs 2.40.4-1

https://0x0.st/oRV2.txt

https://0x0.st/8QFG.txt

12 
menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-578f62aa-8011-404c-b94f-3fb929a755ef' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_gpt
		insmod ext2
		search --no-floppy --fs-uuid --set=root 578f62aa-8011-404c-b94f-3fb929a755ef
		echo	'Loading Linux linux ...'
		linux	/boot/vmlinuz-linux root=UUID=578f62aa-8011-404c-b94f-3fb929a755ef rw  loglevel=3 quiet
		echo	'Loading initial ramdisk ...'
		initrd	/boot/intel-ucode.img /boot/initramfs-linux.img
	}
	menuentry 'Arch Linux, with Linux linux (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-578f62aa-8011-404c-b94f-3fb929a755ef' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_gpt
		insmod ext2
		search --no-floppy --fs-uuid --set=root 578f62aa-8011-404c-b94f-3fb929a755ef
		echo	'Loading Linux linux ...'
		linux	/boot/vmlinuz-linux root=UUID=578f62aa-8011-404c-b94f-3fb929a755ef rw  loglevel=3 quiet
		echo	'Loading initial ramdisk ...'
		initrd	/boot/intel-ucode.img /boot/initramfs-linux-fallback.img
	}

These are Grub’s menu entries for your linux 6.13.7.arch1-1 kernel. You should be able to see them in Grub’s menu under Advanced options.

Restart your computer and in Grub’s menu look under Advanced option, see if you have the menu entry for the latest Linux kernel. Try to boot from it.

Also about /etc/default/grub, I don’t know which changes to this file comes with EndeavourOS. What you have is the default file from Archlinux. If you want to have what is default for EndeavourOS, someone else could maybe provide it. I don’t know where to look for.

13

After a quite recent change eos-pacdiff by default creates a backup of each file into folder
/etc/.EOS_BACKUPDIR
You can find the previous versions of files there.

Looks like file /etc/pacman.conf (from Arch!) was merged over the EndeavourOS version, that’s why the EndeavourOS packages on your system are newer than the unofficial AUR versions.

And, as you have noticed, blindly merging .pacnew files can cause issues. Some issues might be really bad, like unable to login.

1 Like
14

Yes, when I reboot, under the advanced options. I do see the entry for linux 6.13.7.arch1-1 kernel. It boots fine, and now I’m booted back up running 6.13.7.arch1-1

Thank you!

For reference, here is a list of the files in the .EOS_BACKUPDIR

canon_lide70.conf.20250318-081701
locale.gen.20250318-081701
default.xml.20250318-081701
main.conf.20250318-081701
rust.conf.20250318-081701
escl.conf.20250318-081701
mirrorlist.20250318-081701
shells.20250318-081701
grub.20250318-081701
mkinitcpio.conf.20250318-081701
issue.20250318-081701
pacman.conf.20250318-081701

the pacman.conf I’ve already addressed, based on the first reply to this thread from keescase. I just replaced the Arch default pacman.conf with the EOS default pacman.conf, so that’s all set.

for GRUB

Should I just replace the “/etc/default/grub” file with the “grub.20250318-081701” file from the .EOS_BACKUPDIR ?

I think that I should, but would like to get confirmation on all the steps here, so I don’t mess up anything more. And after copying that back-up file to /etc/default/grub, I assume that I should re-run:

sudo grub-install --no-nvram
sudo grub-mkconfig -o /boot/grub/grub.cfg

Is that right? Is there anything else that I should be doing?

And are any of the other files that I updated this morning (as listed from .EOS_BACKUPDIR) be restored? Problematic if I keep the new files?

thanks again!

in that regard, I guess I lucked out in that my system is still bootable and I can login.

15

Probably yes since it seems that the backup version was working OK.
But be sure to compare those files about the differences before replacing, e.g.

sudo meld /etc/default/grub /etc/.EOS_BACKUPDIR/grub.20250318-081701

Note that you can merge the interesting parts with that command.

1 Like
16

This should work. You need to rename it back to just grub. Post its contents if you want so we can look at if you are hesitant.

2 Likes
17

The linux-lts issue could be resolved by proper settings in /etc/default/grub, and/or making sure os-prober is installed.

18

Good to know that os-prober also is looking for kernels, because I was going to suggest that, but I wasn’t sure it would work. Anyway I think just uncommenting (remove the #)

GRUB_DISABLE_OS_PROBER=false

In the grub file should do the trick.

1 Like
19

@hoosfoos I checked already the grub.pacnew file. It is a vanilla config for a vanilla Arch. No new configuration options needing to be merged. You can restore your “old” /etc/default/grub and run

The other command is not needed.

1 Like
20

This is really not needed for Grub to find the kernel images under /boot.
os-prober is a “Utility to detect other OSes on a set of drives”. In this case no need for that.

If OP wants to set a default kernel other than LTS, it can be done with:
GRUB_TOP_LEVEL=

1 Like