Created attachment 1085780 [details] anaconda.log Description of problem: My machine has one disk but nothing is reported in the 'Installation Destination' spoke. Version-Release number of selected component (if applicable): Fedora-Workstation-netinst-x86_64-23_Beta.iso How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.