Bug 1490013 - Scriptlet failed during upgrade
Summary: Scriptlet failed during upgrade
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-09 04:40 UTC by George R. Goffe
Modified: 2017-09-26 12:13 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-09-11 13:31:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
gzip'd flat file for ls -al /etc/alternatives (3.10 KB, application/x-gzip)
2017-09-25 12:33 UTC, George R. Goffe
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1494905 0 unspecified CLOSED dnf erase emacs fails (%preun failed) 2021-02-22 00:41:40 UTC

Internal Links: 1494905

Description George R. Goffe 2017-09-09 04:40:48 UTC
Description of problem:

Emacs upgrade produced the enclosed message below.

Version-Release number of selected component (if applicable):
emacs-1:25.2-9.fc28.x86_64

How reproducible:
always

Steps to Reproduce:
1.dnf -y upgrade
2.
3.

Actual results:
Apparently the upgrade ran but a scriptlett has failed to execute properly.

Expected results:


Additional info:

  Running scriptlet: emacs-1:25.2-9.fc28.x86_64                                                                                      225/263 
error: %preun(emacs-1:25.2-9.fc28.x86_64) scriptlet failed, exit status 2
Error in PREUN scriptlet in rpm package emacs
Error in PREUN scriptlet in rpm package emacs
  Cleanup          : quota-nls-1:4.03-12.fc28.noarch                                                                                 226/263 
error: emacs-1:25.2-9.fc28.x86_64: erase failed

Comment 1 Jan Synacek 2017-09-11 13:31:02 UTC
%preun
%{_sbindir}/alternatives --remove emacs %{_bindir}/emacs-%{version}

That's all that it does. It seems to me that either alternatives installation was broken or the symlinks in /etc/alternatives were not there.

It's not clear if this can be reproduced or not, so I'm going to close it now. In case you update rawhide next time, please check the contents of /etc/alternatives, and also if the "alternatives --version" command works before the update. In case this happens again, this information will be needed.

Comment 2 George R. Goffe 2017-09-25 12:33:44 UTC
Created attachment 1330524 [details]
gzip'd flat file for ls -al /etc/alternatives

Jan,

Thanks for your help with this "bug"...

Here's the ls of /etc/alternatives just in case.

This is the second time I have EVER seen this bug. I'm constantly (daily) updating this system (I'm looking for bugs to further the cause).

Again, thanks.

George...

Comment 3 Jan Synacek 2017-09-26 09:49:50 UTC
Is that list after or before the scriptlet failed? It looks like it's after, when the symlink is already correctly pointing to emacs-25.3. My guess is that before the update (i.e. before the scriptlet failed), the /etc/alternatives/emacs symlink has been either corrupted or deleted. That's why the scriptlet failed. It doesn't really have any impact on the functionality if the symlink is correct *after* the update, which it looks it is. It's just that the error looks scary and needs manual intervention. I don't think I can help any more than this.

Comment 4 George R. Goffe 2017-09-26 12:13:52 UTC
Jan,

Thanks for your help.

The listing is after the problem appeared.

rpm -q showed 2 versions of emacs. I removed both but had to add the '--noscripts' option to get the failing version off the system. Then I did a dnf install emacs'*' and everything worked fine.

Again, thanks for your help.

George...


Note You need to log in before you can comment on or make changes to this bug.