Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#15367 - [mkinitcpio] config file is not found with -c

Attached to Project: Arch Linux
Opened by Gerhard Brauer (GerBra) - Saturday, 04 July 2009, 13:19 GMT
Last edited by Paul Mattal (paul) - Tuesday, 05 January 2010, 01:52 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


mkinitcpio fails when a config file is specified via options and the path to the config file is not specified.
mkinitcpio -c initcpio-pata (fails)
mkinitcpio -c ./initcpio-pata (good)

I noticed this behaviour on x86_64 during ISO building. Before a few days it works,
it could be related to the time when readline and bash were upgraded on my machine.

Additional info:
* package version(s)
mkinitcpio 0.5.25-1
readline 6.0.00-1
bash 4.0.024-1

Steps to reproduce:
(as normal user to not hurt something, root is affected too)
cp /etc/mkinitcpio.conf /tmp
cd /tmp
$ ls -l mkinitcpio.conf
-rw-r--r-- 1 gerhard users 2492 4. Jul 14:54 mkinitcpio.conf
$ LANG=C mkinitcpio -c mkinitcpio.conf
/sbin/mkinitcpio: line 196: source: mkinitcpio.conf: file not found
:: Begin dry run
:: Dry run complete, use -g IMAGE to generate a real image

If i use instead:
$ LANG=C mkinitcpio -c ./mkinitcpio.conf
LANG=C mkinitcpio -c /tmp/mkinitcpio.conf
this way it would work.

On line 196 there is a simple:
source "${CONFIG}"

and of source sourcing in bash works:
[gerhard@ws01 tmp]$ source mkinitcpio.conf
[gerhard@ws01 tmp]$ echo $HOOKS
base udev autodetect sata scsi usbinput keymap filesystems

This task depends upon

Closed by  Paul Mattal (paul)
Tuesday, 05 January 2010, 01:52 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Per comments from original reporter, this is caused by an intentional behavior of bash.
Comment by Gerhard Brauer (GerBra) - Saturday, 04 July 2009, 13:49 GMT
Ah, it's not a mkinitcpio problem - it is a bash/sh problem. Take this script:

echo "Test sourcing"
source "${CONFIG}"
echo "Fin"
If shebang is /bin/sh (as in /sbin/mkinitcpio) the error with file not found occurs.
If i change shebang to /bin/bash than it works.

This error occurs here only in bash 4.0.024-1. With bash 3.2.048-3 (tested on a i686) all work fine.

So sourcing something fails when bash is called in sh-modus and works if in normal bash-mode.
Comment by Gerhard Brauer (GerBra) - Saturday, 04 July 2009, 15:04 GMT
Ok, feel free to change the bugreport title cause it's nothng special to mkinitcpio.
I have sent also a mail to
Comment by Thomas Bächler (brain0) - Sunday, 05 July 2009, 00:05 GMT
mkinitcpio needs /bin/bash for other reasons and /bin/sh was wrong anyway. Interesting though that your test script shows the same behaviour.
Comment by Gerhard Brauer (GerBra) - Sunday, 05 July 2009, 06:28 GMT
Got an answer from bash maintainer on
> Description:
> If i source a file relative to the current directory then - if
> in sh mode - sourcing fails with file not found. If i source a file with
> absolute or relative path than it works in sh mode. In bash mode i have
> no problem.

This is a property of bash posix mode when you don't have `.' in $PATH:

28. The `.' and `source' builtins do not search the current directory
for the filename argument if it is not found by searching `PATH'.

> This behavior is new in version 4, old version 3.2 works fine.

The bash-3.2 behavior was a bug. Its fix is listed in CHANGES:

ggg. Fixed a bug that caused a shell running in Posix mode to search $PWD for
a file specified as an argument to source/. when the file was not found
in $PATH.


Yes, if i add '.' to my path then it's ok (Our default is PATH without '.', and this is OK IMHO)
I think it's the best to avoid sourcing something without a path. Don't know if this new behavior touches any of our shell scripts, but it's surely worth to keep in mind... Myself changes my source from where i thought this could be a mkinitcpio bug.

Don't know what to to with this bugreport. Thomas, if you don't see any need for action with this infos you could close it.