Red Hat Bugzilla – Full Text Bug Listing
|Summary:||udev "READ TOC" issue - livecd-creator fails to generate working livecd: boot has failed, sleeping forever|
|Product:||[Fedora] Fedora||Reporter:||Pasi Karkkainen <pasik>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||14||CC:||adam.stokes, bruno, dhuff, dwalsh, harald, Jasper.Hartline, jonathan, katzj, mishu, richard.dorsch, sagarun|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-16 12:34:50 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Pasi Karkkainen 2011-03-03 15:36:41 EST
Description of problem: I'm running livecd-creator on fully updated Fedora 14 (as of 3rd of March 2011). livecd-creator fails to generate working f14 livecd. Booting from livecd ISO image fails with "Boot has failed, sleeping forever". Screenshot URL of the livecd boot console kernel messages here: http://pasik.reaktio.net/fedora/f14/livecd-creator/f14-livecd-boot-has-failed.jpg So basicly the kernel detects the CD drive, but it fails to mount (livecd) root. Version-Release number of selected component (if applicable): livecd-tools-14.2-1.fc14.x86_64 squashfs-tools-4.1-2.fc14.x86_64 How reproducible: Always. Steps to Reproduce: 1. (on a fully updated fedora 14 host) yum install livecd-tools 2. livecd-creator --config=f14.ks --cache=/var/cache/livecd-f14 3. boot physical machine from the ISO image. Actual results: Boot fails with "Boot has failed, sleeping forever". Expected results: Boot works and livecd-root gets mounted. Additional info: I've with and without f14 updates-repo for the livecd. kickstart-script to generate the minimal f14 livecd: # cat f14.ks lang en_US.UTF-8 keyboard fi timezone Europe/Helsinki auth --useshadow --enablemd5 selinux --disabled firewall --disabled part / --size 1024 repo --name=f14 --mirrorlist="http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-14&arch=i386" %packages @core anaconda-runtime bash kernel passwd policycoreutils chkconfig authconfig rootfiles # SELinux disabled requires this /usr/sbin/lokkit %end %post --nochroot # remove "quiet" and "rhgb" options to enable verbose startup cat $LIVE_ROOT/isolinux/isolinux.cfg | sed -e 's/ quiet //g' | sed -e 's/rhgb //g' > /tmp/test.cfg cp /tmp/test.cfg $LIVE_ROOT/isolinux/isolinux.cfg echo "echo testing testing.. " >> $INSTALL_ROOT/etc/rc.local echo "sleep 20" >> $INSTALL_ROOT/etc/rc.local %end
Comment 1 Richard Vidal-Dorsch 2011-03-03 16:07:36 EST
I think there is something missing in your ks file First check this page http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo Use a kickstart from /usr/share/spin-kickstart/*.ks Then build your LiveCD based on one of those ks.
Comment 2 Pasi Karkkainen 2011-03-03 16:28:13 EST
I used the example kickstart script from /usr/share/doc/livecd-tools-14.2/livecd-fedora-minimal.ks with some small additions . I'll try with /usr/share/spin-kickstarts/fedora-live-mini.ks and see how that goes.
Comment 3 Pasi Karkkainen 2011-03-03 16:53:14 EST
I generated f14 livecd using non-modified /usr/share/spin-kickstarts/fedora-live-mini.ks and it fails to boot with the following errors: No root device found No root device found Boot has failed, sleeping forever. So it's the same problem as with my custom kickstart script .. Any ideas?
Comment 4 Pasi Karkkainen 2011-03-03 17:37:25 EST
I did some more testing: - The generated f14 livecd images do work OK on qemu. - The generated f14 livecd images do NOT work on physical hardware. On physical hardware livecd kernel does detect the CD drive OK (as can be seen in the screenshot in the original report above) but for some reason it is not able to mount the livecd root fs. Is there any way to debug this further?
Comment 5 Pasi Karkkainen 2011-03-03 17:47:39 EST
Oh, and I forgot to mention that the official (GA) Fedora 14 installer ISO image does work fine on the same physical hardware where my self-generated f14 livecd fails to mount the root fs from the cd.
Comment 6 Richard Vidal-Dorsch 2011-03-03 19:33:41 EST
OK, so you built a LiveCD based on a known kickstart file. The LiveCD creator downloads databases (sqlite files) from Fedora repositories (and mirrors). It could be that one or some database files were downloaded at the time when a mirror was synced which could have "confused" the livecd-creator. However, you could delete the local cache directory and then re-build a standard LiveCD.
Comment 7 Arun S A G 2011-03-03 22:08:58 EST
(In reply to comment #6) > OK, so you built a LiveCD based on a known kickstart file. > > The LiveCD creator downloads databases (sqlite files) from Fedora repositories > (and mirrors). It could be that one or some database files were downloaded at > the time when a mirror was synced which could have "confused" the > livecd-creator. However, you could delete the local cache directory and then > re-build a standard LiveCD. Please do not speculate, have you tried to reproduce the bug?
Comment 8 Richard Vidal-Dorsch 2011-03-04 01:12:51 EST
Created attachment 482229 [details] Screenshot of a successful fedora 14 minimal build
Comment 9 Richard Vidal-Dorsch 2011-03-04 02:10:03 EST
> Please do not speculate, have you tried to reproduce the bug? I just uploaded a screen shot which shows a successful boot of a Fedora 14 minimal LiveCD. I also built a Desktop variant based on GNOME. Both LiveCDs boot in my VMware and on physical HW. I have to admit that what I wrote sounds a bit far fetched - if you just read my last post. In fact, other people had reported a similar, if not the same bug, in another bug report. https://bugzilla.redhat.com/show_bug.cgi?id=624028 Please also read comment 37 - Jeff Cook's reply https://bugzilla.redhat.com/show_bug.cgi?id=624028#c37 I am building Fedora LiveCDs almost every day. I ran into a similar issue where I could not find the root cause why my LiveCDs would not boot properly. I tried numerous scenarios but all of them failed, except one. I deleted the /var/cache/live directory, the livecd-creator's cache directory - et voilà! This solved my problem. I have to say that I had difficulties, at that time, in downloading packages from the fedora repository and mirror servers. This may have caused this issue I ran into.
Comment 10 Pasi Karkkainen 2011-03-04 02:19:02 EST
I've started from scratch multiple times, ie. I've deleted the cache directory. And I've tried with and without fedora updates repo (for the livecd). And it just doesn't seem to work.. Any other ideas how to debug that? Does anaconda/plymouth/something have kernel parameters I could use to get more debug output at boot time? Thanks for the reply.
Comment 11 roberto agria 2011-03-07 06:11:37 EST
Hi, i've donwloaded a fedora 14 live iso, used liveusb creator to write on usb pen, and then the same error already reported in this thread appeared. It wasn't my first time with liveusb creator, but since F14 it's not working anymore. I've repeated the procedure several time, with no success even trying to modify the parameter root=live:UUID=xxxx in root=live:LABEL=FEDORA trick. The bug is serious, many people avoids joining Fedora cause of this bug. Thanks.
Comment 12 Bruno Wolff III 2011-03-07 08:30:53 EST
Removing the the quiet and rhgb kernel parameters should let you see more of what is happening during boot.
Comment 13 Pasi Karkkainen 2011-03-07 08:39:01 EST
I already removed "quiet" and "rhgb" options.. the screenshot above shows the "full" boot messages. Does dracut/plymouth/anaconda have some options I could use to get more verbose output during livecd boot/startup?
Comment 14 Bruno Wolff III 2011-03-07 10:26:38 EST
I just tested a freshly built F14 spin (Desktop with updates-testing and the latest F14 kernel from koji) and it booted up just fine on both optical media and a USB built using livecd-iso-to-disk. So likely there is either a hardware/bios factor or liveusb-creator issue. If you are using liveusb-creator, it needs to be using a recent syslinux. If it is using something before version 4, it isn't going to work.
Comment 15 Brian Lane 2011-03-07 10:49:27 EST
(In reply to comment #11) > Hi, i've donwloaded a fedora 14 live iso, used liveusb creator to write on usb > pen, and then the same error already reported in this thread appeared. > It wasn't my first time with liveusb creator, but since F14 it's not working > anymore. I've repeated the procedure several time, with no success even trying > to modify the parameter root=live:UUID=xxxx in root=live:LABEL=FEDORA trick. > The bug is serious, many people avoids joining Fedora cause of this bug. > Thanks. liveusb-creator is a separate program, used to write existing iso's to USB. livecd-creator, which this bug is about, is used to create new iso's with different or updated content. If you have a problem with liveusb-creator please file a bug against that component.
Comment 16 Jasper O'neal Hartline 2011-03-07 23:37:40 EST
Pasi, can you upload the faulty ISO disc image file somewhere it can be downloaded and examined for errors? This at least will give us something to work with in determining your issue if it is in fact not an issue with the livecd-tools package. Upload the ISO file so it can be downloaded and tested for any error.
Comment 17 Richard Vidal-Dorsch 2011-03-08 05:24:50 EST
Pasi, I used your f14.ks file and built a minimal LiveCD. This LiveCD did not boot in my VMware as shown in the screen-shot (f14-no-boot.jpg). The boot loader configuration file isolinux.cfg is empty. Then I also rebuilt fedora-live-mini.ks from the Fedora 14 spin-kickstart package. Which resulted in a bootable LiveCD but got stuck in the boot process. I found out that the prefdm (located in /etc/X11/) tried to launch one of the supported display managers. It is a bit odd since the minimal LiveCD is not suppose to boot into a Desktop Environment so I checked the /etc/inittab for the default runlevel; it was set to runlevel 5 which is X11 (GUI). I spent some time in narrowing down the root cause until I realized the it was right in front of me... At line 11 of fedora-live-mini.ks xconfig --startxonboot This was the trouble maker (on my side). I do not know if this will solve the issue on your side. Just delete this line or comment it with a # and everything should work. The new created LiveCD runs in my VMware and on real HW.
Comment 18 Richard Vidal-Dorsch 2011-03-08 05:26:39 EST
Created attachment 482868 [details] LiveCD built based on f14.ks does not boot
Comment 19 Richard Vidal-Dorsch 2011-03-08 05:50:57 EST
Oops! Copy-Paste issue! Pasi, I was able to build a bootable LiveCD based on your f14.ks. When I copy-pasted the kickstart it accidentally wrapped a line to the next line. Screen-shot attached. It shows the firstboot. Please verify your image(s) with another VM.
Comment 20 Richard Vidal-Dorsch 2011-03-08 05:52:32 EST
Created attachment 482871 [details] LiveCD built based on f14.ks boots successfully
Comment 21 Pasi Karkkainen 2011-03-08 14:35:15 EST
I've uploaded f14 custom livecd iso-image here: http://pasik.reaktio.net/fedora/f14/livecd-creator/livecd-f14-test-201103081655.iso . It doesn't have any F14 updates included. ks.cfg used to generate the iso is here: http://pasik.reaktio.net/fedora/f14/livecd-creator/f14-test.ks . that ISO boots in Qemu but it doesn't boot on physical hardware (baremetal server). Official F14 installer CD does boot OK on the same physical server. Here's the command I used to build the livecd (on a fully updated f14): livecd-creator --config=f14-test.ks --cache=/var/cache/livecd-f14-test
Comment 22 Pasi Karkkainen 2011-03-08 14:43:10 EST
I also tried booting the livecd on physical server and adding "rdshell" parameter.. and thus dracut gives me a shell. From the shell I'm able to mount /dev/sr0 just fine.. so I'm just wondering why the livecd is not able to mount root..
Comment 23 Richard Vidal-Dorsch 2011-03-09 12:58:12 EST
(In reply to comment #21) > that ISO boots in Qemu but it doesn't boot on physical hardware (baremetal > server). Official F14 installer CD does boot OK on the same physical server. I downloaded your ISO image and tested it with my VMware as well as with a Core i7/QM57 (Calpella) board. Works fine in both cases. Can you share the HW spec of your server with us?
Comment 24 Pasi Karkkainen 2011-03-14 10:06:04 EDT
Ok, thanks for testing. My physical machine is a server with Intel Xeon 5600 series CPUs and Intel 5520 chipset. It has remote management BMC with ISO/media emulation and I'm using that to remotely boot the ISO image. But like said, on the same physical server: - Official F14 GA installer CD/DVD boots and works just fine. - Official F14 GA liveCD does NOT boot, same problem, "No root device found" ! - My custom f14 livecd boot detects the CD drive (usb remote media) but doesn't mount it.. "No root device found" ! - If I add "rdshell" kernel boot option to my custom f14 livecd I get a shell, and I can mount the CD (/dev/sr0) just fine from there. So it's just the *live* boot that fails, for both the official livecd and my custom f14 livecd.. same problem with both. It seems like it's not even trying to mount the CD in that case.. at least it doesn't give any errors about the mount attempts.. Any further ideas?
Comment 25 Brian Lane 2011-03-14 16:54:30 EDT
It looks like this more likely to be a dracut problem.
Comment 26 Harald Hoyer 2011-03-15 05:25:00 EDT
Seems to a CDROM drive problem.. Does USB stick booting work?
Comment 27 Pasi Karkkainen 2011-03-15 05:32:22 EDT
I don't think it's a CDROM problem.. like said I can mount the CD just fine when going to a shell on my custom livecd. And other CD's work (including Fedora installer CD) fine. Should I file a new bug against dracut? Any ideas how to further troubleshoot this?
Comment 28 Richard Vidal-Dorsch 2011-03-15 05:53:17 EDT
(In reply to comment #27) > I don't think it's a CDROM problem.. like said I can mount the CD just fine > when going to a shell on my custom livecd. > > And other CD's work (including Fedora installer CD) fine. > > Should I file a new bug against dracut? Any ideas how to further troubleshoot > this? What do you mean by 'other CD's work'? Are you referring to - Fedora 14 Installation DVD - Fedora 14 LiveCD Both original version are working fine? If so, all versions (DVD & LiveCD including your custom LiveCD) are using dracut-006-3. If your custom LiveCD does not work properly but the Installation DVD and the original LiveCD do work then it must be something different. I would still try using a LiveUSB to make sure that it is really not related to the CDROM.
Comment 29 Harald Hoyer 2011-03-15 05:58:21 EDT
(In reply to comment #27) > I don't think it's a CDROM problem.. like said I can mount the CD just fine > when going to a shell on my custom livecd. > > And other CD's work (including Fedora installer CD) fine. > > Should I file a new bug against dracut? Any ideas how to further troubleshoot > this? Which version of dracut and udev is installed? What's the output of (in dracut rdshell): # udevadm info --query=property --name=/dev/sr0 # /lib/udev/cdrom_id --debug /dev/sr0
Comment 30 Pasi Karkkainen 2011-03-15 13:52:47 EDT
> > What do you mean by 'other CD's work'? Are you referring to > > - Fedora 14 Installation DVD > - Fedora 14 LiveCD > > Both original version are working fine? > - Fedora 14 Installation DVD works fine. - CentOS5 LiveCD works fine. - My custom-built f14 livecd does not work, "No root device found". - Fedora 14 (official) LiveCD does not work, same problem, "No root device found".
Comment 31 Pasi Karkkainen 2011-03-15 14:23:18 EDT
> > Which version of dracut and udev is installed? > in the livecd: dracut-006-3.fc14. udev version 161. > What's the output of (in dracut rdshell): > > # udevadm info --query=property --name=/dev/sr0 > # /lib/udev/cdrom_id --debug /dev/sr0 # udevadm info --query=property --name=/dev/sr0 UDEV_LOG=3 DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.3/1-5.3:1.0/host7/target7:0:0/7:0:0:0/block/sr0 MAJOR=11 MINOR=0 DEVNAME=/dev/sr0 DEVTYPE=disk SUBSYSTEM=block ID_CDROM=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_CD=1 ID_VENDOR=AMI ID_VENDOR_ENC=AMI\x20\x20\x20\x20\x20 ID_VENDOR_ID=046b ID_MODEL=Virtual_CDROM ID_MODEL_ENC=Virtual\x20CDROM\x20\x20\x20 ID_MODEL_ID=ff20 ID_REVISION=1.00 ID_SERIAL=AMI_Virtual_CDROM_serial-0:0 ID_SERIAL_SHORT=serial ID_TYPE=cd ID_INSTANCE=0:0 ID_BUS=usb ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_USB_DRIVER=usb-storage ID_PATH=pci-0000:00:1d.7-usb-0:5.3:1.0-scsi-0:0:0:0 DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-id/usb-AMI_Virtual_CDROM_serial-0:0 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:5.3:1.0-scsi-0:0:0:0 # /lib/udev/cdrom_id --debug /dev/sr0 main: probing: '/dev/sr0' cd_inquiry: INQUIRY: [AMI ][Virtual CDROM ][1.00] info_scsi_cmd_err: GET CONFIGURATION failed with SK=5h/ASC=20h/ACQ=00h cd_profiles: drive is pre-MMC2 and does not support 46h get configuration command cd_profiles: trying to work around the problem info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h cd_profiles_old_mmc: no current profile, but disc is present; assuming CD-ROM cd_media_toc: READ TOC: len: 12, start track: 1, end track: 1 cd_media_toc: last track 1 starts at block 0 info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h ID_CDROM=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_CD=1 Note that "mkdir /mnt && mount /dev/sr0 /mnt" works OK in rdshell !
Comment 32 Pasi Karkkainen 2011-03-30 16:26:06 EDT
Any ideas what to try?
Comment 33 Harald Hoyer 2011-03-31 02:56:26 EDT
(In reply to comment #31) > cd_inquiry: INQUIRY: [AMI ][Virtual CDROM ][1.00] > info_scsi_cmd_err: GET CONFIGURATION failed with SK=5h/ASC=20h/ACQ=00h > cd_profiles: drive is pre-MMC2 and does not support 46h get configuration > command > cd_profiles: trying to work around the problem > info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h > cd_profiles_old_mmc: no current profile, but disc is present; assuming CD-ROM > cd_media_toc: READ TOC: len: 12, start track: 1, end track: 1 > cd_media_toc: last track 1 starts at block 0 > info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h > ID_CDROM=1 > ID_CDROM_MEDIA=1 > ID_CDROM_MEDIA_CD=1 > Here is the problem... The virtual CDROM implements the "READ TOC" SCSI command in a broken way. It does not return details about the tracks on the CDROM. So, you would need a cdrom_id workaround. Could you try these udev packages? http://people.redhat.com/harald/downloads/udev/udev-147-2.35.el6/
Comment 34 Pasi Karkkainen 2011-03-31 04:49:16 EDT
Thanks! I'll try that. Just to make it sure: I install that udev version to the livecd filesystem, I assume udev for the boot image is fetched from there?
Comment 35 Pasi Karkkainen 2011-04-11 15:57:38 EDT
Harald: That el6 version of udev 147 works OK ! No problems mounting the livecd with that udev version. I rebuilt that udev 147 el6 src.rpm for f14 and then I did some ks install script %post hackery to "update" udev to 147 el6 version when generating livecd and to re-generate initramfs image and copy it over to isolinux/initrd0.img and now the generated f14 livecd works fine! So udev in fedora requires a workaround for this "READ TOC" issue! Here's the hackery I used to "update" to 147 udev in f14 livecd: # copy udev update for testing.. %post --nochroot cp -a /root/udev/rpm/libudev-147-2.35.fc14.i686.rpm $INSTALL_ROOT/tmp/ cp -a /root/udev/rpm/libgudev1-147-2.35.fc14.i686.rpm $INSTALL_ROOT/tmp/ cp -a /root/udev/rpm/udev-147-2.35.fc14.i686.rpm $INSTALL_ROOT/tmp/ %end # install udev update %post echo "Installing updated udev rpms.." rpm -Uvh --nodeps --force /tmp/libudev-147-2.35.fc14.i686.rpm /tmp/udev-147-2.35.fc14.i686.rpm /tmp/libgudev1-147-2.35.fc14.i686.rpm echo "done installing udev update." echo "Re-generating kernel initramfs image.." /sbin/dracut -f /boot/initramfs-184.108.40.206-45.fc14.i686.img 220.127.116.11-45.fc14.i686 echo "Done re-generating initramfs." %end # update isolinux/initrd0.img %post --nochroot echo "Copying new initramfs image to isolinux directory.." cp -af $INSTALL_ROOT/boot/initramfs-18.104.22.168-45.fc14.i686.img $LIVE_ROOT/isolinux/initrd0.img echo "Done copying initramfs." %end Thanks a lot!
Comment 36 Pasi Karkkainen 2011-04-12 02:41:15 EDT
udev "READ TOC" bug is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=690181 .
Comment 37 Harald Hoyer 2011-04-12 02:53:36 EDT
(In reply to comment #36) > udev "READ TOC" bug is tracked here: > https://bugzilla.redhat.com/show_bug.cgi?id=690181 . are you sure this is the same bug? are you using a iscsi cdrom?
Comment 38 Pasi Karkkainen 2011-04-12 03:38:20 EDT
Not totally sure.. I'm using virtual CDROM drive provided by the management processor in the server. Linux does see it as USB CDROM drive. Anyway udev-147-2.35.el6 works OK, while the 161 version in Fedora 14 fails to identify the livecd disc/iso.
Comment 39 Harald Hoyer 2011-04-12 04:22:36 EDT
(In reply to comment #38) > Not totally sure.. I'm using virtual CDROM drive provided by the management > processor in the server. Linux does see it as USB CDROM drive. exactly.. bug#690181 is about cdrom over iscsi, I think. So your bug is the incomplete READ TOC implementation of the virtal CDROM provided by the management processor in the server. So the server software is to be blamed.
Comment 40 Pasi Karkkainen 2011-04-12 04:48:58 EDT
Yes, the root cause is the buggy virtual cdrom drive in the server. But when it works just fine with another versions of udev, workaround should be added to udev. I'm pretty sure this affects many users. Note that for example CentOS5 livecd works just fine ! Also Fedora 14 official installer CD is happy with that virtual cdrom drive.
Comment 41 Brian Lane 2011-04-20 18:40:42 EDT
*** Bug 698444 has been marked as a duplicate of this bug. ***
Comment 42 Pasi Karkkainen 2011-04-29 13:29:02 EDT
Should I open a new bug against udev so that workaround for this problem can be included in udev?
Comment 43 Harald Hoyer 2011-05-02 05:38:04 EDT
I just reassigned it.
Comment 44 Pasi Karkkainen 2011-05-02 08:16:08 EDT
Great, thanks. Comment #31 has all the info about the virtual cdrom drive (provided by the server ipmi/bmc management processor). Summary: udev-147-2.35.el6 works OK, ie. "READ TOC" works OK, and f14 version of udev fails to identify the CD.
Comment 45 Pasi Karkkainen 2011-05-03 14:19:45 EDT
Is it expected that udev in F15 beta behaves differently? Should I try to generate a livecd based on F15 beta and try it on that server and see if F15 udev is able to identify the CD ?
Comment 46 Harald Hoyer 2011-05-04 04:47:19 EDT
(In reply to comment #45) > Is it expected that udev in F15 beta behaves differently? Should I try to > generate a livecd based on F15 beta and try it on that server and see if F15 > udev is able to identify the CD ? no, the bug is still there (upstream). I discussed it already with the udev author.
Comment 47 Pasi Karkkainen 2011-06-17 06:35:09 EDT
Any workarounds found for the udev "READ TOC" issue? Thanks.
Comment 48 Pasi Karkkainen 2011-07-11 10:11:20 EDT
Any updates? should I try with F15 ? (was there any related changes in udev in f15 ?)
Comment 49 Pasi Karkkainen 2011-08-10 08:00:40 EDT
Comment 50 Fedora Admin XMLRPC Client 2011-10-20 12:09:42 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 51 Fedora Admin XMLRPC Client 2011-10-20 12:11:47 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 52 Fedora Admin XMLRPC Client 2011-10-20 12:14:33 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 53 Fedora End Of Life 2012-08-16 12:34:53 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. 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 '14' 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 14 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