Created attachment 1739388 [details] dnf upgrade console output from a similar older drive onto the very same computer but without rebooting it yet. Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. dnf upgrade -y 2. reboot 3. log in as non-root user 4. sudo bash Actual results: sudo bash core dumped su -l core dumped Expected results: I expected it to bring up a root shell. Additional info: It's on fedora rawhide on an internal sata sk hynix s31 ssd. The only thing I witnessed that was odd during the dnf upgrade was something of an output error.
Running scriptlet: kernel-core-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 540/540 sort: fflush failed: 'standard output': Broken pipe sort: write error gzip: stdout: Broken pipe gzip: stdout: Broken pipe sort: write failed: 'standard output': Broken pipe sort: write error Running scriptlet: nss-3.59.0-2.fc34.x86_64 540/540 Running scriptlet: rpm-4.16.1-1.fc34.x86_64 540/540
That's unlikely to be dnf's fault, instead some central component is broken on rawhide and the whole works blew up.
This really doesn't look like a dnf issue. I can think of the following root causes: * other components broken (does rebooting the system help?) * broken hardware: SSD, RAM (what smartctl --health /dev/sdX or dmesg say?) * broken file system If your system boots, I recommend running `dnf remove --duplicates` to recover from a potentially inconsistent state.
I just realized that you've rebooted already (it's mentioned in the summary). Could you boot from a live media, mount the system partition and check if the symlinks in /usr/lib64 point to reasonable locations? Also all the files under /usr/lib64 should have non-zero size. You could use dnf from the live media to repair the mounted file by using `dnf --installroot=/path/to/mount ...`
Same here. I can boot into the system since I have an older kernel available. No dead symlinks in /usr/lib64. All of them are non-zero.
I get similar error on regular Fedora 33 workstation update. This command: sudo dnf distro-sync 2>&1 | tee update.txt generates these lines: (...) Uitvoeren van scriptlet: kernel-core-5.9.16-200.fc33.x86_64 23/23 sort: fflush failed: 'standard output': Broken pipe sort: write error gzip: stdout: Broken pipe gzip: stdout: Broken pipe sort: write failed: 'standard output': Broken pipe sort: write error (...) Apparently, the rest of the update continues regularly. After reboot these PCs work just fine. Perhaps caused by usage of fish as a shell. I'm attaching output of DNF from two different PCs here, hopes this helps.
Created attachment 1742258 [details] Commenter 6 attachment 1 [details]
Created attachment 1742259 [details] Commenter 6 attachment 2 [details]
Same error here on Fedora 33. Excerpt from "dnf upgrade" output: [...] Esecuzione scriptlet in corso: kernel-core-5.9.16-200.fc33.x86_64 34/34 sort: fflush failed: 'standard output': Broken pipe sort: write error gzip: stdout: Broken pipe gzip: stdout: Broken pipe sort: write failed: 'standard output': Broken pipe sort: write error [...]
Based on comment#6 and comment#9 the problem might be in kernel scriplet. Reassigning.
*** Bug 1911033 has been marked as a duplicate of this bug. ***
I am not sure but I think I also had this problem on rawhide (sudo was segfaulting and I couldn't login). It was caused by broken symlinks in /etc/pam.d/ and I fixed it by selecting a profile with authselect: authselect select minimal. It did happen during a dnf update (most likely some scriptlet) but it was almost a month ago and I no longer have the logs.
FWIW: See bug 1911038, it seems this is a problem with dracut, but I wonder if it's related to rpm or the running kernel somehow (it doesn't occur when dracut is called directly) Bug 1911364 might be duplicate.
I'm also getting this on my Fedora 33 system. I think it's been happening on every kernel update since before christmas. The system still boots; running authselect didn't do anything, and 'dnf remove --duplicates' didn't find anything. I'll attach the output of me trying to reinstall the kernel. (I'm also using RPMFusion, and that's fail a checksum; is that happening to anyone else with this problem? Could that be related?)
Created attachment 1748100 [details] Comment 14 attachement
TWIMC: the "broken pipe" messages that some people mentioned here seem to be a bug in kexec-tools. See Bug 1911038 for details. They afaics are unlikely to be causing the "core dumped" problems that let to the creation of this bug report.