Hide Forgot
Created attachment 509949 [details] Anaconda dump Description of problem: Anaconda crashes, depending on the combination of packages selected Version-Release number of selected component (if applicable): 15.31 How reproducible: Reliable with the same set of packages selected Steps to Reproduce: 1. pxe-install F15 (text mode) 2. 3. Actual results: Anaconda crashes after last package is loaded, but before installing boot (sorry, that's all that's available from screen info) Expected results: Anaconda completes the install (or at least handles the exception properly if I'm doing something silly). Additional info: 1. Success/failure depends on the particular set of packages selected. However it's not a simple dependence. I can choose one subset of packages, A, which installs correctly, and another subset, B, which also installs correctly, but A U B won't install. It's also not a space dependence, A U B still fails even if I double the available filesystem space. 2. I suspect that the problem may be partially to do with selecting graphical components for a non-graphical install; I eventually got an acceptable install by eliminating everything that might have a graphical component. But it isn't purely a result of that, because of 1. 3. Of course, this looks a lot like Bug 601291. However I think it must be a different issue, because that was reported against F13 and F14 installs, whereas the kickstart script I was using here worked fine for F13 and F14 (modulo obvious changes in directory names etc).
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