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@adam anaconda (f20-branch %)]$ grep -R fedora_19 *
[adamw@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@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).
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
