On Wed, 2013-12-25 at 18:11 -0500, Robert Moskowitz wrote: > In setting the location from New York to Detroit, if I did not get > Detroit the 1st time or even when back to try and select something else, > I lost the down arrow to scroll beyond the 'a's. I had to type Detroit > in on the location bar. This was consistant behaviour. Had enough > times doing this step. That dropdown is known to be a bit wacky; apparently it's a bug in GTK+ the anaconda devs can't do much about. Seems like it's been waiting a long time to get fixed. > 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. With a kickstart you can specify multiple separate repos, I think. But I haven't really poked into this behaviour much since newUI. > 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. > 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. > 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
