On 05/30/2014 04:00 PM, Robert Moskowitz wrote:
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.
OK. I will first live image boot with this i386 install and see what
I can find to save, then I will redo the x64 install and see what I
can find.
On looking through /var/log/messages, F20-i386 is thinking the system is
too hot, 98C. Which it isn't this is a know problem with the Lenovo
thinkpads and there is a utility you install (thinktop and powerfan?),
once the system is up, to get proper reporting. Yes it DOES get hot at
times.
So, I will save the logs of this install, but I think i386 just can't
take the heat!
Be back to this one in a bit.
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.
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
