On Feb 1, 2011, at 11:26 AM, Silvan Calarco wrote:
> On Tuesday 01 February 2011 16:48:20 Jeff Johnson wrote:
>>> Resolved (and stupid me)!
>>> While preparing the list of rpm commands to send you I noticed that
>>> between each rpm invocation the script was removing the db cache:
>>>
>>> rm /var/makedist/root.tmp/var/lib/rpm/__db.00* -f
>>
>> Eeek! That's a tad bit of overkill, but I've seen worse solutions.
>
> :)
> I remember I was a lot stressed some years ago with rpm 4 problems before
> applying this ugly workaround. Since then evidently I forgot about it :)
Yup. I wear my RPM scars proudly:
RPM was the first application to use POSIX (optional) shared
mutexes when NPTL (and TLS and futexes and O(1) signal delivery and more
were first introduced way back when.
Lusers came after RPM with pitchfork's, tar, garlic and silver bullets looking
for RPM support. The issues persist hysterically to this day in rpm-5.3.8
where
rpm --rebuilddb
and
rm -f /var/lib/rpm/__db*
and all the other bubble-gum hack-o-rounds have passed into Linux "urban
legend" myths.
(aside)
I don't know how to translate "urban legend" connotatively. Here's an example:
Baby
alligator's used to be sold as pet's. When the pet was no longer interesting,
it was often flushed down the toilet. This leads to reports of sightings
of 10+ foot alligator's roaming the sewer's of NYC. Read Thomas Pynchon's
book V for one hilarious spoof of "urban myths".
Meanwhile, the proper way to "fix" issues using "RPM ACID" in rpm-5.3.8 is
cd /var/lib/rpm
db51_recover -ev
and I'll be more than happy to assist when you and OpenMAMBA are ready
to make the transition from rpm-5.2.1 -> rpm-5.3.8.
> Now it's great that I can remove it and see rpm work as expected even with
> heavy installation commands. I also had db integrity problems after full
> installation (rebuilddb needed) and I think those should be fixed too as well.
>
>>> I made this workaround a long time ago (years) to fix problems with rpm 4
>>> and just removing this fixed the problem, does it make sense?
>>
>> If *not* removing the __db* files "fixes", then yes it makes sense.
>
> Yes, I meant removing the 'rm __db*' command, thus keeping the __db* files.
>
The are no circumstances where
rm -f /var/lib/rpm/__db*
is an appropriate fix. The "urban myth" is really a flaw in the
design of linux kernel futexes, where it was possible to lock
a futex and then exit in an application like RPM. There was no
means (at the time, there are "robust futexes" implemented now)
other than a reboot to clear a "stale futex".
And "stale futexes" -> "stale locks" in Berkeley DB where a cheap
(but woefully ineffective) workaround is/was
rm -f /var/lib/rpm/__db*
Short answer: All of "stale lock" handling is now resident in a 10+
foot alligator's belly that roams the sewers underneath the streets
of NYC nightly. If you listen carefully, you can also hear the
ticking of the alarm clock (an obscure allusion to Peter Pan ...)
>> An explanantion consistent with what you appear to be saying is that a
>> header in an rpmdb was mmap'd directly from the file system. When the
>> __db* file was removed, then the data underneath the pointer diverged and
>> became inconsistent with other data returned from an rpmdb. The
>> refcnt on the open fdno used in the mmap from the __db* cache files
>> prevented the data from just being added to free blocks on the file system.
>>
>> All of the above is just a guess however.
>
> This explaination sounds good to me for what (little) I know about internal
> mechanisms. Now I'm trying to build some of the other targets (e.g. the
> openmamba installation livedvd with 2.2 GB of packages installed) to be sure
> that the issue is indeed completely resolved.
>
>>> Sorry for not finding it myself, afaics rpm 5 is doing its job well!
>>
>> NP. I *love* being a lazy schmuck ;-)
>>
>> I'm still pursuing arm development, OpenMAMBA/arm is one of the few current
>> arm distros I see around. So I'll be happy to help test your arm iso's
>> with qemu when you are ready.
>
> Well, I'll let you know for openmamba-tablet, but there is already a
> distribution called openmamba-sdk that can be used in chroot with qemu:
> http://www.openmamba.org/distribution/media/sdk.html?lang=en
>
> There is a pointer to the wiki with instructions
> (http://wiki.openmamba.org/it/index.php/ARM), unfortunately in italian
> currently, but it should be easy to understand even using an online
> translator. This distribution, intended for openmamba-for-arm development
> itself, is a bit outdated but it provides smartpm so it can be automatically
> upgraded to current packages with "smart upgrade && smart upgrade".
>
>> And I should have a OpenMAMBA VM setup in the next couple of days.
>
> Fine! I suggest you to install the livecd or livedvd development snapshot.
>
The livedvd looks most useful for my purposes (but I have the livecd too).
hth
73 de Jeff
> Best regards,
> Silvan
>
> --
> mambaSoft di Calarco Silvan
> Web: http://www.mambasoft.it
>
> mambaSoft Store @ http://www.mambastore.it
> openmamba GNU/Linux development @ http://www.openmamba.org
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
