Description of problem: mailx/mail not found after in-place F32-F33 uprade, but package is still shown as installed by dnf Version-Release number of selected component (if applicable): mailx-12.5-35.fc33.x86_64 How reproducible: Upgrade F32-F33 in place Steps to Reproduce: 1. Upgrade F32-> F33 in place 2.attempt to use mail or mailx (reports "not found" and suggests installing 'mailx' package 3. dnf/rpm shows mailx package installed Actual results: Appears the symlinks in /etc/alternatives are missing/incorrect, since OS cannot find the actual executables Expected results: Additional info: Removing the mailx package and re-installing resolves the problem. NOTE: removing the package removes a huge pile of other packages as well, including a boatload of perl modules, oddly, Google Earth.
Same on F31->F33 upgrade. Immediately after the upgrade, I wanted to use the `mail` command, and got the same suggestion to install mailx package, which was already installed. `dnf reinstall mailx` fixed it for me (no need to remove all the dependencies then, Tim!). This is what was on the filesystem initially: lrwxrwxrwx. 1 root root 22 Nov 23 09:17 /usr/bin/mail -> /etc/alternatives/mail lrwxrwxrwx. 1 root root 14 Nov 23 09:17 /etc/alternatives/mail -> /usr/bin/mailx [<- BROKEN LINK - /usr/bin/mailx missing] After reinstall of mailx, this appeared: lrwxrwxrwx. 1 root root 23 Nov 23 11:56 /usr/bin/mailx -> /etc/alternatives/mailx I'm not sure what happened here, as /usr/bin/mailx is owned by the mailx package so I assume it should be created on install. I checked the upgrade logs, but didn't see any errors emitted: Nov 23 09:17:56 gigalith.gloomytrousers.co.uk dnf[1073]: Running scriptlet: mailx-12.5-35.fc33.x86_64 1415/6239 Nov 23 09:17:57 gigalith.gloomytrousers.co.uk dnf[1073]: Upgrading : mailx-12.5-35.fc33.x86_64 1415/6239 Nov 23 09:17:57 gigalith.gloomytrousers.co.uk dnf[1073]: Running scriptlet: mailx-12.5-35.fc33.x86_64 1415/6239 ... Nov 23 10:59:25 gigalith.gloomytrousers.co.uk dnf[1073]: Cleanup : mailx-12.5-32.fc31.x86_64 5017/6239 ... Nov 23 11:26:10 gigalith.gloomytrousers.co.uk dnf[1073]: Verifying : mailx-12.5-35.fc33.x86_64 3793/6239 Nov 23 11:26:10 gigalith.gloomytrousers.co.uk dnf[1073]: Verifying : mailx-12.5-32.fc31.x86_64 3794/6239
The only binary for this package is mailx.mailx as you can see from the build-id: # rpm -ql mailx /etc/mail.rc /usr/bin/Mail /usr/bin/mail /usr/bin/mailx /usr/bin/mailx.mailx /usr/bin/nail /usr/lib/.build-id /usr/lib/.build-id/13 /usr/lib/.build-id/13/2b6958880188398a8d95702b2bf9314b1b32cf /usr/share/doc/mailx /usr/share/doc/mailx/AUTHORS /usr/share/doc/mailx/COPYING /usr/share/doc/mailx/README /usr/share/man/man1/Mail.1.gz /usr/share/man/man1/mail.1.gz /usr/share/man/man1/mailx.1.gz /usr/share/man/man1/mailx.mailx.1.gz /usr/share/man/man1/nail.1.gz # ls -l /usr/lib/.build-id/13/2b6958880188398a8d95702b2bf9314b1b32cf lrwxrwxrwx. 1 root root 31 Jul 28 21:09 /usr/lib/.build-id/13/2b6958880188398a8d95702b2bf9314b1b32cf -> ../../../../usr/bin/mailx.mailx -- it appears the issue is with the upgrade and the /etc/alternatives links pointing to the new binary - suspect larger issue is not running the pre/postinstall scriptlet on an upgrade: # rpm -q --scripts mailx preinstall scriptlet (using /bin/sh): # remove alternativized files if they are not symlinks for f in Mail mail mailx nail; do [ -L /usr/bin/$f ] || rm -f /usr/bin/$f >/dev/null 2>&1 || : [ -L /usr/share/man/man1/$f.1.gz ] || rm -f /usr/share/man/man1/$f.1.gz >/dev/null 2>&1 || : done postinstall scriptlet (using /bin/sh): # set up the alternatives files /usr/sbin/update-alternatives --install /usr/bin/mailx mailx /usr/bin/mailx.mailx 200 \ --slave /usr/bin/Mail Mail /usr/bin/mailx \ --slave /usr/bin/mail mail /usr/bin/mailx \ --slave /usr/bin/nail nail /usr/bin/mailx \ --slave /usr/share/man/man1/mailx.1.gz mailx.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ --slave /usr/share/man/man1/Mail.1.gz Mail.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ --slave /usr/share/man/man1/mail.1.gz mail.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ --slave /usr/share/man/man1/nail.1.gz nail.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ >/dev/null 2>&1 || : preuninstall scriptlet (using /bin/sh): if [ $1 -eq 0 ]; then /usr/sbin/update-alternatives --remove mailx /usr/bin/mailx.mailx >/dev/null 2>&1 || : fi postuninstall scriptlet (using /bin/sh): if [ $1 -ge 1 ]; then if [ "$(readlink /etc/alternatives/mailx)" == "/usr/bin/mailx.mailx" ]; then /usr/sbin/update-alternatives --set mailx /usr/bin/mailx.mailx >/dev/null 2>&1 || : fi fi dnf reinstall appears to correctly run the scripts
The postinstall scriptlet should be as follows: # set up the alternatives files /usr/sbin/update-alternatives --install /usr/bin/mailx mailx /usr/bin/mailx.mailx 200 \ --slave /usr/bin/Mail Mail /usr/bin/mailx.mailx \ --slave /usr/bin/mail mail /usr/bin/mailx.mailx \ --slave /usr/bin/nail nail /usr/bin/mailx.mailx \ --slave /usr/share/man/man1/mailx.1.gz mailx.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ --slave /usr/share/man/man1/Mail.1.gz Mail.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ --slave /usr/share/man/man1/mail.1.gz mail.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ --slave /usr/share/man/man1/nail.1.gz nail.1.gz /usr/share/man/man1/mailx.mailx.1.gz \ >/dev/null 2>&1 || :
FEDORA-2021-227f7f635b has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-227f7f635b
FEDORA-2021-7cd5de24ac has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-7cd5de24ac
FEDORA-2021-227f7f635b has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-227f7f635b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-227f7f635b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-7cd5de24ac has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-7cd5de24ac` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7cd5de24ac See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-227f7f635b has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-7cd5de24ac has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
A few days ago I upgraded F31>F33 and encountered the same problem. (After upgrading I did another dnf update, but don't think that's relevant.) The installed version is mailx-12.5-36.fc33, so I would expect to not see this problem anymore. Alternatives of mail points to the executable: lrwxrwxrwx 1 root root 20 May 2 14:33 /etc/alternatives/mail -> /usr/bin/mailx.mailx but that doesn't help. I noticed that /usr/bin/mailx is missing, `rpm -Vv mailx` gives: ......... c /etc/mail.rc ......... g /usr/bin/Mail ......... g /usr/bin/mail missing g /usr/bin/mailx ......... /usr/bin/mailx.mailx ......... g /usr/bin/nail ......... a /usr/lib/.build-id ......... a /usr/lib/.build-id/20 ......... a /usr/lib/.build-id/20/d5b5e3384cc4dd77582f9e738510272be44b8a ......... /usr/share/doc/mailx ......... d /usr/share/doc/mailx/AUTHORS ......... d /usr/share/doc/mailx/COPYING ......... d /usr/share/doc/mailx/README ......... d /usr/share/man/man1/Mail.1.gz ......... d /usr/share/man/man1/mail.1.gz ......... d /usr/share/man/man1/mailx.1.gz ......... d /usr/share/man/man1/mailx.mailx.1.gz ......... d /usr/share/man/man1/nail.1.gz I didn't reinstall mailx (yet), so that I can give you information about the systems current state, should you need it. Though, I can reinstall, to see whether that fixes the problem. Please let me know.
(In reply to ND from comment #10) > I didn't reinstall mailx (yet), so that I can give you information about the > systems current state, should you need it. Though, I can reinstall, to see > whether that fixes the problem. Please let me know. Thanks, but I don't think it can help. Try reinstalling, I think that will fix it. Anyway, this looks like a different issue. I'm not sure what's wrong though, I'll try to reproduce it.
Thanks. I reinstalled and that solved my problem. > Anyway, this looks like a different issue. I am by no means an expert, but I would think it might be partially the same problem, because also for Russell Odom /usr/bin/mailx was missing.