Bug 150435 - RPM succeeds when trying to uninstall from a readonly filesystem
Summary: RPM succeeds when trying to uninstall from a readonly filesystem
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-06 14:17 UTC by Ra P.
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-03-06 23:45:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ra P. 2005-03-06 14:17:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.7) Gecko/20040803 Firefox/0.9.3

Description of problem:

I have /usr mounted as read-only, and I only mount it read-write when I make changes to it.

However, I once forgot to mount it as R/W before trying to uninstall a package.  RPM just told me that it succeeded uninstalling the package when, in fact, it didn't succeed.

I realized the package wasn't uninstalled days later.

I don't know whether this is the intended behavior or not, but RPM should at least report something like:

- "Just for you to know, I couldn't uninstall [this_package] because the filesystem (is readonly / didn't allow me to)",

so one can either ignore the warning or make further necessary steps.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Mount /usr r/o
2. Uninstall any package installed
3. Check for uninstalled package.  It will still be there.
  

Actual Results:  RPM reported "Uninstall succeeded".

Expected Results:  RPM should have reported "Couldn't uninstall the package".

Additional info:

Comment 1 Jeff Johnson 2005-03-06 23:45:53 UTC
Yep. rpm does not check for RO mounts, and rpm --erase is
"best effort" i.e. rpm will attempt to erase, but will
not terminate if a unlink(2) or rmdir(2) system call fails.

This behavior is as intended.


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