With a new ISO install shouldn't an exact copy of /etc/pacman.conf be found at gitlab.manjaro.org?

I installed a system with the ISO manjaro-xfce-21.1.3-210916-linux513.

When I looked at pacman.conf, I see:

SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

I did an update.

When I looked at pacman.conf, I see the same thing:

SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

When I went to pacman.conf at git I see:

Include = /etc/pacman.d/mirrorlist

If I have the correct git file and there was a change to the configuration file, shouldn’t there be a .pacnew file?
Can anyone shed some light on the differences between the git file and the file installed (either original and/or update), much appreciated. I concentrated on the SigLevel option.

This entry got me reviewing files.

Because the PackageRequired part is implemented globally, it is unnecessary to implement it for each repository.

I am more interested in why pacman.conf on my system is different than the one in git, and why no .pacnew. I tried to look through the commits to find when it changed, but so far I have been unsuccessful. :frowning:

Maybe the git master contains changes that aren’t yet part of pacman’s stable version.

If you don’t make changes to the default config, pacman does not generate a pacnew file.

==Test 1: My Current System which was initiated from ISO 21.1.3 ==

I did the following steps:

mkdir temp && cd temp
cp  /var/cahce/pacman/pkg/pacman-6.0.1-2-x86_64.pkg.tar.zst .
tar -xf pacman-6.0.1-2-x86_64.pkg.tar.zst etc/pacman.conf
less etc/pacman.conf

And pacman.conf does not contain SigLevel; Same as git.

== Test 2: Install ISO and all updates System ==

However, the ISO I installed from (lsb_release -a: 21.1.3 Pahvo; media: manjaro-xfce-21.1.3-210916-linux513) has a pacman.conf with SigLevel and no update produced a.pacnew. I expected to see a .pacnew somewhere along the lines.

I don’t want SigLevel to confuse the issue, I’m just using it as indicator that the config file changed. I’m more concerned why a changed config file didn’t produce a .pacnew file. I did make changes to the installed pacman.conf (i.e., NoExtract, VerbosePkgLists, etc). This is a simple case with no repercussions. I’m using it as a safe learning experience. I’d like to have a more reliable, long-term way of finding out about changes other than a happy accident in this forum :slight_smile: The .pacnew is one reliable, consistent way, or at least I thought it was.

I thought it might be the version of pacman, but the ISO contains 6.0.1-1, and with the most current maintenance 6.0.1-2.

It is my understanding from archwiki that when an update contains a change to a configuration file that has been modified, a .pacnew file will be created so the user can view the changes. I don’t know how that happens under the covers — is it an automated or manual process.

When I look at git, all I see is pacman.conf in the Master Branch. Does every ISO and/or update have it’s own Branch or Tag, so users can follow the changes? HHHHMmmm… :thinking:

as Benjamin said: that occurs only if

@stargazer , you can edit any package file with config, and then check

pacman -Qkk your_package_name

My example:

~/Desktop ❯ pacman -Qkk pacman
backup file: pacman: /etc/makepkg.conf (Modification time mismatch)
backup file: pacman: /etc/pacman.conf (Modification time mismatch)
backup file: pacman: /etc/pacman.conf (Size mismatch)
backup file: pacman: /etc/pacman.conf (MD5 checksum mismatch)
backup file: pacman: /etc/pacman.conf (SHA256 checksum mismatch)
pacman: 431 total files, 0 altered files
~/Desktop ❯ 

So pacman checks if the file was modified after installation and if was, new config from updating package creates new one .pacnew config file.
AFAIK, if config file was not changed by user, it updates by replacing old one with newer one silently withou user interaction request: it is nothing to merge: was default package config and became default package config - like you just installed new OS copy with that new package already built-in in that hypothetical ISO image.

Any question remains?

pacman -Qkk produced the same output as yours.

I made changes months ago to pacman.conf. Prior to changing the file, I copied it to pacman.conf.install, so I maintain the original file.

I expect to see a .pacnew if there are changes to the file from Manjaro. Comparing my pacman.conf and pacman.conf.install to git, I believe there should have been a .pacnew (unless I’m at the wrong git location).


I read a topic that got me looking at things (some times I see if I know the answer to topics without answering to learn and verify what I think I know with the goal of alleviating future problems :slight_smile: and sharing solutions). During this process, when I viewed the pacman package on git , I noticed specific options were different from my pacman.conf and even pacman.conf.install. I’m scratching my head :thinking:, but I never received a .pacnew.

@alven how does your pacman.conf compare to the git pacman.conf?


===> grep -i pacnew /var/log/pacman.log

===> stat / | grep -i birth

===> grep " pacman (" pacman.log


I tried to find the git commit that removed the 4 lines containing “SigLevel = PackageRequired”, but was not successful.

If I missed the pacman.conf.pacnew, what other pacnews have I missed or will miss in the future that might cause a problem. I’m just trying to follow the source here, to explain the difference. It is a standard reply to tell user’s on the forum to look for .pacnew files after an upgrade.

I always run pacdiff and review the pacman stdout.

I may have to chalk this up to an unexplainable enduser event. Oh well, :frowning:

Thank you for your insights.

Why don’t you download and check inside the actual package from the REPOSITORIES instead of the GitLab? go to http://yourMirrorURL.com/followThePathToPackageInsideCORE

Or you can look inside your local cache for packages.

Yeah, I did that. Sorry for not mentioning it. The extracted file matches git, which confirms to me that I should have gotten a pacnew because /etc/pacman.conf had changes made to it.

Am I the only one with a changed pacman.conf that hasn’t gotten a .pacnew :upside_down_face:

I thought I could sneak up on this issue (get a .pacnew when config file is different) by reinstalling pacman (pacman -U /var/cache/pacman...), but it doesn’t seem to work that way (I’m on VM trying this now).

What code causes the .pacnew… Is it just the code in /var/lib/pacman/local/pacman-6.0.1-2/install?

I don’t know enough of C to be able to read it like a book but from what I gather that is implemented in the source code of libalpm, which is a part of the pacman source code.
If you do understand and want to examine, look at the source code:

Index of /other/pacman/

is the database where all info about all installed packages
that pacman knows about and thus can manage and keep track of
is kept

I dont think mine has never changed forcibly, and I have certainly edited it.

Were there even any changes in package etc/pacman.conf for this minor update?
Methinks your situation is this one (see Arch wiki):

original = X, current = Y, new = X

The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user.

Even if your local /etc/pacman.conf was different you would not get a pacnew file due to both pacman package files having the same content/md5sum.

It’s browsable online: this function seems to be the relevant one.

I’m leaning less towards pacman and more towards git (or buildiso) at the moment.

Where does pacman.conf come from — when the ISO is built…

Walk’n through the steps with questions

  1. [pacman -Qi pacman] shows the Packager at Manjaro. So now I know to focus on the Manjaro package, and not Arch.

  2. When I install any recent Manjaro ISO and compare /etc/pacman.conf to gitlab.manjaro.org/packages/core/pacman/-/blob/master/pacman.conf, they are different.

    I’m expecting to find /etc/pacman.conf that was just installed some place at gitliab. The latest ISO I tried was - manjaro-xfce-21.2.1-220103-linux515

  3. I thought I might build my own ISO, read the source, and see how all the pieces fit and where packages come from. I’m new to these tools, so forgive the hiccups :slight_smile:

    When the Manjaro ISO is created, are the same tools, like buildiso used?

    Is it possible, pacman.conf is coming from a local source, and not git?

NOTE: I’m using pacman.conf to keep it “simple” , but it could be any package with more or less importance in the future, and I’m just try’n to wrap my head around the process to make life easier in the future.


I was discussing Manjaro and gitlab and github with another Manjaro user. They thought Manjaro had migrated from github to gitlab. Is the migration complete? Is Manjaro still using github?

No, though some individual developers still have their own code there, so it may be sourced from the PKGBUILDs found at the official source - Gitlab - or rather, Manjaro’s own instance of Gitlab.

actual daily dev images are on github:

Get our latest daily developer images now from Github: Plasma , Gnome , XFCE .

Github is used due to the CI offered.

The official repo is on https://gitlab.manjaro.org where the only relation to https://gitlab.com is the software used.

All Manjaro ISO is built using manjaro-tools package - no exceptions.

Install the tools and you will find the pacman.conf used on the ISO in folder /usr/share/manjaro-tools

Yeah, I saw those. There’s a video, " Building your custom Manjaro ISO via Github Actions CI" on the Manjaro youtube channel.

It is too bad about Architect. It’s nice, and it is how I finally figured out where pacman.conf came from. I’m definitely going to experiment with buildiso tools.

I read in the forum that users could still install manjaro-architect and this video by OTB was encouraging.

I did install, and sure enough pacman.conf was different.

I examined the ISO and mounted the squashfs’s (MANJARO_XFCE_212/manjaro/x86_64/{desktopfs,livefs,mhwdfs,rootfs}.sfs). Tools used (strings, hexdump, find).

Bottom line, pacman.conf gitlab source location is based on installation method, and the files are different.

That is correct and it is so because Architect installs the packages from repo

Whereas buildiso creates a bunch of sfs overlay filesystems - put them together with a bootloader and packing them into an iso image. Later Calamares simply unpack two of these filesystems onto the target namely the root filesystem → then the desktop filesystem.

If you want to customize further you the do so in several ways.

The simplest way is by adding files and folders to the desktop-overlay in the profiles folder.

The second method can be achieved by altering the content of the raw filesystems stored in /var/lib/manjaro-tools/iso/.

To access the folders before ISO creation you would use the -x argument with buildiso.

Then add or change content in the filesystem folders and finalize the build using the -zc arguments to with buildiso.

When knowing all this it is possible to alter and customize the final ISO in every possible way and maybe some you haven’t thought of yet.

Pseudo script modifying the prebuild images with custom build AUR package

buildiso -r $chrootsdir -x -p $profile
git clone $aur-package
cd $aur-package && makepkg
pacman -U $aur-package -r $chrootsdir/$profile/x86_64/desktopfs
buldiso -zc -p $profile
1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.