[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd and cdebootstrap --foreign



This is exactly what I'm talking about:

On 25/10/14 16:36, Geert Stappers wrote:
> On Sat, Oct 25, 2014 at 02:05:20AM +0200, Simon Richter wrote:
>> This is a KTAM3874/pITX board, running their SDK kernel. The segfault
>> occurs in PID 1. 
> Most likely running as user root.  Please confirm.
>
> That "SDK kernel", which kernel version number is it?

Current hardware, sold from a vendor shipping linux kernel 2.6.37 in
their latest rootfs dated 11 February 2014.

Let's see what TI themselves have to say about this, after all they make
the silicon: http://www.ti.com/tool/linuxezsdk-sitara - damn! If TI
can't be bothered updating beyond kernel 2.6.37, what hope does kontron
have? Or the poor user/integrator stuck with a fleet of these boards?

Maybe there's Linaro kernels which support the AM3874: no, doesn't look
it. Maybe there's mainline kernel support for this now? Nope, TI has got
some of their CPU lines into mainline linux but the AM38xx isn't one of
them: http://linuxgizmos.com/ti-sitara-sdk-moves-to-mainline-linux-kernel/

Check out this poor KTAM3874 user's thread just trying to compile the
hacked 2.6.37 kernel that *is* offered for this board:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/276011.aspx

--- and that's basically a microcosm of what I've witnessed so far in
the embedded ARM "scene", of course I'm willing to be shown that I'm
wrong on this: hardware vendors don't get software. It's just a mess.
Software ecosystem is 10 years behind the times, often dumping tarballs
over the wall without any real SVN/git/SCM versioning. I have to believe
that this is a typical state of affairs for systems integrators using
ARM kit, especially the low-power <1GHz stuff.

I do like systemd. I just worry that people don't realize how many
greenfield projects/products are starting out today that are never going
to ship with a linux kernel new enough to boot systemd. And perhaps that
isn't enough reason to change the outcome of whether Debian should
formally continue to support sysvinit in Jessie or future releases. But
it's naive to think that this isn't a problem.

--
Paul


Reply to: