Description of problem: Using RHEL 6 Beta to try to create an F13 image. Followed the instructions under the following section to the letter with a formatted USB key with 1 partition: 3.2.2.1.2. Making Fedora USB Media with livecd-tools It simply does not work. Here's my input and the output: [root@Pandaberry ~]# livecd-iso-to-disk /home/duffy/Desktop/Fedora-13-x86_64-Live.iso /dev/sdb1 /usr/bin/livecd-iso-to-disk [--format] [--reset-mbr] [--noverify] [--overlay-size-mb <size>] [--home-size-mb <size>] [--unencrypted-home] [--skipcopy] <isopath> <usbstick device> I know the disk is /dev/sdb1. If I try /dev/sdb it performs a mediacheck on the iso image (it passes) but it doesn't put it on the USB stick. Version-Release number of selected component (if applicable): livecd-tools-031-1.fc12.1.x86_64 How reproducible: very Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
the dd directions didn't work either: [root@Pandaberry ~]# dd if=/home/duffy/Desktop/Fedora-13-x86_64-Live.iso of=/dev/sdb1 1386496+0 records in 1386496+0 records out 709885952 bytes (710 MB) copied, 6.92765 s, 102 MB/s mounted the key, had nothing on it but a lost+found directory.
so the install guide documentation says this: "su -c 'dd if=/path/to/image/file/imagefile.iso of=device'" the wiki page (https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB) says this: "$ dd if=F12-Live-i686.iso of=/dev/sdX bs=8M Note that you want the device name (e.g. /dev/sdx) not the partition name (e.g. /dev/sdx1). " While I'm fairly certain I tried both sdb and sdb1, using sdb with the bs=8M, dd seems to be making an actual effort to copy the image over now. It would be very nice if the install guide noted to not include the partition number the way the wiki page did.
*** This bug has been marked as a duplicate of bug 618071 ***
I have been through the pain of this also and I have the solution! As you say if you have the usbkey mounted then the livecd-iso-to-disk command fails, but how did you unmount it? What I found was that if you right click on the icon for the mounted usbkey and select eject then the stick umounts but does not put it in a mode that is correct for the use of the livecd-iso-to-disk command! However after a lot of messing about I have found that if you umount the partition of the stick that you want to write to using a terminal, and then as root do: # umount /dev/sdb1 and then # livecd-iso-to-disk --reset-mbr /path-to/Fedora-14-DVD.iso /dev/sdb1 It will likely work fine and result in a bootable key. I have just done this using the analogues of the above command from an f13 machine, and written the f14 beta DVD iso. The key had been formatted using gparted, with a single fat32 partition set with the boot flag. When plugging the key in it mounted automagically. Closing the nautilus window and running the umount command from the cli as I described above makes the preparation of the key work fine. One other very important point that is missing from the documentation is the issue of where grub gets written as part of the install process. When it gets to the section of the main install where grub gets written it is vital to click "Switch device" - then make sure that first bios drive is selected as (typically) /dev/sda and 2nd bios drive is /dev/sdb (if that is the usbkey device). Then ensure that the installer will write grub to the mba of /dev/sda. If this is not done then grub gets written to the mbr of the usbkey by default and the resulting installed system will not boot (though it can be fixed post install using a rescue disk) Then continue with install - and the new system will boot perfectly! The dd command method to write the iso to the usbkey failed to give a bootable key for me in this case, so I don't know if there is a bug in the preparation of the f14 beta iso or if there is some other problem. Anyway I certainly think that the documentation for f14 needs to be changed to reflect the correct and reliable methods for creating bootable install or live usb media.
why this issue has not been resolved officially? (in documentation etc.)
Hi Anshuman, this bug is closed because it's a duplicate of bug 618071