Skip to main content ↑ ↓
Topic: [mkinitcpio] Fails to add nested symlinks correctly. (Read 260 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[mkinitcpio] Fails to add nested symlinks correctly.

With a recent update, mkinitcpio does not copy anymore the target file correctly if it encounters a symlink, resulting in a stale link be embedded into the initial ramdisk.

Specifically, if a symlink points to another symlink, the intermediate symlink, which is the target of the first symbolic link, is omitted: 
If in the file system the link structure is
Code: [Select]
file_a -> file_b -> file_c
and file_a should be added to the image, only file_a and file_c are added but file_b is omitted.

This is contrary to the previous behaviour, and contrary to the manpage.

man mkinitcpio states:

Quote from: man mkinitcpio
       add_file path [ destination ] [ mode ]
           Adds a file and any needed parent directories to the image. If it is a symlink, both the symlink and the target file will be added. Optionally, a destination within the initramfs image as well as a file mode can be specified. By default, the destination and mode will be taken from the source and mode of the file specified by the path.
(bold accentuation by myself)

However, I have a /lib/initcpio/install/dmcrypt_and_resume which contains, amongst others,
Code: [Select]
[...]
add_file /etc/suspend.conf
[...]
and on my system /etc/suspend.conf is a symbolic link pointing to /usr/local/etc/suspend.conf, which in turn points to /usr/local/platform/GPD_Pocket/etc/suspend.conf which is the actual file.

For many years, it has worked correctly, but now I find /etc/suspend.conf to be a dangling symlink in the image since the intermediate /usr/local/etc/suspend.conf is missing, while /usr/local/platform/GPD_Pocket/etc/suspend.conf is present.

I see this problem has appeared also for other files which are nested symlinks.

mkinitcpio's package version on my system is 33-1.

(Here is the corresponding report at bugs.archlinux.org: https://bugs.archlinux.org/task/76711)