Remember my F20 nvram issues with Lenovo x120e? More sagas
Robert Moskowitz
rgm at htt-consult.com
Fri May 30 21:51:36 UTC 2014
On 05/30/2014 03:53 PM, Adam Williamson wrote:
> 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.
Took a bit, but I am in there and will soon upload what I found. No
/var/log/ana* anything.
Did find a /root/anaconda-tb-pwnbs4, that I will upload. Also pulling
/var/log/messages
More information about the test
mailing list