[fedora-arm] Black Bootable image

[Steve Underwood]

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
>> image.Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz
>> <http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/20/Images/armhfp/Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz>
>> 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
>> users.
> 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 [1] for those that wish
> to try it while we wait for the Fedora kernel devs to push a new
> kernel.
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 
success.

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 
working. :-\
> Peter
>
> [1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-devel-3.12.6-300.fc20.armv7hl.rpm
>
Regards,
Steve