[Grml-devel] First Release Candidate of Grml version 2017.05 available

[Christoph Biedl]

Michael Prokop wrote...

> * Christoph Biedl [Mon May 08, 2017 at 11:41:26PM +0200]:

> > So I guess this release will, like Debian, no longer support older i386
> > CPUs? Then the release notes should mention that on some place. I'll try
> > to test on K6 and C3 systems these days, this should fail, and hopefully
> > in a sane way. Also, no worries, they are at least 15 years old now and
> > demand a tremendous amount of pocket money.
>
> Yeah, we don't modify/rebuild Debian's userspace tools and our
> kernel is based on Debian's. I don't have any such old systems
> though and don't know which CPUs are exactly unsupported now.
> So whoever knows what we should write in our release notes, please
> just create a PR or patch against
> https://github.com/grml/grml.org/blob/master/changelogs/README-grml-2017.05-rc1/index.html.tt2
> :)

Just borrow from the stretch release notes[1]? With some changes and
also an addition:

| Following Debian's switch, the 32-bit PC support (known as the
| architecture "i386") now no longer covers a plain i586 processor. The
| new baseline is the i686, although some i586 processors (e.g. the "AMD
| Geode") will remain supported.
|
| Systems that do not provide the required features will fail to boot with
| a distinctive error message.
|
| The following shell script may be a useful indicator (assuming only one
| processor is installed in the machine):
|
|  if grep -q '^flags.*\bfpu\b.*\btsc\b.*\bcx8\b.*\bcmov\b' /proc/cpuinfo; then
|     echo "OK (assuming all CPUs are of the same type)"
|  else
|     echo "NOT OK: Missing one or more of the required CPU extensions"
|  fi

[1] https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html#i386-is-now-almost-i686


> > A visual: At least the small i386 image prints a "[ FAIL ] amixer binary
> > not availble" warning during boot. If it's easy to avoid that, please do
> > so.
>
> amixer is coming from alsa-utils, which would pull in ~8MB of
> additional disk space usage on grml-small, so probably not worth it.
> Should we just make it a warning instead of an error message, or do
> you suggest something else?

Drop the init script or whatever causes this from -small. If this means
too much work, rather focus on other issues.

    Christoph