On 12/29/2013 06:32 AM, Peter Robinson wrote:
On Sun, Dec 22, 2013 at 2:34 PM, Steve Underwood
> On 12/22/2013 08:59 PM, Adrian wrote:
>> I see vfat images dated this month, however still indicating the serial
>> console requirement.
>> When will we get to a bootable image, with usb/hdmi support please?
>> Adrian ... vk4tux
> This month's VFAT image for the Beaglebone Black is badly broken. If you
> want something workable use an older
> contains a kernel which keep oops'ing on certain operations, like an
> outbound slogin attempt. I reported that and the response was kernel RPM
> 3.12.5-302 which results in a board which will not boot at all.
What do you mean by "this months image". The release image does have
some known and documented limitations but it's relatively stable for
the documented use case.
If you try to slogin to another box from the release image
you get an
oops. That's a severe enough kernel problem to make the image pretty
useless for most people.
> It looks like kernel-3.12.5-302 fixes various things for x86_64
> it is an improvement for them, yet it really wrecks an ARM installation. I
> guess we can expect ARM to always be a secondary architecture, with anything
> that benefits x86_64 users being pushed, regardless of its effects on other
That's not exactly true. Firstly whether it be x86 or ARM no one
particularly device blocks a kernel release. If there's an issue with
a particular piece of HW it's then fixed in a later release. In the
case of the BB Black the 3.12.x kernel massively improves a number of
things such as usb, hdmi and other things. There was one known
regression which is the ethernet, which while it works isn't the most
stable. I've today pushed a patch that should fix this for the next
kernel build and I've put up a scratch kernel  for those that wish
to try it while we wait for the Fedora kernel devs to push a new
No single piece of *new* hardware holds up a kernel, but they are very
reluctant to break things that were working. Its rare that a "yum
update" on a working x86_64 machine has a negative effect. "yum update"
is still an adventure on an ARM machine.
The 3.12.x kernel apparently does a lot of good things. However,
updating to the 3.12.5 RPM results in a BeagleBone Black which will not
boot. I feel that's a serious drawback. If you look at
you will see the
issue is marked as closed a while after I reported that the "fix" bricks
boards. I'm sure a report that the RPM brocks x86_64 boards would have
been taken more seriously. With that approach to updates "yum update" is
going to remain an adventure. Remember that 3.12.5 is an update to a
release. We aren't talking about betas.
We the Fedora ARM kernel people and wider testers are doing our best
with limited time and many devices to support with a greatly moving
target that is the upstream kernel. We do our best but there's many
combinations of hardware which people use in many different ways and
we do try our hardest to support all the many different ways and means
that people want to use Fedora on ARM.
Unless there is a change of course you are
fighting a loosing battle.
Ubuntu are less strict about how they put things together, and have had
a satisfactory installer for the BeagleBone Black pretty much from its
release date. That means almost all BeagleBone users are using Ubuntu,
and only a handful of determined Fedora users like me are even testing
Fedora on this hardware. A small pool of testers is not a recipe for
As a software development platform (mostly for me to try using NEON to
accelerate some of my DSP code on ARMs) the betas of Fedora 20 work very
well. However, all I really need are the SD card and Ethernet port