bug 1006304 - Re: Many attempts to install f20 today

[Robert Moskowitz]

Trimmed to lastest attempt.

On 12/27/2013 01:54 PM, Adam Williamson wrote:
> On Fri, 2013-12-27 at 08:42 -0500, Robert Moskowitz wrote:
>> Thanks for responding.  Trimed down to things to reply to...
>>
>> On 12/27/2013 02:59 AM, Adam Williamson wrote:
>>>> 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.
> If there is one, it's not particularly obvious...
>
> [adamw at adam anaconda (f20-branch %)]$ grep -R fedora_19 *
> [adamw at adam anaconda (f20-branch %)]$ grep -R vgname *
> pyanaconda/kickstart.py:        vgname = ksdata.onPart.get(self.vgname,
> self.vgname)
> pyanaconda/kickstart.py:        vg = devicetree.getDeviceByName(vgname)
> pyanaconda/kickstart.py:            raise
> KickstartValueError(formatErrorMsg(self.lineno, msg="No volume group
> exists with the name \"%s\".  Specify volume groups before logical
> volumes." % self.vgname))
> pyanaconda/kickstart.py:            if not self.vgname:
> pyanaconda/kickstart.py:            dev =
> devicetree.getDeviceByName(self.vgname)
> pyanaconda/kickstart.py:                raise
> KickstartValueError(formatErrorMsg(self.lineno, msg="No preexisting VG
> with the name \"%s\" was found." % self.vgname))
> pyanaconda/kickstart.py:        elif self.vgname in (vg.name for vg in
> storage.vgs):
> pyanaconda/kickstart.py:            raise
> KickstartValueError(formatErrorMsg(self.lineno, msg="The volume group
> name \"%s\" is already in use." % self.vgname))
> pyanaconda/kickstart.py:
> name=self.vgname,
> pyanaconda/kickstart.py:            ksdata.onPart[self.vgname] =
> request.name
> [adamw at adam anaconda (f20-branch %)]$ grep -R request.name *
> pyanaconda/kickstart.py:            ksdata.onPart[self.vgname] =
> request.name
>
> probably in there somewhere, but meh. Again, doesn't seem
> burning-down-the-house serious, but worth filing a bug on, sure.

Probably built from a couple variables, but not important, as you said.  
Until it shows up again in f21!

But on to the real problem.

>
>>>> 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?
> They're in /tmp while the installation is running, you can scp or fpaste
> or copy-to-a-USB-stick them out from there.

You will find all the contents of /tmp from the latest bug 1006304 at:

http://medon.htt-consult.com/~rgm/logs/

Let me know when you have them and I will take them down.



>
>>    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.
> It's worth trying, but it could well just be an issue with your UEFI
> firmware in some way. Again, impossible to tell without the logs,
> unfortunately (all the anaconda error message tells us is that EFI
> bootloader configuration failed; it has zero indication of why, that's
> always in the output from efibootmgr in program.log).