Bug 1274668

Created attachment 1085782 [details]
dnf.librepo.log

Created attachment 1085783 [details]
dnf.log

Created attachment 1085784 [details]
dnf.rpm.log

Created attachment 1085785 [details]
hawkey.log

Created attachment 1085786 [details]
ifcfg.log

Created attachment 1085787 [details]
packaging.log

Created attachment 1085789 [details]
program.log

Created attachment 1085792 [details]
storage.log

Created attachment 1085793 [details]
syslog

Created attachment 1085795 [details]
X.log

That's because you specified inst.stage2=hd:UUID=04db2969-7f58-4a83-9def-6eee84e588a5:/Fedora-Workstation-netinst-x86_64-23_Beta.iso in the boot command line. Looking at storage.log that UUID is /dev/sda11, so anaconda needs to mount the iso from this partition in order to start the installation environment. For this reason, /dev/sda cannot be repartitioned while the installer is running, and is not available as a destination.

If that is the case then, this is new behavior. I have used this method of booting the network installer on this hardware for F20, F21 and F22 and installed without issue.

Here is the thread at fedoraforum that caused me to register this bug:
http://www.forums.fedoraforum.org/showthread.php?t=307202
The originator of the thread tried to boot the live iso 
Fedora-Live-KDE-x86_64-23_Beta-1.iso
but was having trouble using it from a USB stick as the installer did not see his single hard drive.
However, booting the iso from a file on a partition of that drive did allow the installer to see the drive and he made a successful installation, as he reports at post no. 10.

According to your argument, this should not have been possible.

I am not sure what you mean by 'repartitioned'. I presume that you are thinking of removing all partitions on the drive and creating new ones. That is a very specialised use case and would likely annoy anyone with a preexisting Windows installation.

Imagine a machine with a preexisting OS which uses grub as a boot loader, Ubuntu, say, or a previous Fedora release. Then one is going to create new partitions to install the new Fedora release. This is precisely what I did when I installed Fedora 20 with an existing Fedora 19 on the disk and used anaconda to create the new partitions. 
Is that 'repartitioning' and therefore impossible if the iso is on one of the existing partitions? 
In fact, I lodged two bugs at the time, (as you might remember):

https://bugzilla.redhat.com/show_bug.cgi?id=1048592
Wrong keyboard configuration if keymap= is used
https://bugzilla.redhat.com/show_bug.cgi?id=1048593
Cannot select Updates when Installation Source set

I will upload a screenshot of the 'Installation Destination' screen just to be complete.

Created attachment 1086085 [details]
screenshot of 'Installation Destination'

(In reply to Keith Dixon from comment #13)
> I am not sure what you mean by 'repartitioned'. I presume that you are
> thinking of removing all partitions on the drive and creating new ones. That
> is a very specialised use case and would likely annoy anyone with a
> preexisting Windows installation.

I mean changing anything at all about the partition table. Creating partitions, removing partitions, resizing existing partitions. You cannot make any changes to the partition table while a partition on this disk is mounted, because you would get an error along the lines of "Partitions on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use." If this worked before, then either a) showing the disk was an error on the part of anaconda, and you did not actually need to create or modify any partitions, which is not a common case, or b) the ISO was not actually mounted from tthe same disk.

> 
> Imagine a machine with a preexisting OS which uses grub as a boot loader,
> Ubuntu, say, or a previous Fedora release. Then one is going to create new
> partitions to install the new Fedora release. This is precisely what I did
> when I installed Fedora 20 with an existing Fedora 19 on the disk and used
> anaconda to create the new partitions. 
> Is that 'repartitioning' and therefore impossible if the iso is on one of
> the existing partitions? 

Yup.

> In fact, I lodged two bugs at the time, (as you might remember):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1048592
> Wrong keyboard configuration if keymap= is used
> https://bugzilla.redhat.com/show_bug.cgi?id=1048593
> Cannot select Updates when Installation Source set

One of those bugs was fixed (the EOL is just because it was fixed before a release branch so the fedora updates system never moved it past MODIFIED, and we forgot to do so ourselves), and the other issue was explained in the bug. Neither of those are relevant to this issue.

I merely mentioned those two bugs as available evidence that this method has actually worked up to this date. It is the method I used on F20, F21 and F22.

I forgot to thank you for your explanation. 

I have just found a bug report from the F20 install in which I upload the contents of /var/log/anaconda.
F20 x86_64 EFI installation, os prober creates non-efi entries in grub.cfg
https://bugzilla.redhat.com/show_bug.cgi?id=1051632

The log files show me creating 8 new partitions but I cannot find any errors in syslog.

The uuid is sda3.