From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 Description of problem: On boot, get several disturbing messages, "File descriptor 3 left open". This happens on three different PC systems (SCSI, IDE, and Virtual PC), which were automatically partitioned with Disk Druid using LVM2. The systems seem to run fine on the surface. However, I'm worried these are indicators of file system problems. I didn't know whether to classify this as a problem with my installation (me), with grub, anaconda, with nash, or the kernel. root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.9-5.0.5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet [Linux-bzImage, setup=0x1400, size=0x15cc3e] initrd /initrd-2.6.9-5.0.5.EL.img [Linux-initrd @ 0xfef1000, 0xee087 bytes] Uncompressing Linux... Ok, booting the kernel. audit(1115133862.314:0): initialized Red Hat nash version 4.1.18 starting File descriptor 3 left open Reading all physical volumes. This may take a while /dev/hdc: open failed: No medium found Found volume group "VolGroup00" using metadata type lvm2 File descriptor 3 left open 2 logical volume(s) in volume group "VolGroup00" now active File desriptor 3 left open INIT: version 2.85 booting Version-Release number of selected component (if applicable): kernel-2.6.9-5.0.5EL grub-0.95-3.1 How reproducible: Always Steps to Reproduce: 1. Boot into Linux 2. 3. Actual Results: Boot messages report, "File descriptor 3 left open" Expected Results: If there is no problem, then report success or be silent. The phrasing that something is "left open" evokes despondency akin to "the barn door was left open, and all the horses are missing". Additional info: Here is the text of /boot/grub/grub.conf: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux AS (2.6.9-5.0.5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.0.5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-5.0.5.EL.img title Red Hat Enterprise Linux AS (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-5.EL.img
I am seeing the exact same problem with my new install of Red Hat Desktop (v. 4 for 32-bit x86). This bug did not occur with Fedora Core v. 3
I also see this on a Dell c800 Latitude laptop used for QA/Testing. This problem did not occur with v9. I have RHEL AS v4 Update 1 for 32-bit x86. There does seem to be something wrong with the filesystem because Acronis 8 detects a problem and will not image the drive except by sector. Even when the OS is shutdown/halted normally I get this message. Is there any fix for this issue yet?
A similar error has been reported in Bugzilla Bug 156854 â panic in lvm on start up of x86_64 mach Maybe these are related?
I just installed x86_64 RHEL 4 ES Update 1 on a Tyan S2676 with two 3.6G Xeons. The file system configuration is four 73G U320 drives with the second two being RAID1 mirrors of the first two. The first drive consists of one partition for /boot and an LVM2 physical volume. The second drive is one big LVM2 PV. The two LVM2 PVs are configured as one volume group with ten logical volumes. I did an "everything" installation. On rebooting, the system hangs for over a minute after printing the nash version and then gives me the "File descriptior 3 left open" messages as above. As for classifying the problem, personally, I suspect that it's an LVM2 since it appears that it's the part doing the complaining. So, I'm not sure whether I should deploy RHEL4 in a mission critical environment, yet.
I looked at it a bit more and it looks kinda like the kernel, while attempting to mount the root file systems, manages to run lvm somehow (I'm not a boot process guru, and I couldn't manage to grep it's secrets in the half hour I spent looking at this problem). If you look at _close_stray_fds() in lvmcmdline.c, you'll see that it tries to clean up any fd's that somehow managed to not get closed. There appears to be an LVM2 option to squelch that particular error message, but it would seem that the boot process is not using it. Anyway, the message appears to mean that a stray fd was identified and closed. Now, what particular LVM commands is being run (I only get two "left open" messages instead of the three that Ms. Fong reports) are still unknown to me, but it seems obvious that the code that implements it isn't closing all the files it opens and gets caught before the lvm command exits. This problem should probably be identified and fixed before the Update 2 errata is released (bug #158692).
I opened bug #167860 against lvm2. Someone should probably close this bug as a duplicate of it.
*** Bug 167860 has been marked as a duplicate of this bug. ***
The problem is actually in 'nash' in the mkinitrd package and is fixed in mkinitrd-4.2.1.4-1 which should be included in U2.