Created attachment 572155 [details] anaconda.log A USB installation source created by dd'ing a DVD ISO to the USB contains an exploded installation tree without an ISO file for anaconda to draw from. Consequently, anaconda boots and installation proceeds, but just before the package selection stage, a network configuration prompt appears. The packages are n the USB, but can't be read. Bug 729600 also discusses this but suggests that the USB just needs to be specified as the installation source, and Comment 19 says that extra configuration is required. However, specifying the USB as such in a boot prompt using linux repo= or askmethod doesn't work because anaconda cannot draw from an exploded tree when no ISO is present. In Comment 11 of bug 742612, Chris Lumens says that dd should not be recommended now that livecd-tools works for non-live media. Consequently, I will move the dd installation procedure into the Minimal Boot Media section of the Installation Guide, since currently dd is creating what amounts to a boot USB. That procedure will be updated to reflect the changes for RHEL in bug 804476. But dd'ing DVD ISOs continues to not be possible without a network connection. Logs are attached from the point where the network configuration prompt appeared. This problem occurred when installing both F16 and F17 Alpha. I've reported a similar problem in RHEL in bug 805357.
Created attachment 572156 [details] storage.log
Created attachment 572157 [details] yum.log
Created attachment 572158 [details] program.log
I've attempted this again using F17 Beta-RC2 instead of Alpha, and this time an unhandled exception occurred before the installer reached the package selection screen. With F16 and the F17 Alpha, a network connection was prompted at this same point even if an hd: boot option was provided. I tried all of the following boot options: linux repo=hd:/dev/sdb1/ linux repo=hd:/dev/sdb/ linux inst.repo=hd:/dev/sdb1/ linux inst.repo=hd:/dev/sdb/ I also tried the following syntax (plus the same variations listed above), since it was provided to me for specifying a specific folder on the device (this cannot be done though due to the lack of an ISO image in the exploded installation tree): linux repo=hd:/dev/sdb1:/ At the same point, the following message appeared instead of the unhandled exception: "Couldn't mount ISO Source An error occurred mounting the source device /dev/sdb1. This may happen if your ISO images are located on an advanced storage device like LVM or RAID, or if there was a problem mounting the partition. Click exit to abort the installation." The device was not LVM or RAID, and I confirmed in a virtual console that the device was mounted. Because the syntax may be flat wrong though, this issue may be moot. I have a log that can be attached if need be, but I'll just provide a log of the unhandled exception for now.
Created attachment 574406 [details] Anaconda log at point of unhandled exception
Created attachment 574407 [details] Storage log at point of unhandled exception
I've confirmed that this is still a problem with Beta. It isn't pulling the repo from usb, instead it brings up the network and uses the mirrors.
anaconda-17.23-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.23-1.fc17
I'm +1 blocker on this since it can't be fixed with an update and dd remains the only way I'm aware of for OSX and other linux distro users to create USB install media. I see it as conditional breakage of the F17 final release criterion [1] "The installer must be able to complete an installation using all supported interfaces" [1] http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
Created attachment 580575 [details] updates.img for anaconda-17.22-1 This updates.img will fix anaconda so that it checks the / of the source media for repodata before falling back to network. This fixes the problem with dd'd media. It can also be used with a new version of livecd-iso-to-disk (16.14, 17.10) to make USB's with only 1 partition like we used to.
livecd-tools-17.10-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/livecd-tools-17.10-1.fc17
livecd-tools-16.14-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/livecd-tools-16.14-1.fc16
Package anaconda-17.23-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-17.23-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6815/anaconda-17.23-1.fc17 then log in and leave karma (feedback).
Discussed in the 2012-05-01 blocker bug review meeting. Accepted as a Fedora 17 final blocker as it violates the following final release criterion [1]: The default update manager in release-blocking desktops must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system [1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
(In reply to comment #14) > The default update manager in release-blocking desktops must not periodically > check for updates when the system is booted live, but must periodically check > for updates when running on an installed system I put the wrong release criterion in that comment. It should have been a conditional violation (USB installation media created with dd) of the F17 final release criterion: The installer must be able to use all supported local and remote package source options Since dd is the only supported method of creating USB installation media on non-fedora linux distributions and OSX, this was deemed severe enough to justify blocker status.
livecd-tools-16.15-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/livecd-tools-16.15-1.fc16
livecd-tools-17.11-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/livecd-tools-17.11-1.fc17
We believe this should be fixed with F17 Final TC2. We should test and verify that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
livecd-tools-15.13-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/livecd-tools-15.13-1.fc15
livecd-tools-17.11-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
I've verified this fix with TC3. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
livecd-tools-15.13-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Fully updated to livecd-tools-16.15-1.fc16.x86_64. Unfortunately the image created with this using the command: sudo livecd-iso-to-disk /home/bharringtonFedora-17-x86_64-DVD/Fedora-17-x86_64-DVD.iso /dev/sdb1 Still produces an unusable disk which errors with: "Couldn't mount ISO Source An error occurred mounting the source device /dev/sdb1. This may happen if your ISO images are located on an advanced storage device like LVM or RAID, or if there was a problem mounting the partition. Click exit to abort the installation." attached are the logs from the server with a screenshot in the sub directory anaconda-screenshots.
Created attachment 587793 [details] Logs & Screenshots from failed install created via livecd-tools-16.15-1.fc16.x86_64 Anaconda logs
Worked fine in validation testing with multiple testers, so there's something odd going on in your configuration for some reason. The cmdline looks very wrong: Command line: initrd=initrd.img repo=hd::/ root=live:UUID=B455-EB4C quiet BOOT_IMAGE=vmlinuz I'm not sure _why_, though. Brian, any thoughts?
i'm missing _some_ of what's wrong here. of course, that's also due to the changes in how F17 starts up. when i look at that command I see the UUID being referenced corresponds to the output of blkid matching the flash drive. As you can see, it gets far enough that it loads the stage1. The repo referencing stage2 looks a bit odd, but when i look at the install guide, it seems like it should make sense: "Hard Drive If you have copied the Fedora ISO images to a local hard drive, you can use this method. You need a boot CD-ROM (use the linux repo=hd:device:/path boot option), or by selecting Hard drive on the Installation Method menu (refer to Section 8.1, “Installation Method”). Refer to Section 8.1.2, “Installing from a Hard Drive”, for hard drive installation instructions. " Possibly repo=hd::/ simply will leave it at whatever device was identified by UUID.
Brian, a few things: If there is a bug with livecd-tools, please open a new bug for that component instead of adding to this closed, unrelated bug. Building F17 using livecd-tools from f16 *may* work, but it is more reliable to use livecd-tools from the release being targeted. Be careful when you comment, you switched the component to 0xFFFF somehow. I changed it back to anaconda.