Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#76182 - [mkinitcpio] lookups for dd in /usr/local/bin
Attached to Project:
Arch Linux
Opened by Marc Rechté (mrechte) - Wednesday, 12 October 2022, 17:28 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 12 October 2022, 23:28 GMT
Opened by Marc Rechté (mrechte) - Wednesday, 12 October 2022, 17:28 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 12 October 2022, 23:28 GMT
|
DetailsDescription:
In /usr/lib/initcpio/functions, dd is required to determine kernel version (kver). However, if ones defines a dd command in /usr/local/bin, the function will take that version instead of the original one located in /usr/bin. This will ends up in the following error and an un-bootable machine: (12/21) Updating linux initcpios... ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img ==> ERROR: invalid kernel specified: `/boot/vmlinuz-linux' Additional info: * package version(s) * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: |
This task depends upon
Closed by Toolybird (Toolybird)
Wednesday, 12 October 2022, 23:28 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments
Wednesday, 12 October 2022, 23:28 GMT
Reason for closing: Not a bug
Additional comments about closing: See comments
Comment by Doug Newgard (Scimmia) -
Wednesday, 12 October 2022, 22:35 GMT
Yeah, overriding system tools will break things. Pretty normal.
Comment by Toolybird (Toolybird) -
Wednesday, 12 October 2022, 23:28 GMT
My initial reaction was the same as @Scimmia's. I don't think we can protect against every single scenario involving /usr/local.