Error: config file /etc/pacman.conf, line 1: All directives must belong to a section

Support
1

Hello!

Getting this error while trying to install any AUR package in Pamac or to check for installed kernels (mhwd-kernel -li):

error: config file /etc/pacman.conf, line 1: All directives must belong to a section.

Beginning of my pacman.conf file looks like this

#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives

#
# GENERAL OPTIONS
#
[options]

I suspect the problem started very recently (with last 03-05-25 update?), probably after I’ve removed community repo entries from pacman.conf (using Kate). Not seeing any rogue blanks or spaces in .conf file, so I have no idea, why error is pointing to line 1. Tried replacing all the pacman.conf content with pacman.conf.pacnew data, but get the same error.

Ideas how to get rid of this error would be appreciated. Thanks!

2

As you have edited pacman.conf - please verify your config using the package default - especially look at the entries defining a repo - but also look for accidental removal of lines or chars.

You can safely replace your pacman.conf with the content from the package

3

Thanks for your reply. Conf file from the link was almost identical, apart from additional comment line. And replacing my conf file with the data from the link results in same error message unfortunately.

4

Your file has a - to the human eye - invisible error

Move the file to a backup

sudo mv /etc/pacman.conf /etc/pacman.conf.bak

Then create a new file

sudo nano /etc/pacman.conf

And paste the content from gitlab and save the file

3 Likes
5

Thank you, you are right! That was indeed unseen by human eye case (=
Symbol # in line 1 was different from others # in the file. Unseen in Kate, but indicated differently in nano. Edited it out in nano and things are working! Thanks!

1 Like
6

How the heck you were able to put this in???

1 Like
7

My guess was/is the byte designating file content encoded in something other than ASCII.

Some GUI editors add it when saving a file.

Compilers and applications expecting ASCII format complains loudly when that byte exist.

1 Like
9

I’ve no idea, as linux-aarhus mentioned, probably something that happening during saving the file (encoding related?) The scary thing is, that Kate was pretty consistent at it (=

Noticed this Kate’s behavior was encountered before - [Link]

10

Not sure if it is switched on as default (I’m fairly certain it isn’t). It’s not enabled on my installation, and I’m fairly sure I’ve left the settings for Kate as they were when I installed Manjaro on my new mini-PC at the end of 2023:

11

Yep, I had this setting on. But I remember fiddling with it some long time ago, while trying to solve some encoding issue. Also believe that it isn’t on by default.

1 Like
12

There are a vast amount of legacy applications that might still choke with a BOM present. This was particularly troublesome in web server applications for a long while; especially with the adoption of utf-8 as a defacto character set for web and other publishing. Most serious text editors began making the BOM optional as a means to address the problem.

TL;DR:
The Byte Order Mark (BOM) isn’t enabled by default.

Regards.

2 Likes
13

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