Bug 716662

Hi,

can you try resyncing your repos? There seems to be a problem with RPM db checksum according to the logs:

Rpmdb checksum is invalid: dCDPT(pkg checksums)

Ales

Yes, I noticed that also but assumed it was a red herring. This is an install directly from a copy of the F15 i386 install DVD (so the only repo involved is the copy of the install DVD NFS-mounted into anaconda, as far as I can understand). OK, I better make sure I checksummed the iso. Other than that, I'm not sure what I can do - any more detailed directions would be greatly appreciated.

Dear Ales, the iso is OK according to sha256. So I'm not sure what else to check. If I'm misunderstanding your request (i.e. if there is some way I could resync the DVD repo), please clarify.

There's more than just that checksum error, though.  Check out install.log right at the Django package.  That's where the real weirdness begins:

Installing Django-1.3-2.fc15.noarch
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region
error: rpmdb: unable to allocate memory for mutex; resize mutex region

This really points to a bug in RPM or yum, cloning.

In Anaconda I am going to have a better exception window displayed (not directly a traceback).

I don't completely follow the last couple of messages, but in case it's relevant, the machines I'm installing to have 1GB memory (failing on four separate machines, so it's unlikely to be a hardware problem). Please let me know if/what other info I can usefully supply.

21:20:57,181 INFO program: Running... mke2fs -t ext4 /dev/mapper/vg_tangof15-lv_var
21:20:58,105 INFO program: Filesystem label=
21:20:58,106 INFO program: OS type: Linux
21:20:58,106 INFO program: Block size=1024 (log=0)
                           ^^^^^^^^^^^^^^^

Block size of 1024 has "always" been disastrous for rpmdb, for whatever reason (it's sufficiently rare condition that nobody has botherer digging deep into it). Could be that BDB defaults to using some values based on the block size that end up being too small for rpm's use or such.

The reason you end up with block size 1024 is that your /var is extremely small:
logvol /var --fstype ext4 --name=lv_var --vgname=vg_tangof15 --size=480

If it managed to install, you'd almost certainly run into numerous other problems with /var that small, such as not being to able to perform system updates because yum runs out of diskspace just to download the packages to update. Increase the size considerably (eg 4800) which will result in a larger block size, which should give you a working install and a much happier system in its post-install life.

Oh well. This finally prompted to set up a reproducer and have a closer look. The issue has been complicated and mixed up over the years by (reputed) fs bugs in the kernel in this particular configuration, plus perhaps the BDB diagnostics in this situation haven't been so clear. In any case, the
mystery appears to be no deeper than BDB consuming LOT more mutexes when its page size (which defaults to fs block size) is 1024 than the "regular" 4096:

Case 1, 587 packages:

BS 4096:
13861   Mutex in-use count
13861   Mutex maximum in-use count

BS 1024:
30186   Mutex in-use count
30186   Mutex maximum in-use count

Case 2, 2765 packages:

BS 4096:
28030   Mutex in-use count
28030   Mutex maximum in-use count

BS 1024:
80702   Mutex in-use count
80702   Mutex maximum in-use count

For large sets of packages the number of used mutexes is getting close to BDB default limit (~30000 with current rpm configuration) on 4096 blocksize too, so it needs tweaking sooner than later anyway.

(In reply to comment #7)
Dear Panu,
   Thank you for your detailed and very helpful explanation. Sorry for the delayed reply, I have been travelling so had no way to test till now.

> Block size of 1024 has "always" been disastrous for rpmdb, for whatever reason
> (it's sufficiently rare condition that nobody has botherer digging deep into
> it). Could be that BDB defaults to using some values based on the block size
> that end up being too small for rpm's use or such.
> 
> The reason you end up with block size 1024 is that your /var is extremely
> small:
> logvol /var --fstype ext4 --name=lv_var --vgname=vg_tangof15 --size=480

I've now upped it to size=2048, and it has built OK with the full complement of the packages I needed. So it's clearly confirmed that this was the issue.
> 
> If it managed to install, you'd almost certainly run into numerous other
> problems with /var that small, such as not being to able to perform system
> updates because yum runs out of diskspace just to download the packages to
> update. Increase the size considerably (eg 4800) which will result in a larger
> block size, which should give you a working install and a much happier system
> in its post-install life.

Actually, there was good reason for the small size for /var - these are cluster machines, with no yum proxy, so they stay with the base install, and there is no possibility of a problem with updates. They only have 40G disks, so I need to squeeze /var down as much as possible (and I need it in a separate filesystem so that when anything does go wrong, it is relatively easy to clean up). I can live with 2048, but if you know any way for kickstart to directly control the block size (i.e. pass the -b parameter to mke2fs) that would be even better.

    Thanks again for your help
    Bob

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping