On Fri, 2014-05-30 at 14:40 -0400, Robert Moskowitz wrote: > A quick piece of review then on to day's failures. > > Back in December? I was working on installing F20-64 on my Lenovo x120e > and could not update NVRAM. You here helped me get a working system. > > ============ now on to recent history ============= > > Then the audio started getting flacky and could tell if it was hardware > or a software update (headphones worked, but not built in speakers). So > I picked up another x120e from ebay that had an oem Windows7 on it. I > pulled that drive and put in my drive from the old system. I figured > that since it was working without nvram info it would work in another > box. And it did. For a while. > > Then one reboot after a kernel update, it would not reboot. A long set > of messages and then failure to sync drive and powering off. I found > that if I hit s or <ctl-s> a lot of times at the right point it would > boot up. I rebooted as little as possible and only applied updates when > gnome would freeze up (in a tty session). Finally it got too bad, and I > put the drive back into the old system with the flacky audio where I am > right now. > > ===================== Finally today's failures ================= > > So I ordered a new SSD drive and today set about installing F20-64. See > bug 975537, and no, Adam, I did not save anything. Instead I set about > doing an i386 install! That seemed to go ok until I got to the reboot. > It goes through a reboot and shuts off. I have tried with <alt-d> to > catch any messages, but none that I can see. :( > > So now what? Adam, I CAN do another x64 install and if you give me the > steps to rescue any logs (you mean they were not part of the upload?) I > will attach them to the bug report. That would probably be best. The logs get attached automatically when libreport files a *new* report, but not when it thinks your bug is a dupe - unfortunately, any time bootloader installation fails in a UEFI install it tends to winds up as a dupe of some older existing bug, because of how the error gets reported. So, what you can do is boot a live image, mount the installed system that you can't get to, and pull /var/log/anaconda/program.log (or anaconda.program.log, I forget what it winds up being called) out and attach it to the bug report, or to a *new* bug report. > Or I COULD do a rawhide install. Point me where to get the ISO image > and I am willing it give it a go. I DO at least have this system to > work from. I updated https://fedoraproject.org/wiki/Rawhide recently to try and make this sort of thing clearer, can you check that and see if it works as a useful guide? > thank you for your support. Now I think I will try that Fedora 20 arm > install again. This time recable my monitor so I have direct hdmi > connection to get me through firstboot. > > -- 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
