Description of problem: # rpm -e kernel-core-4.14.0-0.rc6.git1.2.fc28.x86_64 ln: target '/boot/dtb' is not a directory error: %preun(kernel-core-4.14.0-0.rc6.git1.2.fc28.x86_64) scriptlet failed, exit status 1 error: kernel-core-4.14.0-0.rc6.git1.2.fc28.x86_64: erase failed # /bin/kernel-install remove 4.14.0-0.rc6.git1.2.fc28.x86_64 /lib/modules/4.14.0-0.rc6.git1.2.fc28.x86_64/vmlinuz ln: target '/boot/dtb' is not a directory # rpm -e uboot-tools uboot-images-armv7-2017.11-0.2.rc2.fc28.noarch uboot-images-armv8-2017.11-0.2.rc2.fc28.noarch # rpm -e kernel-core-4.14.0-0.rc6.git1.2.fc28.x86_64 # Version-Release number of selected component (if applicable): uboot-tools-2017.11-0.2.rc2.fc28.x86_64
Confirmed, got same error during upgrade from F26 to F27 using dnf system-upgrade download --refresh --releasever=27 after Cleanup : libgcc-6.4.1-1.fc25.x86_64 6355/6355 I got this: ln: target '/boot/dtb' is not a directory I am not sure what the side effects will be. Can I ignore it?
The bad use of a wildcard in /lib/kernel/install.d/10-devicetree.install seems to be the problem: for dtbdir in /boot/dtb-* ... If no matching files exist then the literal string "/boot/dtb-*" is used instead.
Saw this after dnf system-upgrade from F26 to F27 and the first kernel upgrade within F27. In my case, this also seemed to prevent the newly upgraded kernel (from updates-testing, 4.13.15-300.fc27.x86_64) from becoming the default boot kernel. GRUB would default to 4.13.13-300.fc27 instead at boot. I cargo-cult-fixed it my creating the /boot/dtb directory. After removing and then reinstalling 4.13.15-300.fc27, I only got the: cat: write error: Broken pipe message while installing the kernel-core package. GRUB now defaults to 4.13.15-300.fc27. FWIW, /boot/dtb, post-install, looks like: $ ls -lZ /boot/dtb/ total 0 lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 4 Nov 25 13:03 boot -> boot lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 dev -> dev lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 7 Nov 25 13:03 dtb-bin -> dtb-bin lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 etc -> etc lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 4 Nov 25 13:03 home -> home lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 lib -> lib lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 5 Nov 25 13:03 lib64 -> lib64 lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 10 Nov 25 13:03 lost+found -> lost+found lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 5 Nov 25 13:03 media -> media lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 mnt -> mnt lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 opt -> opt lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 4 Nov 25 13:03 proc -> proc lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 4 Nov 25 13:03 root -> root lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 run -> run lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 4 Nov 25 13:03 sbin -> sbin lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 srv -> srv lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 sys -> sys lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 tmp -> tmp lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 usr -> usr lrwxrwxrwx. 1 root root unconfined_u:object_r:boot_t:s0 3 Nov 25 13:03 var -> var
*** Bug 1506386 has been marked as a duplicate of this bug. ***
Applying the patch "Add a architecture check for the DT kernel setup" to 10-devicetree.install to F27 would fix this. https://src.fedoraproject.org/rpms/uboot-tools/c/34cd2c20de45bc86cb78b86324a4889bd577fcf7?branch=master Or even better, do not ship 10-devicetree.install in the package on non-ARM archs at all.
(In reply to Michal Schmidt from comment #5) > Applying the patch "Add a architecture check for the DT kernel setup" to > 10-devicetree.install to F27 would fix this. > Or even better, do not ship 10-devicetree.install in the package on non-ARM > archs at all. This is two problems: First, the unintended side effect of a wildcard within ARM arch. Second, it shouldn't be in x86_64 at all if this is ARM specific.
uboot-tools-2017.09-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce2b4209d3
uboot-tools-2017.09-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ce2b4209d3
Installed the new uboot-tools package and still have errors: [jdickers@jdickers Downloads]$ sudo dnf reinstall kernel-core kernel-debug-core Last metadata expiration check: 0:19:20 ago on Wed 29 Nov 2017 09:27:18 AM CST. Dependencies resolved. =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Reinstalling: kernel-core x86_64 4.13.15-300.fc27 updates 21 M kernel-debug-core x86_64 4.13.15-300.fc27 updates 23 M Transaction Summary =================================================================================================================================================================================================================== Total download size: 44 M Is this ok [y/N]: y Downloading Packages: (1/2): kernel-core-4.13.15-300.fc27.x86_64.rpm 1.2 MB/s | 21 MB 00:17 (2/2): kernel-debug-core-4.13.15-300.fc27.x86_64.rpm 1.3 MB/s | 23 MB 00:17 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 2.4 MB/s | 44 MB 00:18 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Reinstalling : kernel-debug-core-4.13.15-300.fc27.x86_64 1/4 Running scriptlet: kernel-debug-core-4.13.15-300.fc27.x86_64 1/4 Reinstalling : kernel-core-4.13.15-300.fc27.x86_64 2/4 Running scriptlet: kernel-core-4.13.15-300.fc27.x86_64 2/4 Running scriptlet: kernel-debug-core-4.13.15-300.fc27.x86_64 3/4 Erasing : kernel-debug-core-4.13.15-300.fc27.x86_64 3/4 Running scriptlet: kernel-core-4.13.15-300.fc27.x86_64 4/4 Erasing : kernel-core-4.13.15-300.fc27.x86_64 4/4 Running scriptlet: kernel-debug-core-4.13.15-300.fc27.x86_64 4/4 cat: write error: Broken pipe Error! echo Your kernel headers for kernel 4.13.15-300.fc27.x86_64+debug cannot be found at /lib/modules/4.13.15-300.fc27.x86_64+debug/build or /lib/modules/4.13.15-300.fc27.x86_64+debug/source. Running scriptlet: kernel-core-4.13.15-300.fc27.x86_64 4/4 cat: write error: Broken pipe Verifying : kernel-core-4.13.15-300.fc27.x86_64 1/4 Verifying : kernel-debug-core-4.13.15-300.fc27.x86_64 2/4 Verifying : kernel-core-4.13.15-300.fc27.x86_64 3/4 Verifying : kernel-debug-core-4.13.15-300.fc27.x86_64 4/4 Reinstalled: kernel-core.x86_64 4.13.15-300.fc27 kernel-debug-core.x86_64 4.13.15-300.fc27 Complete!
I installed the kernel-debug-devel package and the errors for the missing headers went away. Now the only errors I get are: Running scriptlet: kernel-debug-core-4.13.15-300.fc27.x86_64 4/4 cat: write error: Broken pipe Running scriptlet: kernel-core-4.13.15-300.fc27.x86_64 4/4 cat: write error: Broken pipe Not sure if this is still related to this bug or not....
Upgraded to uboot-tools-2017.09-5.fc27, then I deleted /boot/dtb, followed by installing kernel 4.13.16-300.fc27, both from updates-testing. I also saw the `cat: write error: Broken pipe` message, once, when the kernel was installing. The uninstallation of the oldest kernel worked without issues, but upon reboot, the latest kernel was not the default boot option - 4.13.15-300.fc27 was still getting picked by default in the GRUB menu. I eventually `dnf reinstall`ed 4.13.16-300.fc27, and upon one more reboot, still with the "broken pipe" message printing, I got the latest kernel to be the default.
Since I haven't seen any deleterious results from this broken pipe, I was wondering if I could/should simply create an empty /boot/dtb directory. That way, ln would have a target even though I apparently don't need it.
uboot-tools-2017.09-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.