I applied the 6.2 upgrade to a 6.0 system not realizing that the system had chattr +i -R'd /lib,/bin,/sbin,/usr, /etc/rc.d, /etc/mail and other misc files. The install script continued along its happy way NOT installing some files nor generating any error messages. When the machine was rebooted, it was all messed up because it had somehow managed to delete /etc/inittab and did not replace it with something useful. It did manage to update the package database so a subsequent upgrade thought everything was up to date and didn't want to install the new software.
Um, rpm is totally unprepared to deal with chattr (or even rdonly) file systems. Until chattr is more widely (and consistently) used, I see little need to teach rpm about chattr. For now, just "Don't do that!".
I feel that this is unfortunate. I have been teaching a LOT of people to use the immutable bit on critical files and directories and it has saved a number of systems from being broken into in the past (sometimes by crackers, sometimes by a manager who gained access to a console logged in as root). I guess I really feel that it isn't reasonable for RPM to continue doing its thing without telling anyone of any errors or warnings and later going 'doh because it failed or partially failed (totally failing seems easier to deal with than partially failing). Believe me, after doing this once, the second time you do it to yourself, you sort of feel like the Coyote (oh no!). -Robert
The feature request for rpm is not discarded, only deferred. Before chattr, the rdonly file system problems need to be resolved, and before that a less naive scheme than the current netsharedpath mechanism needs to be devised. FWIW, part of teaching people to use chattr involves explaining how the use of chattr affects other programs like rpm, etc ...
This is significantly more serious than the current bug report gives credit. We recently found a machine with chattr +i on /bin/login and a few other files. In particular this meant that when upgraded it silently failed up upgrade these packages, although there was a note on one of the virtual consoles. This was in relation to a hacking incident - it meant that if the machine that had been hacked had been upgraded then the back door that the hacker placed there would have survived. This _has_ to be an issue, since traditionally an upgrade would be considered a safe way of removing problems with a compromised machine. If nothing else the installation should come up with big red flags complaining that it cannot upgrade a package. Julian (unix-support.ac.uk)
Collecting RO problems at #52190. *** This bug has been marked as a duplicate of 52190 ***