Red Hat Bugzilla – Bug 160693
file descriptor leak for /tmp/biosdev, maybe causing partition table related failures
Last modified: 2009-12-16 02:28:05 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Description of problem: I experienced an Anaconda traceback while performing the pvcreate step and tried to debug why the pvcreate failed. To cut a long story short, I think it may be due to a file descriptor leak in the edd code. The attached patch should fix the leak. I noticed that this function also leaves doesn't delete the /tmp/biosdev in several of the error cases, I don't see this causing any visible problems at the moment but perhaps the whole function should be restructured to avoid this kind of error. Version-Release number of selected component (if applicable): anaconda-10.2.1.5-2 How reproducible: Always Steps to Reproduce: 1. Installed kubuntu on the hard disk. 2. Tried to install FC4 with all default options 3. Traceback when reaching pvcreate stage Additional info: Looking at /proc/partitions showed that the hdc2 partition which pvcreate was trying to access was only 1 block long which didn't match the new partition table (this was the size of the old partition on the disk). It seems that the "re-read partition table" phase of the partition table update failed due to an open reference to an /dev/hdcX device. I proved this was the problem by firing up fdisk manually and re-writing the partition table. This showed that new partition table had been written to the disk OK, but that the kernel couldn't re-read the partitions. I couldn't find any mount point references to /dev/hdc or obvious FD'd (ls /proc/*/fd | grep hdc). Then I noticed that Anaconda had several open file descriptors listed for "/tmp/biosdev (deleted). It seems quite likely that this leaked file descriptor could be the thing preventing an update of the kernel partition info. Perhaps anaconda / parted should through an exception when it fails to re-read the partition table (fdisk manages to detect this condition)? It looks like many of the currently open bugs could be caused by this. It is easily worked around by simply rebooting and performing the install again (since the disk will already have the "correct" partition table). I don't have the debug info I collected at hand to attach to the bug at the moment. Let me know if you'd like me to provide the open file descriptor lists, traceback etc.
Created attachment 115557 [details] Close FD leak Here is a patch which should fix the FD leak. I've not actually tested it, but it should be fairly obvious (famous last words). The patch was generated against an old anaconda tree, but I checked that the same problem exists in the FC4 src RPM and it should apply cleanly.
If it would be possible for you to also attach the traceback, that'd be very helpful. I think you're right in that this could fix a lot of the currently open bugs (I know I've seen the problem where it crashes the first time through partitioning but works on the second) and having the traceback would help in finding the other bugs that could be fixed by this.
Created attachment 115624 [details] Anaconda dump file
Created attachment 115625 [details] Anaconda log file
Created attachment 115626 [details] Part table written correctly by anaconda, but kernel update fails
Created attachment 115627 [details] fdisk partition table prior to install
Created attachment 115628 [details] /proc/partitions prior to install attempt
Created attachment 115629 [details] Process listing after anaconda fails
Created attachment 115630 [details] Anaconda fd's after failure, shows /tmp/biosdev & /tmp/disk left open
I tried searching through the parted code to try an locate the reason why anaconda doesn't get told about the failure to updatre the kernel /proc/partions and I think the problem is in the parted/libparted/linux.c _disk_sync_part_table() I've attached a copy for reference. If I understand the algorithm of this routine correctly it tries removing all the partitions and notes any errors. It then re-adds the new partitions, but ignores any errors with adding partitions which failed to be removed. In our case the /dev/hdc2 partition is busy so it ignores the request to update the /proc/partitions and the pvcreate fails on the 512 byte /dev/hdc2 device.
Created attachment 115631 [details] parted/libparted/linux.c
*** Bug 161994 has been marked as a duplicate of this bug. ***
*** Bug 162149 has been marked as a duplicate of this bug. ***
*** Bug 162488 has been marked as a duplicate of this bug. ***
*** Bug 162811 has been marked as a duplicate of this bug. ***
*** Bug 162820 has been marked as a duplicate of this bug. ***
*** Bug 163225 has been marked as a duplicate of this bug. ***
*** Bug 163617 has been marked as a duplicate of this bug. ***
*** Bug 163790 has been marked as a duplicate of this bug. ***
*** Bug 164214 has been marked as a duplicate of this bug. ***
*** Bug 164360 has been marked as a duplicate of this bug. ***
*** Bug 160387 has been marked as a duplicate of this bug. ***
*** Bug 164923 has been marked as a duplicate of this bug. ***
*** Bug 164967 has been marked as a duplicate of this bug. ***
*** Bug 164994 has been marked as a duplicate of this bug. ***
How do I install fc4 if I am afflicted by this bug? Is there a new ISO file somewhere?
AFAIK there are no fixed iso's, but you shouldn't really need them. You've got a couple of options to make the install work. If you've already tried the install and had it fail once then simply repeating the install and choosing the same disk partitioning options should make it work on the second attempt (the correct partition table is written to the disk by the first install process and is used successfully by the second install). Alternatively you can zero the partition table before you start the install using something like the rescue mode or a knoppix CD. e.g. fdisk (empty the partition table with 'o' and then write with 'w') or by overwriting the start of the disk,e.g. # dd if=/dev/zero of=/dev/hda bs=512 count=1
*** Bug 166376 has been marked as a duplicate of this bug. ***
*** Bug 166703 has been marked as a duplicate of this bug. ***
*** Bug 167198 has been marked as a duplicate of this bug. ***
*** Bug 167550 has been marked as a duplicate of this bug. ***
*** Bug 167855 has been marked as a duplicate of this bug. ***
*** Bug 167861 has been marked as a duplicate of this bug. ***
*** Bug 161004 has been marked as a duplicate of this bug. ***
*** Bug 168366 has been marked as a duplicate of this bug. ***
*** Bug 168521 has been marked as a duplicate of this bug. ***
*** Bug 168629 has been marked as a duplicate of this bug. ***
*** Bug 168900 has been marked as a duplicate of this bug. ***
*** Bug 169375 has been marked as a duplicate of this bug. ***
*** Bug 169354 has been marked as a duplicate of this bug. ***
*** Bug 169591 has been marked as a duplicate of this bug. ***
*** Bug 169630 has been marked as a duplicate of this bug. ***
*** Bug 160838 has been marked as a duplicate of this bug. ***
*** Bug 170246 has been marked as a duplicate of this bug. ***
*** Bug 170240 has been marked as a duplicate of this bug. ***
*** Bug 170104 has been marked as a duplicate of this bug. ***
*** Bug 170255 has been marked as a duplicate of this bug. ***
Hi, I want to close this request call for now, since I am not planning to use this version of Fedora now. Will wait for the next update.
*** Bug 170209 has been marked as a duplicate of this bug. ***
Created attachment 119953 [details] Anaconda Dump Neither a re-install using the same partioning options or the zeroing of the partion utilizing the Rescue mode solved errors being experienced. Every installation attempt performed was made using the default options presented by the installation gui. The attachment is a dump to floppy option presented during the prompt when the error was experienced. The methodology of utilization of the presented patch in an earlier response would be appreciated, as experience levels vary among users.
*** Bug 170496 has been marked as a duplicate of this bug. ***
*** Bug 170957 has been marked as a duplicate of this bug. ***
*** Bug 171087 has been marked as a duplicate of this bug. ***
*** Bug 171095 has been marked as a duplicate of this bug. ***
(In reply to comment #50) > Created an attachment (id=119953) [edit] > Anaconda Dump > Neither a re-install using the same partioning options or the zeroing of the > partion utilizing the Rescue mode solved errors being experienced. Every > installation attempt performed was made using the default options presented by > the installation gui. The attachment is a dump to floppy option presented > during the prompt when the error was experienced. The methodology of > utilization of the presented patch in an earlier response would be appreciated, > as experience levels vary among users. So how do I fix this problem? I tried a re-install and it keeps repeating over and over.
Based on the debugging I did when raising the original bug, i'd say that the followings bugs might be caused by something other than this fault report. I've scanned the debug output and my guess of what is wrong is as follows: bug 171087 (Jerry Roy) The following error looks like the culprit: "missing components of raid device md0. The raid device needs 2 drive(s) and only 1 (was/were) found. This raid device will not be started." Was one of your partitions in a raid setup previously? If so then you may need to find some way of nuking the meta data from this partition before trying the install (I think "mdadm --zero-superblock /dev/hdaX" might do what you need). Bug 169591 (Frank Bowman) In the attachment you made to this fault report (I notice that this is slightly different to the one attached to your original fault) there are references to VolGroup01 which looks a little odd to me. I was under the impression that the default install created VolGroup00. There are signs that the installer tries to destroy VolGroup01 in an effort to re-create it as VolGroup00 and it looks like something goes wrong with this process. You could try booting into the rescue mode and see whether this successfully starts up the LVM. With this you could manually use remove and/or re-create the LVM volumes before trying the install again (see man lvm). If all else fails you could just completely blank the the whole disks (or just select partitions) with "dd if=/dev/zero of=/dev/... ". The install really should work OK from completely blank disks (and rules out any problems left over by previous installs). If you're prepared to wait another month you could try the updated installer in FC5-test1 (assuming it sticks to the published schedule). This includes the patch to fix the original problem in this fault report.
*** Bug 171673 has been marked as a duplicate of this bug. ***
*** Bug 172827 has been marked as a duplicate of this bug. ***
*** Bug 173310 has been marked as a duplicate of this bug. ***
*** Bug 173765 has been marked as a duplicate of this bug. ***
*** Bug 174091 has been marked as a duplicate of this bug. ***
*** Bug 174003 has been marked as a duplicate of this bug. ***
*** Bug 174256 has been marked as a duplicate of this bug. ***
*** Bug 174610 has been marked as a duplicate of this bug. ***
*** Bug 174622 has been marked as a duplicate of this bug. ***
*** Bug 174878 has been marked as a duplicate of this bug. ***
*** Bug 174960 has been marked as a duplicate of this bug. ***
*** Bug 175069 has been marked as a duplicate of this bug. ***
*** Bug 175041 has been marked as a duplicate of this bug. ***
*** Bug 175678 has been marked as a duplicate of this bug. ***
*** Bug 175679 has been marked as a duplicate of this bug. ***
*** Bug 176668 has been marked as a duplicate of this bug. ***
*** Bug 176748 has been marked as a duplicate of this bug. ***
*** Bug 177193 has been marked as a duplicate of this bug. ***
I believe I have the same problem when installing on a dual processor SMP system with twin SCSI disks using a number of RAID1 partitions. The system has FC3 already installed and running and all I want to do is install FC4 on the / partition. I am only setting the partition mount points using the manual partition table editor but I still get the "error informing kernel ..." bug. As this is a file system server and a number of the partitions contain valuable data I don't wan't to clear the partition table entries. Is there an updated Fedora-4 boot.iso image that fixes this problem ? Is there any other way I can install FC4 on this system ?
I tried applying the Anaconda /tmp/biosdev patch as mentioned earlier in this bug info to my FC4 installation images (stage2.img, netstg2.img and hdstg2.img). This did not cure my problem with my problem system (Other systems I have install fine). In my case when the error "Error informing the kernel about modifications to partition ..." occurs, the anaconda program has a file descriptor open to /dev/sda (I have two SCSI disks /dev/sda and /dev/sdb). I have traced this "fd leak" to occuring just after the start installation screen, after "enablefilesystems" so presumably in packages.py turnOnFilesystems(). I had to get my server working so I did not have time to trace this further. In my case I was updaing a FC3 installation by just re-installing FC4 on an existing partition and so no partition table changes were actually needed. So I got around this bug by commenting out the line: "disk.commit()" in the savePartitions() function in partedUtils.py. A quick howto for those who want to do this is attached.
Created attachment 123521 [details] Micro Howto update Anaconda Install system
*** Bug 178635 has been marked as a duplicate of this bug. ***
*** Bug 178693 has been marked as a duplicate of this bug. ***
*** Bug 178987 has been marked as a duplicate of this bug. ***
*** Bug 179833 has been marked as a duplicate of this bug. ***
*** Bug 180004 has been marked as a duplicate of this bug. ***
*** Bug 180752 has been marked as a duplicate of this bug. ***
*** Bug 181589 has been marked as a duplicate of this bug. ***
*** Bug 181620 has been marked as a duplicate of this bug. ***
*** Bug 181978 has been marked as a duplicate of this bug. ***
*** Bug 183532 has been marked as a duplicate of this bug. ***
*** Bug 184062 has been marked as a duplicate of this bug. ***
*** Bug 184046 has been marked as a duplicate of this bug. ***
*** Bug 184218 has been marked as a duplicate of this bug. ***
(In reply to comment #27) > AFAIK there are no fixed iso's, but you shouldn't really need them. You've got a > couple of options to make the install work. If you've already tried the install > and had it fail once then simply repeating the install and choosing the same > disk partitioning options should make it work on the second attempt (the correct > partition table is written to the disk by the first install process and is used > successfully by the second install). Nuts! This simply does not work! Redhat is required by its license to have a working distribution of any version it sells available for download. And it does not. Redhat needs the money it charges for a 64-bit version of Linux; it is not going to give away a working version of 64-bit Linux until the revenue picture clears up.
> Nuts! This simply does not work! > Redhat is required by its license to have a > working distribution of any version it sells available > for download. And it does not. I wrote the original comment that you referenced I feel I should respond. I'll try to stick to the facts. I should start by saying that i've got no connection with RedHat except than to use Fedora on multiple machines on a daily basis. The word I disagree with in your comment is "working". The sources to the shipping FC4 anaconda file are available, which fulfills the license terms. *No one* guarantees that it is bug free or will work for you. > Redhat needs the money it charges for a 64-bit version of Linux; > it is not going to give away a working version of 64-bit Linux > until the revenue picture clears up. I'm writing this right now on my 64-bit FC4 machine which has been working fine for me. Redhat have fixed this bug in the FC5 tree and in an RHEL4 update. Both of which are the next releases of the respective products. The anaconda sources for both OS's are available for download. Since FC5 hasn't been released yet, you'll have to grab them from the development tree. FWIW - I'd like to see fixed up FC4 ISO's available too, but it won't happen. If you read the archives of the Fedora mailing lists you'll see that the trade-offs involved with re-spinning the ISO's vs waiting for the next release have been discussed several times.
I have the FC5 Test 2 ISO's Will the fixes be in these disks? Since I am not a Linux Guru and cannot afford the time to learn all the issues right now. Can you help me? I am not sure what I need off your site to get this working with the FC4. Can you tell me specifically what files I should download and where to download these from to fix this issue? Thanks, Jerry Roy jroy@goremote.com (In reply to comment #55) > (In reply to comment #50) > > Created an attachment (id=119953) [edit] [edit] > > Anaconda Dump > > Neither a re-install using the same partioning options or the zeroing of the > > partion utilizing the Rescue mode solved errors being experienced. Every > > installation attempt performed was made using the default options presented by > > the installation gui. The attachment is a dump to floppy option presented > > during the prompt when the error was experienced. The methodology of > > utilization of the presented patch in an earlier response would be > appreciated, > > as experience levels vary among users. > So how do I fix this problem? I tried a re-install and it keeps repeating over > and over.
My best advice would be to wait a week for the formal FC5 release and then use that. This assumes things are still keeping to the published schedule at http://fedora.redhat.com/About/schedule/ If you've not had any experience with installing a test releases before then it is probably too late now to install it and hope to get any useful feedback for the FC5 release. While it is possible to download the fixes and rebuild things yourself to fix FC4. I wouldn't advise doing it. I've not done it myself and i'm afraid I don't have the time to try to discuss all the steps involved. For one reference to someone that has done something like this see http://www.redhat.com/archives/fedora-devel-list/2005-September/msg00314.html You might find some of the replies interesting too. Note: AFAICT these respun CD's DO NOT have the anaconda fix for this bug, but they do have other bugs fixed. Again, personally, i'd wait for FC5.
*** Bug 185159 has been marked as a duplicate of this bug. ***
*** Bug 184093 has been marked as a duplicate of this bug. ***
*** Bug 185684 has been marked as a duplicate of this bug. ***
*** Bug 185790 has been marked as a duplicate of this bug. ***
*** Bug 186328 has been marked as a duplicate of this bug. ***
*** Bug 193466 has been marked as a duplicate of this bug. ***
*** Bug 197756 has been marked as a duplicate of this bug. ***
*** Bug 196683 has been marked as a duplicate of this bug. ***
*** Bug 220801 has been marked as a duplicate of this bug. ***