Hide Forgot
During the " Examining Devices " phase of Fedora16 installer on a system with multipath, it will not detect an existing operating system even when one is present. This was done using the following Fedora16 DVD installer http://ppc.koji.fedoraproject.org/scratch/karsten/iso/RC3/ppc64/iso/Fedora-16-ppc64-DVD.iso I am not able to do a "vnc" install with this media because it doesn't let me configure the IP address of my system. Instead it skips that and launches the VNC session and gives an IP address that isn't valid for my network (172.16.254.252:1) So instead I did a "serial" install (linux serial debug=1) and went through the text GUI menus. However, with this install method I don't have an option for "Specialized Storage Devices". I do have logs from a previous Fedora16 build where I was able to use the VNC installer (fc16 beta rc 6). == Comment: 2012.01.05 14:31:50 == Discovered a couple workarounds for the network config issue. From the yaboot prompt use the following kernel options linux vnc debug=1 sshd=1 ip=<ip_address> netmask=<netmask_address> gateway=<gateway_address> dns=<dns_address> or linux vnc debug=1 sshd=1 asknetwork == Comment: 2012.01.06 10:59:18 == [anaconda root@pfdioc03b tmp]# udevadm test --action=change /devices/virtual/block/dm-8 run_command: calling: test adm_test: version 173 parse_file: reading '/lib/udev/rules.d/10-dm.rules' as rules file parse_file: reading '/lib/udev/rules.d/11-dm-lvm.rules' as rules file parse_file: reading '/lib/udev/rules.d/13-dm-disk.rules' as rules file parse_file: reading '/lib/udev/rules.d/40-libgphoto2.rules' as rules file parse_file: reading '/lib/udev/rules.d/40-multipath.rules' as rules file parse_file: reading '/lib/udev/rules.d/40-ppc.rules' as rules file parse_file: reading '/lib/udev/rules.d/42-qemu-usb.rules' as rules file parse_file: reading '/lib/udev/rules.d/50-firmware.rules' as rules file parse_file: reading '/lib/udev/rules.d/50-udev-default.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-cdrom_id.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-floppy.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-net.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-pcmcia.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-persistent-alsa.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-persistent-input.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-persistent-serial.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-persistent-storage-tape.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-persistent-storage.rules' as rules file parse_file: reading '/lib/udev/rules.d/60-persistent-v4l.rules' as rules file parse_file: reading '/lib/udev/rules.d/61-accelerometer.rules' as rules file parse_file: reading '/lib/udev/rules.d/64-md-raid.rules' as rules file parse_file: reading '/lib/udev/rules.d/65-libsane.rules' as rules file parse_file: reading '/lib/udev/rules.d/65-md-incremental.rules' as rules file parse_file: reading '/lib/udev/rules.d/69-cd-sensors.rules' as rules file parse_file: reading '/lib/udev/rules.d/70-anaconda.rules' as rules file parse_file: reading '/etc/udev/rules.d/70-persistent-cd.rules' as rules file parse_file: reading '/etc/udev/rules.d/70-persistent-net.rules' as rules file parse_file: reading '/lib/udev/rules.d/70-uaccess.rules' as rules file parse_file: reading '/lib/udev/rules.d/70-wacom.rules' as rules file parse_file: reading '/lib/udev/rules.d/71-seat.rules' as rules file parse_file: reading '/lib/udev/rules.d/73-seat-late.rules' as rules file parse_file: reading '/lib/udev/rules.d/75-cd-aliases-generator.rules' as rules file parse_file: reading '/lib/udev/rules.d/75-net-description.rules' as rules file parse_file: reading '/lib/udev/rules.d/75-persistent-net-generator.rules' as rules file parse_file: reading '/lib/udev/rules.d/75-probe_mtd.rules' as rules file parse_file: reading '/lib/udev/rules.d/75-tty-description.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-ericsson-mbm.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-longcheer-port-types.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-platform-serial-whitelist.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-simtech-port-types.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-usb-device-blacklist.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-x22x-port-types.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-mm-zte-port-types.rules' as rules file parse_file: reading '/lib/udev/rules.d/77-nm-olpc-mesh.rules' as rules file parse_file: reading '/lib/udev/rules.d/78-sound-card.rules' as rules file parse_file: reading '/lib/udev/rules.d/80-drivers.rules' as rules file parse_file: reading '/lib/udev/rules.d/80-mm-candidate.rules' as rules file parse_file: reading '/etc/udev/rules.d/91-drm-modeset.rules' as rules file parse_file: reading '/lib/udev/rules.d/95-cd-devices.rules' as rules file parse_file: reading '/lib/udev/rules.d/95-dm-notify.rules' as rules file parse_file: reading '/lib/udev/rules.d/95-keyboard-force-release.rules' as rules file parse_file: reading '/lib/udev/rules.d/95-keymap.rules' as rules file parse_file: reading '/lib/udev/rules.d/95-udev-late.rules' as rules file parse_file: reading '/run/udev/rules.d/99-live-mount.rules' as rules file parse_file: reading '/lib/udev/rules.d/99-systemd.rules' as rules file udev_rules_new: rules use 153168 bytes tokens (12764 * 12 bytes), 27993 bytes buffer udev_rules_new: temporary index used 50120 bytes (2506 * 20 bytes) udev_device_new_from_syspath: device 0x100235d0650 has devpath '/devices/virtual/block/dm-8' udev_device_new_from_syspath: device 0x100235db410 has devpath '/devices/virtual/block/dm-8' udev_device_read_db: device 0x100235db410 filled with db file data udev_rules_apply_to_event: LINK 'mapper/mpathbp3' /lib/udev/rules.d/10-dm.rules:114 udev_rules_apply_to_event: RUN 'socket:/org/kernel/dm/multipath_event' /lib/udev/rules.d/40-multipath.rules:16 udev_rules_apply_to_event: GROUP 6 /lib/udev/rules.d/50-udev-default.rules:68 udev_event_execute_rules: no node name set, will use kernel supplied name 'dm-8' udev_node_add: creating device node '/dev/dm-8', devnum=253:8, mode=0660, uid=0, gid=6 udev_node_mknod: preserve file '/dev/dm-8', because it has correct dev_t udev_node_mknod: preserve permissions /dev/dm-8, 060660, uid=0, gid=6 node_symlink: preserve already existing symlink '/dev/block/253:8' to '../dm-8' link_find_prioritized: found 'b253:8' claiming '/run/udev/links/mapper\x2fmpathbp3' link_update: creating link '/dev/mapper/mpathbp3' to '/dev/dm-8' node_symlink: preserve already existing symlink '/dev/mapper/mpathbp3' to '../dm-8' udev_device_update_db: created db file '/run/udev/data/b253:8' for '/devices/virtual/block/dm-8' This program is for debugging only, it does not run any program, specified by a RUN key. It may show incorrect results, because some values may be different, or not available at a simulation run. UDEV_LOG=6 DEVPATH=/devices/virtual/block/dm-8 MAJOR=253 MINOR=8 DEVNAME=/dev/dm-8 DEVTYPE=disk ACTION=change SUBSYSTEM=block DM_SBIN_PATH=/sbin DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 DM_NAME=mpathbp3 DM_UUID=part3-mpath-35000c50017b69adf DM_SUSPENDED=0 DEVLINKS=/dev/mapper/mpathbp3 MPATH_SBIN_PATH=/sbin TAGS=:systemd: run: 'socket:/org/kernel/dm/multipath_event' <dlehman> that's what we want <dlehman> is one of the mpath's paths failed? <hamzy> like disk error? <dlehman> the device-mapper rules are setting a flag that means anaconda's rules, along with many other standard rules, should ignore these devices <dlehman> the flag is DM_UDEV_DISABLE_DISK_RULES_FLAG <dlehman> I'll just paste the udev rules that can set that flag <dlehman> ENV{DM_UUID}=="mpath-?*", ENV{DM_ACTION}=="PATH_FAILED", GOTO="dm_disable" <dlehman> ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_disable" <dlehman> ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="dm_disable" <dlehman> ENV{DISK_RO}=="1", GOTO="dm_disable" <dlehman> so, I don't know exactly how any of those work, but it looks like: a failed path in an mpath, a temporary cryptsetup device node, or a read-only disk <hamzy> the SAS card is saying that the multipath path has failed? <dlehman> DM_ACTION==PATH_FAILED sounds to me like one of the disks/paths became unavailable == Comment 2012.01.16 15:16:54 == I formatted the two hard drives as pdisk and created a RAID 0 array. I was then able to do an installation of Fedora16 onto the RAID 0 array without issues. However, we're still hitting this bug when trying to do an install over the existing one. The installer doesn't detect the existing installation and prompt the user. Also, the system that's displaying these issues is being replaced but I'm going to talk to our hardware coordinator to make sure we get the same type of SAS RAID configuration on the new system so we can continue this effort. == Comment: #5 - 2012.01.23 10:34:22 == The installer is running in a multipath environment at the first screen. I then ssh into the system to poke around. I notice that, if I enable multipath, then I do not see any problems with udev. [anaconda root@pfdioc03b ~]# cat << __EOF__ > /etc/multipath.conf # multipath.conf written by anaconda defaults { user_friendly_names yes } blacklist { devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z]" devnode "^dcssblk[0-9]*" device { vendor "DGC" product "LUNZ" } device { vendor "IBM" product "S/390.*" } # don't count normal SATA devices as multipaths device { vendor "ATA" } # don't count 3ware devices as multipaths device { vendor "3ware" } device { vendor "AMCC" } # nor highpoint devices device { vendor "HPT" } } multipaths { } __EOF__ [anaconda root@pfdioc03b ~]# multipath create: mpatha (1IBM IPR-0 1B87E0C4CEFF65C4) undef IBM,IPR-0 1B87E0C4 size=260G features='1 queue_if_no_path' hwhandler='1 alua' wp=undef |-+- policy='round-robin 0' prio=50 status=undef | `- 1:255:0:0 sdb 8:16 undef ready running `-+- policy='round-robin 0' prio=10 status=undef `- 0:255:0:0 sda 8:0 undef ready running [anaconda root@pfdioc03b ~]# dmsetup status -v | egrep "(Name|State)" Name: mpathap2 State: ACTIVE Name: mpathap1 State: ACTIVE Name: mpatha State: ACTIVE Name: live-rw State: ACTIVE Name: mpathap3 State: ACTIVE [anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test --action=change /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done === dm-0 === DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-1 === DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-2 === DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-3 === DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-4 === DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 I then navigate the installer to select the multipath device and where it should detect the previously installed system. However, it is now at the hostname screen. [anaconda root@pfdioc03b ~]# dmsetup status -v | egrep "(Name|State)" Name: mpathap2 State: ACTIVE Name: mpathap1 State: ACTIVE Name: mpatha State: ACTIVE Name: live-rw State: ACTIVE Name: mpathap3 State: ACTIVE [anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test --action=change /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done === dm-0 === DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-1 === DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-2 === DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-3 === DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 === dm-4 === DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 Notice that udev now has the DM_UDEV_DISABLE_DISK_RULES_FLAG flag set?
------- Comment From hamzy.com 2012-01-23 14:10 EDT------- [anaconda root@pfdioc03b ~]# vi /lib/udev/rules.d/10-dm.rules [anaconda root@pfdioc03b ~]# cp /lib/udev/rules.d/10-dm.rules /etc/udev/rules.d/ [anaconda root@pfdioc03b ~]# udevadm control --reload-rules [anaconda root@pfdioc03b ~]# multipath -F [anaconda root@pfdioc03b ~]# ls -l /sys/devices/virtual/block total 0 drwxr-xr-x. 8 root root 0 Jan 23 16:32 dm-0 drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop0 drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop1 drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop2 drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop3 drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop4 drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop5 drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop6 drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop7 Okay, I modified /lib/udev/rules.d/10-dm.rules to the above attached file. I then pressed the back button in the installer to the first screen. After unloading the multipath device and reloading udev rules, I went through the selection screens until the point where the existing OS should be detected (but hostname screen is shown). DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 As you can see above, I am not creating a debug environment variable for one of the dm_disable conditions. It looks like it was imported from somewhere via: IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"
Created attachment 557033 [details] 10-dm.rules file with extra debugging variables ------- Comment (attachment only) From hamzy.com 2012-01-23 14:04 EDT-------
------- Comment From hamzy.com 2012-01-23 14:26 EDT------- I also check to see if /lib/udev/rules.d/11-dm-lvm.rule was setting the flag, but it does not look that way. [anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test --action=change /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1 DM_UDEV_HAMZY_START=1 DM_UDEV_HAMZY_START2=1 DM_UDEV_HAMZY_START3=1 DM_UDEV_HAMZY_START4=1 DM_UDEV_HAMZY_START5=1 DM_UDEV_HAMZY_START6=1 DM_UDEV_DISABLE_DISK_RULES_FLAG=1 DM_UDEV_HAMZY_DONE=1 DM_UDEV_YZMAH_START=1 DM_UDEV_YZMAH_START1=1 DM_UDEV_YZMAH_START2=1 DM_UDEV_YZMAH_LVM_DONE=1
Hey Harald, Can you take a look at this defect? I don't know DM_UDEV_DISABLE_DISK_RULES_FLAG is being set. It seems that the line: IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG" Is pulling this flag from an internal database. What code is setting that flag inside udev?
Created attachment 557310 [details] 11-dm-lvm.rules file with extra debugging variables ------- Comment (attachment only) From hamzy.com 2012-01-24 15:41 EDT-------
(In reply to comment #4) > Hey Harald, > > Can you take a look at this defect? I don't know > DM_UDEV_DISABLE_DISK_RULES_FLAG is being set. It seems that the line: > > IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG" > > Is pulling this flag from an internal database. What code is setting that flag > inside udev? you have to ask the device-mapper/lvm guys. It's their flag, which they store in the udev DB
basically, I think, it's because, if they have already seen the dm device and it's disabled, they set the flag in "/lib/udev/rules.d/10-dm.rules" Just read 10-dm.rules (and watch for "dm_disable") and ask the device-mapper team for details.
------- Comment From hamzy.com 2012-01-25 10:29 EDT------- As I've stated previously in the defect, I've included 10-dm.rules in this defect with a debugging version and none of the dm_disable gotos are being executed.
Hey Doug, Could you take a look at this defect for me. I am trying to understand how this flag is being set in udev. How does the device-mapper/lvm2 code store this flag in the udev database? I am not seeing it set by the udev rules. Do you have some special API to tell udev to set flags?
Also, Harald, have I written 10-dm.rules correctly to debug this problem?
I'm not the right person to answer your questions. I handle the MD raid stuff, not the LVM/Multipath stuff. However, I would suggest looking in 40-multipath.rules as those are going to be relevant to these multipath devices. And I know they want to reference a multipath configuration file on the system during normal operation, I don't know if they are managing to pull that configuration off the hard disk during an upgrade however.
Hi Kay, Can you help me debugging this problem? Have I written 10-dm.rules correctly to debug this problem?
I suspect Ben Marzinski knows a lot more about the multipath part here as he's maintaining the device-mapper-multipath component. Anything you can see here going wrong, Ben? Thanks & regards, Phil
Multipathd set that flag in order to keep blkid from running whenever the device is reloaded. If all paths are down and multipath is queueing IO, this will keep the the device stuck open. Unfortunately this is causing problems with reinstalls. The issue is that if udev doesn't run blkid on every udev change event, the data is removed from the udev database. It's possible to fix this in 10-dm.rules, but not without causing other issues. Since devices that are set to queue forever when all paths are down can get stuck open on any IO that happens to them after all paths have failed, we decided that solving this one case wasn't worth the other complications it created, so the patch that sets that flag will get removed in RHEL and fedora. I'm re-assigning this bug to device-mapper-multipath, unless anyone has any objections.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is 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" 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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.