Many attempts to install f20 today -

[Robert Moskowitz]

Thanks for responding.  Trimed down to things to reply to...

On 12/27/2013 02:59 AM, Adam Williamson wrote:
> On Wed, 2013-12-25 at 18:11 -0500, Robert Moskowitz wrote:
>
>> If I selected my local repo, Updates became not an option. Regardless if
>> I used the DVD install (i386 and x86_64) or the netinstal (only tried
>> x86_64), consistantly this became greyed out. I could not provide the
>> URL for where I have my local updates repo. It did not matter if I added
>> repo=url to the boot line, or did it in the GUI.  The moment I selected
>> my own http URL, I lost updates.
> With the interactive install, I believe anaconda doesn't expect you to
> pass multiple repos; it's expecting either a (single) actual yum package
> repository, or a mirror tree with a .treeinfo file specifying the
> location of the standard repo set.

First is there a way to specify the updates repo on the boot line. There 
was (I believe) back on F17.  Or maybe I am just suffering from a senior 
moment.

Where are there instructions for making a .treeinfo file and can I 
specify it in the repo=url boot parameter?

> With a kickstart you can specify multiple separate repos, I think. But I haven't really poked into this
> behaviour much since newUI.

My 'practice' is to first get an install working, then use the 
anaconda.cfg to build a kickstart file. So here I am, not getting to 1st 
base.  I almost discourage you from poking around.  I feel it is a real 
dumb down, and very saddening.  Particularly that I can not customize 
what apps and groups to install or not. Just a large general catagory.

>
>> As far as adding repo= to the boot line, i386 and x86_64 work
>> differently!  But I suspect you know that.  tab with i386 and 'e' with
>> x86_64.
> Um. What? Oh. The boot menu. I think you more likely saw live vs.
> non-live rather than x86_64 vs. i386. They're built a bit differently.
> But I can't say I've bothered looking into it that closely either.
> ctrl-X vs. F10 to actually boot once you've edited it is
> similar...sometimes one works, sometimes the other, sometimes both. I
> just file it under 'not sufficiently serious that I have time for it' at
> present, sadly.

No absolutely I downloaded the full DVD and netinstal isos (I use wget, 
so I know the exact url I download).  Never touched the live isos.

But like you said:  'not sufficiently serious'; once I understood what 
was happening, I worked with the hand dealt.

>
>> Sometimes when I selected LVM for the partitioning, the LVM partition
>> name would be 'fedora_19'.  I left it like that in this install that
>> finally worked and here is what df has to say for itself:
>>
>> $ df -h
>> Filesystem                          Size  Used Avail Use% Mounted on
>> /dev/mapper/fedora_19-root           29G  4.8G   23G  18% /
>> devtmpfs                            1.3G     0  1.3G   0% /dev
>> tmpfs                               1.3G  164K  1.3G   1% /dev/shm
>> tmpfs                               1.3G 1016K  1.3G   1% /run
>> tmpfs                               1.3G     0  1.3G   0% /sys/fs/cgroup
>> tmpfs                               1.3G   44K  1.3G   1% /tmp
>> /dev/sda1                           477M   96M  352M  22% /boot
>> /dev/mapper/fedora_19-home          257G   32G  212G  14% /home
>>
>> Some times it used the host name.  Depended on what steps I took to get
>> to setting up the LVM partition.
> It's probably re-using the existing VG rather than blowing it away and
> creating a new one, the '19' rather suggests that.

On a new, empty, SSD drive from Crucial or a old drive that had f17 on 
it?  Never installed f19 here.  I think the disk druid developers need 
to search their code for some label they did not change.

>
>> In summary of what is important:
>>
>> Why have my installs to the SSD failed (writing bootloader).
> It is absolutely impossible to tell without at least program.log. It's
> kind of annoying that all cases of bootloader install failing on UEFI
> install keep getting written off as dupes of 1006304, because when
> they're marked as dupes we don't get logs, and there's just no way to
> know what's going on. I've posted a couple of comments asking if
> anaconda and libreport devs can figure that out, but nothing doing yet.
>
> If you have a copy of program.log (and ideally all the other logs...)
> from one of those failures, we could try and figure it out.
Instructions on generating (or capturing) the logs?  I would be glad to 
try.  Though I am thinking of building a netinstal USB stick and seeing 
if there are timing problems with the USB DVD drive.  The observed 
symptom is the drive starts up (it had been off during the post install 
process) and a spinning wait object is going on the screen.  After some 
time (minute or so?) I get the error.

I really want to be running on the SSD card before my next bit of travel 
(IEEE 802 meeting Jan 19 in LA).

thanks for your time.