Chrome OS 37 update not available for some devices

[Alexandre Miguel]

Hi,

Google Chrome Blog posted the release of the 37 version system update but also excluded some devides like Acer C7 Chromebook, Samsung Chromebook Series 5 and HP Pavilion Chromebook.

They will receive this version or others in the future or the support for this deviced is finished?

[Mike Frysinger]

all devices are still supported.  sometimes specific updates are skipped for certain devices when there's a known problem specific to those platforms.  we don't generally summarize/publish that info, or provide roadmaps as to when things will resume.  eventually they will.

when a device reaches its end of supported life, it will be clearly announced in many places well in advance.  i think it's safe to say that the expiration order though will follow the release order -- the CR-48 (mario) will go first, followed by Samsung Series 5 (alex) and the Acer AC700 (zgb).  especially because those are our only Atom/32-bit systems :).

-mike

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

[Alexandre Miguel]

Hi Mike,

That announce will be posted on the Chromium Blog? I have a Samsung Series 5 and i would like to know when i will need to upgrade.

Thanks

[Mike Frysinger]

i'm sure it'll be announced in all the proper channels including the Chromium OS blog

honestly, we haven't exactly defined the process yet for EOL-ing a device as it hasn't come up -- we're still supporting devices 4 years after their official release.  but it certainly won't be silent.  we try to keep our users happy :).

-mike

[Alexandre Miguel]

Ok Mike, thank you very much i'm very happy till now :)

[Richard Barnette]

On 9/15/14, 3:06 PM, Mike Frysinger wrote:
> i'm sure it'll be announced in all the proper channels including the
> Chromium OS blog
>
> honestly, we haven't exactly defined the process yet for EOL-ing a
> device as it hasn't come up -- we're still supporting devices 4 years
> after their official release. but it certainly won't be silent. we try
> to keep our users happy :).
> -mike
>

FWIW, there *is* an end-of-life policy, complete with unofficial
dates for the various models:
https://www.google.com/chrome/devices/eol.html

Short summary:
* Updates will be provided for any device model for at least
5 years after its first availability.
* Devices may be supported longer.
* EOL Announcements will be included on the page above
(at least).
* Only the Samsung Series 5 has an officially announced
EOL date (June 2016).

> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>

--
--jrb

[Alexandre Miguel]

Fantastic, so until May 2017 i can keep my Serie 5 550.

Thanks Richard.

[Mike Frysinger]

On Mon, Sep 15, 2014 at 3:33 PM, Richard Barnette <jrbar...@chromium.org> wrote:

On 9/15/14, 3:06 PM, Mike Frysinger wrote:

i'm sure it'll be announced in all the proper channels including the
Chromium OS blog

honestly, we haven't exactly defined the process yet for EOL-ing a
device as it hasn't come up -- we're still supporting devices 4 years
after their official release.  but it certainly won't be silent.  we try
to keep our users happy :).
-mike

FWIW, there *is* an end-of-life policy, complete with unofficial
dates for the various models:
    https://www.google.com/chrome/devices/eol.html

Short summary:
  * Updates will be provided for any device model for at least
    5 years after its first availability.
  * Devices may be supported longer.
  * EOL Announcements will be included on the page above
    (at least).
  * Only the Samsung Series 5 has an officially announced
    EOL date (June 2016).

sorry, i was vague (and a bit wrong -- that page is basically what Alexandre wanted).  i was thinking more in the "software updates from Google are no longer guaranteed" part -- we haven't really made a decision on what exactly that means.  as long as the maintenance burden specific to those devices is not high, i suspect they'll stay comparable to the latest devices.

but if does get to be a problem, then what (like when all our devices running linux-3.4 hit EOL) ?  maybe we keep the device up to date (for security), but drop functionality (like hardware encoding or custom cellular modem support).  but even if that gets to be too problematic, and we basically want to drop the device entirely, then what ?  do we let users submit patches to keep things limping along ?  do we keep testing on them ?  or do we release the device keys so people can start signing their own official builds ?  or do we release a signed SeaBIOS implementation so people can install Linux/whatever directly ?  maybe some OEMs will implement a buyback program for their own devices to get people to upgrade to the latest hotness.

at some point, i suspect we will want to release the keys regardless.  if we're orphaning people software-wise on a version of Chrome with known security holes, then we're not really making them anymore secure by holding on to the keys.  people still wouldn't be able to MITM the update process (since the update key is independent of the device key).

all in all, we're basically kicking the can down the road until our stated obligations are fulfilled :).  dropping just mario (Dec 2015) doesn't make much sense since most of the annoying things there are shared between alex (Jun 2016) and zgb (Aug 2016).  but i'm sure we'll have pretty interesting conversations when Aug 2016 comes around as that'll let us stop worrying about 32bit/Atom, and Nov 2017 as that's the last linux-3.4 device (and the kernel team hates maintaining more than one kernel base).

-mike

--
--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

--
--jrb

[Sonny Rao]

I believe we're still keeping Sandy Bridge on 3.4 (due to some GPU
issues) so we'll have to support it for a while. Based on that EOL
page, it looks like HP Chromebook 14 is maybe the last Sandy Bridge
device at November 2018. So, yeah, I'm not sure what will actually
happen.

>>> Chromium OS discuss mailing list: chromium-...@chromium.org

>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>>>
>>
>> --
>> --jrb
>
>

> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>

> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-os-dis...@chromium.org.

[Tim Small]

On 15/09/14 23:59, Mike Frysinger wrote:
> Nov 2017 as that's the last linux-3.4 device (and the kernel team
> hates maintaining more than one kernel base)

My assumption with the platforms which are very close to standard x86 -
such as the Acer C710 - is that ongoing kernel support won't be any
trouble (since I run an unmodified Debian Jessie 3.14 kernel on a C710
already, albeit having installed a custom firmware).

For non-x86 kernel support, I would have thought that donating a handful
of the ARM Chromebooks to key linux-arm developers would result in a
good chance of getting long term mainline support there too
(particularly if it's done sooner rather than later - whilst the
hardware is still relatively high-spec).

Tim.

[Tim Small]

On 16/09/14 00:05, Sonny Rao wrote:
> I believe we're still keeping Sandy Bridge on 3.4 (due to some GPU
> issues)

I'd be interested to hear any more detail you have on this? If there's
a bug upstream with newer kernels, it'd be good to get this fixed
(although that seems a bit strange, as Sandy Bridge is obviously such a
high volume platform - not like it's some obscure ARM based SoC with
zero vendor support!), or does the issue lie elsewhere (e.g. firmware or
otherwise ChromeOS specific)?

Tim.

[Mike Frysinger]

keeping it booting isn't really the same as making sure regressions
are kept out :). we have a long standing problem with platforms where
random performance/functional/stability regressions creep in on older
platforms. GPU/WiFi were the worse offenders iiuc. it's why we
started forking the kernel trees in the first place -- once we have a
stable base for a board (really the CPU/GPU/chipset combo), we don't
really upgrade it. end users of CrOS don't really care what kernel
version they're on ... they want the system to be stable & fast. i
doubt that donating hardware to kernel devs will really help in this
area.

there's also the matter of doing new feature work that requires newer
functionality. like namespace/seccomp work. we don't want to start
backporting large swaths of core kernel code to the older versions.
-mike

[Tim Small]

On 16/09/14 17:34, Mike Frysinger wrote:

we have a long standing problem with platforms where
random performance/functional/stability regressions creep in on older
platforms.  GPU/WiFi were the worse offenders iiuc.  it's why we
started forking the kernel trees in the first place -- once we have a
stable base for a board (really the CPU/GPU/chipset combo), we don't
really upgrade it.

Whilst I agree that this is frequently an issue with hardware which
utilises low volume components or unusual combinations...

I suppose my gut feeling is that the sort of regressions which you've
seen (I'm guessing on the older Atom ChromeOS devices) would be
substantially less likely to hit you with designs which use high volume
parts (probably at least an order of magnitude greater units shipped)
such as those in the C710 (the same probably goes for the other
Sandybridge / Ivybridge / Haswell based ChromeOS machines) - which see
far more extensive use in multiple other non-ChromeOS Linux device
designs (again I'd guess probably an order of magnitude more designs
use the C710 vs. the CR-48 CPU/GPU/chipset combo - dunno about the
wifi).

  end users of CrOS don't really care what kernel version they're on

Absolutely not - neither do I - so long as it gets the job done.

there's also the matter of doing new feature work that requires newer
functionality.  like namespace/seccomp work.  we don't want to start
backporting large swaths of core kernel code to the older versions.

Of course - and whilst there is an obvious difference between yourselves
and other Linux distro maintainers (in that you must support only
certain hardware platforms), this is a question which must be faced by
all Linux distros.

I suppose it boils down to:

In order to minimise cost to maintain a given platform - for a given
kernel version and hardware platforms - does the cost of upgrading to a
newer kernel exceeds the cost of back-porting required features from
newer kernels?

My instinct is that the "mainstreamness" of the components (and
component combinations) used in hardware platform is likely to be the
biggest influence on this, but of course appreciate that you'll have
other factors to consider when deciding on a device EOL - such as
manufacturer relations etc.

Interesting to have some visibility into these sort of internal
decisions tho' - the continued openness is much appreciated!

Tim.

[Mike Frysinger]

On Wed, Sep 17, 2014 at 3:50 AM, Tim Small <t...@buttersideup.com> wrote:

On 16/09/14 17:34, Mike Frysinger wrote:

we have a long standing problem with platforms where
random performance/functional/stability regressions creep in on older
platforms.  GPU/WiFi were the worse offenders iiuc.  it's why we
started forking the kernel trees in the first place -- once we have a
stable base for a board (really the CPU/GPU/chipset combo), we don't
really upgrade it.

Whilst I agree that this is frequently an issue with hardware which
utilises low volume components or unusual combinations...

I suppose my gut feeling is that the sort of regressions which you've
seen (I'm guessing on the older Atom ChromeOS devices) would be
substantially less likely to hit you with designs which use high volume
parts (probably at least an order of magnitude greater units shipped)
such as those in the C710 (the same probably goes for the other
Sandybridge / Ivybridge / Haswell based ChromeOS machines) - which see
far more extensive use in multiple other non-ChromeOS Linux device
designs (again I'd guess probably an order of magnitude more designs
use the C710 vs. the CR-48 CPU/GPU/chipset combo - dunno about the
wifi).

we see it on all of our devices.  it isn't just about parts that aren't widely used.  mainline kernel development doesn't generally focus on regression free releases and we no longer have the bandwidth to do it ourselves on all our systems.  they rely on users posting feedback, and then eventually distros/vendors/maintainers looking into it, and eventually landing a fix.  that cycle lasts over a couple releases though, so other regressions often slip in in the meantime.  the timeframe is not nearly good enough for us when we're on rolling 6 week cycles.

maybe someone from the WiFi team can chip in, but you might notice that even when we update to a newer kernel, we've imported the wireless stack from our previous kernel.  this way we can update a platform to e.g. linux-3.8 whilst still using the tested linux-3.4 wifi stack for certain devices.  we don't do this forever though ... it's more to ease pulling up a previous board for one or two series before we decide to lock it in.

there's also the matter of doing new feature work that requires newer
functionality.  like namespace/seccomp work.  we don't want to start
backporting large swaths of core kernel code to the older versions.

Of course - and whilst there is an obvious difference between yourselves
and other Linux distro maintainers (in that you must support only
certain hardware platforms), this is a question which must be faced by
all Linux distros.

and honestly, i think the bigger difference is polish.  ignoring enterprise (of which really only RHEL fits the bill anymore), distros do not guarantee a refined experience.  most have even moved to upstreaming bug reports (which is good!), but then that's usually where they stop helping (which is bad), so the end user is stuck in the wind until upstream gets around to looking into it and fixing things.

I suppose it boils down to:

In order to minimise cost to maintain a given platform - for a given
kernel version and hardware platforms - does the cost of upgrading to a
newer kernel exceeds the cost of back-porting required features from
newer kernels?

yes, in our experience, it does exceed.  what works in our favor is that our security team did a lot of their core work early on in the project lifetime and got it mainlined, so many of the critical features are already merged in our oldest version.  the refinement work since has been minor.  i'm afraid for the next large project our security guys start that is not arch specific and then we have to decide what to do about older versions.

My instinct is that the "mainstreamness" of the components (and
component combinations) used in hardware platform is likely to be the
biggest influence on this, but of course appreciate that you'll have
other factors to consider when deciding on a device EOL - such as
manufacturer relations etc.

our experience has shown it to not be the case, and sometimes it's not even possible.  for example, we're the only ones doing ARM laptops that are actually *usable*.  in fact, in some cases, we're the only people making ARM laptops :), and we're the only ones really focusing heavily on stability here at all.  i've done lots of distro work (for many years before i even worked at Google), and i can certainly agree with myself on that point -- a lot of ARM people say they're finished once they boot to a cmdline prompt.  the fact the system is unstable (under load or otherwise) is a mere "annoyance" to them -- just add a watchdog to the system and you'll be fine i'm sure.

i'm a big fan of this:

http://www.systemcall.eu/blog/2014/06/trashing-chromebooks/

-mike

[Selden Deemer]

This sounds like no Android capability on the first-generation Pixel. :(

[Mike Frysinger]

CrOS 37 is very very old.  if your device is stuck on that, it's a bug.  you can try a recovery image to get it back onto the latest version (but that'll wipe your local accounts).

-mike

On Sun, Jun 5, 2016 at 10:36 AM, Selden Deemer <lib...@gmail.com> wrote:

This sounds like no Android capability on the first-generation Pixel. :(

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org