This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 681999

Summary: udev "READ TOC" issue - livecd-creator fails to generate working livecd: boot has failed, sleeping forever
Product: [Fedora] Fedora Reporter: Pasi Karkkainen <pasik>
Component: udevAssignee: udev-maint
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: adam.stokes, bruno, dhuff, dwalsh, harald, Jasper.Hartline, jonathan, katzj, mishu, richard.dorsch, sagarun
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 12:34:50 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Screenshot of a successful fedora 14 minimal build
none
LiveCD built based on f14.ks does not boot
none
LiveCD built based on f14.ks boots successfully none

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-2.6.35.6-45.fc14.i686.img 2.6.35.6-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-2.6.35.6-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
Ping ?
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