[fedora-arm] Black Bootable image
steveu at coppice.org
Sun Dec 29 03:43:20 UTC 2013
On 12/29/2013 06:32 AM, Peter Robinson wrote:
> On Sun, Dec 22, 2013 at 2:34 PM, Steve Underwood <steveu at coppice.org> wrote:
>> 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 machines, so
>> 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
https://bugzilla.redhat.com/show_bug.cgi?id=1043033 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
>  http://pbrobinson.fedorapeople.org/arm-kernel/kernel-devel-3.12.6-300.fc20.armv7hl.rpm
More information about the arm