Arch Linux

Description:
mkinitcpio 34's add_file breaks with symlinks that become a self-referential loop when copied to their new name inside the image
# ln -s crypttab crypttab.initramfs
# add_file crypttab.initramfs crypttab

This worked in 33, though I suspect only by coincidence; The new outcome is not all that surprising when actually given some consideration.
It should either be explicitly allowed and effectively turned it into a (dereferenced) copy of the target, or disallowed completely and reported as an error.
Either way, it should be detected and not silently build a broken initramfs, since there is no immediately obvious (to a user, without considering mkinitcpio hook internals) reason why having crypttab.initramfs be a symlink to crypttab should be problematic and hence it's an easy mistake to make.
If this is deemed too much effort, there should probably at least be warnings about symlinking files intended for the initramfs on the wiki, preferrably whenever such files are mentioned.

Additional info:
* mkinitcpio 34-2

Steps to reproduce:
- Use sd-encrypt hook (or otherwise add_file '/etc/crypttab.initramfs' '/etc/crypttab')
- # ln -s crypttab /etc/crypttab.initramfs
- # mkinitcpio -P
- /etc/crypttab in initramfs will be a symlink to itself (loop). System won't boot if reliant on crypttab entries.

Workaround:
Use a hard link for /etc/crypttab.initramfs instead