Bug 1003171 - Cd check fails sometimes with usb media
Summary: Cd check fails sometimes with usb media
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-08-31 11:55 UTC by Aniruddha
Modified: 2013-09-27 17:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-09-27 17:57:56 UTC
Type: Bug

Attachments (Terms of Use)

Description Aniruddha 2013-08-31 11:55:19 UTC
I copied the Fedora 19 install dvd to usb with dd. I booted from the usb and choose "Test this media & install Fedora 19" The result was "Pass"

When I booted the usb on another pc and ran "Test this media & install Fedora 19" I got the error message below, always around 5% I think this is because the installer image can not be found:

[    9.371594] localhost kernel: sd 6:0:0:0: [sdc] No Caching mode page present
[    9.371599] localhost kernel: sd 6:0:0:0: [sdc] Assuming drive cache: write through
[    9.371602] localhost kernel: sd 6:0:0:0: [sdc] Attached SCSI removable disk
[    9.275544] localhost multipathd[132]: path checkers start up
[    9.275672] localhost multipathd[132]: sdd: add path (uevent)
[    9.363695] localhost multipathd[132]: sdc: add path (uevent)
[    9.890120] localhost multipathd[132]: sda: add path (uevent)
[    9.890272] localhost multipathd[132]: sda: spurious uevent, path already in pathvec
[    9.894900] localhost multipathd[132]: sdb: add path (uevent)
[    9.895004] localhost multipathd[132]: sdb: spurious uevent, path already in pathvec
[   10.713764] localhost dracut-initqueue[429]: anaconda using disk root at /dev/sdd
[   10.875838] localhost kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
[   10.877746] localhost kernel: ISO 9660 Extensions: RRIP_1991A
[   10.774333] localhost dracut-initqueue[429]: anaconda: found /run/install/repo//LiveOS/squashfs.img
[   10.945419] localhost kernel: bio: create slab <bio-1> at 1
[   10.897345] localhost systemd[1]: Starting Media check on /dev/sdd...
[   18.982674] localhost systemd[1]: checkisomd5@-dev-sdd.service: main process exited, code=exited, status=1/FAILURE
[   18.982855] localhost systemd[1]: Failed to start Media check on /dev/sdd.
[   18.983069] localhost systemd[1]: Unit checkisomd5@-dev-sdd.service entered failed state.
[   18.983252] localhost dracut-initqueue[429]: Job for checkisomd5@-dev-sdd.service failed. See 'systemctl status checkisomd5@-dev-sdd.service' and 'journalctl -xn' for details.
[   18.984770] localhost dracut-initqueue[429]: Warning:
[   18.984886] localhost dracut-initqueue[429]: Warning: dracut: FATAL: CD check failed!
[   18.985015] localhost dracut-initqueue[429]: Warning: dracut: Refusing to continue
[   19.083423] localhost dracut: FATAL: CD check failed!
[   19.083435] localhost dracut: Refusing to continue
[   18.987683] localhost systemd[1]: Starting Dracut Emergency Shell...

Comment 1 Steve Tyler 2013-08-31 23:31:59 UTC
Thanks for your report.

What do you get if you run checkisomd5 from the installer shell console?

# /bin/checkisomd5 --verbose /dev/sdd

Also, could you post the exact dd command you used to make the copy?

Comment 2 Steve Tyler 2013-08-31 23:51:40 UTC
Could you attach the complete output of "journalctl -x"?

I don't see anything in the snippet in Comment 0 about /dev/sdd being mounted.

Comment 3 Steve Tyler 2013-09-01 14:39:04 UTC
(In reply to Aniruddha from comment #0)
> [   18.987683] localhost systemd[1]: Starting Dracut Emergency Shell...

I just noticed that you dropped into the dracut shell.

There should be directions for finding the relevant log file and getting it off the system. The log file should be in:


Could you attach sosreport.txt as an uncompressed, "text/plain" file?

And the component should probably be dracut, not anaconda.

Comment 4 Brian Lane 2013-09-27 17:57:56 UTC
Most likely you have a bad USB stick. You can check it after writing it by running checkisomd5 -v /dev/device from the cmdline as root.

Note You need to log in before you can comment on or make changes to this bug.