Bug 144712 - rpm -V kernel fails
rpm -V kernel fails
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-01-10 16:41 EST by Richard Li
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-14 12:35:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard Li 2005-01-10 16:41:42 EST
Description of problem:

rpm -V kernel fails on ia64, possibly because vfat doesn't do permissions.

How reproducible:


Steps to Reproduce:
1. rpm -V kernel

Actual results:

a couple lines that include /boot/efi ...

Expected results:

The prompt.

Additional info:

I'm filing under RPM because possible solution is for RPM to not verify perms on
vfat, but I'm not the expert here...
Comment 1 Jeff Johnson 2005-01-10 23:08:08 EST
Probably true. VFAT is so weird ...
Comment 2 Jeff Johnson 2005-01-14 12:35:47 EST
There are several approaches to working around --verify failures
on file systems that do no supply the basic elements that
are verified.

1) Live with false positives with existing --evrify.
   False positives with known implementation deficiencies
   (like VFAT does not have group/other permissions) has
   the benefit of indicating to the user that the intended
   check is failing.

2) Create false negatives by making --verify aware of VFAT deficiencies.
   False negatives are a lie, and teaching rpm about file system
   deficiencies is non-trivial, particularly with selinux file      
   contexts, and require users to understand a more complicated
   --verify mechanism.

3) Add a '?' dunno state.
   Again, the '?' indicator has usually created more questions
   than answers, as what users *really* want is not to be bothered.

I believe that the existing false positive scheme is as good
as any other solution, hence WONTFIX. Get this bug attached to
some tracker bug instead of arguing with me please.


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