unbounded variable from `FATAL: kernel too old` ?

unbounded variable from `FATAL: kernel too old` ?

[zimoun]

Hi,

I am installing the rnaseq Pigx pipeline from
https://github.com/BIMSBbioinfo/pigx/tree/master/pipelines/rnaseq

I miss something with the Guix installation.

`guix environment -l guix.scm` fails because of these unbounded variables:
 - fastqc
 - salmon
 - ghc-pandoc-1
 - ghc-pandoc-citeproc-with-pandoc-1

And `guix package -A fastqc' returns nothing but it is visible on the
Guix Packages webpage.
https://www.gnu.org/software/guix/packages/F/

Then, I have tried `guix pull`, which leads to:

building path(s) `/gnu/store/7mw3mxnb5py6g2q6qaqf5mbaqxwr0jz3-perl-5.26.1'
FATAL: kernel too old

I am not sure what does it mean ?

(`uname -r` is 3.0.80-0.7-default)


If needed, let me know if you need more information about my system.


Thank you for any insight.

All the best,
simon

Re: unbounded variable from `FATAL: kernel too old` ?

[Ricardo Wurmus]

Hi,

> I am installing the rnaseq Pigx pipeline from
> https://github.com/BIMSBbioinfo/pigx/tree/master/pipelines/rnaseq

Oh, nice!

> I miss something with the Guix installation.
>
> `guix environment -l guix.scm` fails because of these unbounded variables:
>  - fastqc
>  - salmon
>  - ghc-pandoc-1
>  - ghc-pandoc-citeproc-with-pandoc-1

These variables are defined in Guix since quite some time, so you are
probably using a rather old version of Guix.  (The first two are defined
in (gnu packages bioinformatics), the latter two in (gnu packages
haskell).)

Note that you can also install the “pigx-rnaseq” or “pigx” packages with
the latest version of Guix; you don’t need to build the pipeline
yourself.

> Then, I have tried `guix pull`, which leads to:
>
> building path(s) `/gnu/store/7mw3mxnb5py6g2q6qaqf5mbaqxwr0jz3-perl-5.26.1'
> FATAL: kernel too old
>
> I am not sure what does it mean ?
>
> (`uname -r` is 3.0.80-0.7-default)

It means that your kernel is too old to work with the current version of
the GNU C library (glibc).  We applied some patches to the C library to
ensure that it will work with the particular kernel that comes with RHEL
6 (i.e. a heavily modified kernel that self-reports its version as
2.6.32).  The patched glibc package is not yet available in the master
branch; it is currently only available in the “core-updates” branch,
which is due to be merged in the next few days.

3.0 is just a tad too old for the C library.  What system is this?  Is
this SLES from mid 2013?  Are you able to upgrade to at least Linux 3.10
or install the RHEL 6 kernel, which is known to work?

I’m afraid there’s no easy way to convince the C library that your
kernel is compatible, because it’s very likely that it isn’t if it
wasn’t heavily patched.

--
Ricardo

Re: unbounded variable from `FATAL: kernel too old` ?

[zimoun]

Hi,

>> I am installing the rnaseq Pigx pipeline from
>> https://github.com/BIMSBbioinfo/pigx/tree/master/pipelines/rnaseq
>
> Oh, nice!

Thank you to share !!
And nice paper ! :-)


Do you plan to implement a version with the GWL ?


> These variables are defined in Guix since quite some time, so you are
> probably using a rather old version of Guix.  (The first two are defined
> in (gnu packages bioinformatics), the latter two in (gnu packages
> haskell).)

`guix --version` reports 0.14.0.

Weird ?
But if the kernel is too old, then somehow the install is not really
complete. Right ?

> 3.0 is just a tad too old for the C library.  What system is this?  Is
> this SLES from mid 2013?  Are you able to upgrade to at least Linux 3.10
> or install the RHEL 6 kernel, which is known to work?

Yes, it is an old Suse.
My ideas was to be able to fetch up-to-date softwares without
modifying the current configuration (lazy sysadmin's work ;-)

> I’m afraid there’s no easy way to convince the C library that your
> kernel is compatible, because it’s very likely that it isn’t if it
> wasn’t heavily patched.

If I understand well, the shortest path seems to install a new system
from scratch, as GuixSD or Debian.


Thank you for all your explanations.
You save me some time.


All the best,
simon

Re: unbounded variable from `FATAL: kernel too old` ?

[Ricardo Wurmus]

Hi again,

>>> I am installing the rnaseq Pigx pipeline from
>>> https://github.com/BIMSBbioinfo/pigx/tree/master/pipelines/rnaseq
>>
>> Oh, nice!
>
> Thank you to share !!
> And nice paper ! :-)

Thanks :)

> Do you plan to implement a version with the GWL ?

I’m thinking about it.  There is no current plan to switch to something
else from Snakemake, but once the pipelines have stabilised I’d like to
explore ways to simplify them.  One of the changes might be to remove
extraneous dependencies (e.g. fastqc –> fastq to cut out Java), or to
explore if we can simplify the workflow rules, maybe even to cut out
Snakemake completely.

Currently, Snakemake makes a couple of annoying workarounds necessary
(like linking Rscript to ./pigx_temp/bin and putting that on the PATH,
or to copy scripts to a writable location, or to use “shell” instead of
the more convenient “script” rules…), which I’d love to get rid of.

The GWL may need to acquire a few more changes before I can propose it
as a viable alternative for the team.

>> These variables are defined in Guix since quite some time, so you are
>> probably using a rather old version of Guix.  (The first two are defined
>> in (gnu packages bioinformatics), the latter two in (gnu packages
>> haskell).)
>
> `guix --version` reports 0.14.0.

We haven’t made a new release in a while.  I hope we can make a new
one soon.  In general you should be running “guix pull” on a regular
basis.

> But if the kernel is too old, then somehow the install is not really
> complete. Right ?

Unfortunately, this is a wart in software management with the kernel
Linux.  The big kernel binary is not part of the software dependency
graph.  We assume that it is available (and compatible) at runtime.
Usually this is fine.  Unfortunately, there are some old kernels that
are no longer supported by the kernel developers and thus no longer
supported by the glibc developers, who provide the interface that almost
all applications use to talk to the kernel.

You cannot upgrade the kernel with just Guix; you’d have to boot a
system with that kernel.

The kernel interface is pretty large, so it is very unfortunate that we
cannot treat the kernel like any other dependency.  I would think that
this would be a smaller problem in a system like the Hurd.

>> 3.0 is just a tad too old for the C library.  What system is this?  Is
>> this SLES from mid 2013?  Are you able to upgrade to at least Linux 3.10
>> or install the RHEL 6 kernel, which is known to work?
>
> Yes, it is an old Suse.
> My ideas was to be able to fetch up-to-date softwares without
> modifying the current configuration (lazy sysadmin's work ;-)

Unfortunately, you’ll need a supported kernel version.  3.10 is the
minimum for the current glibc.  Installing a recent variant of the GNU
system (e.g. with a recent Debian or GuixSD) would be a good idea.

--
Ricardo

Re: unbounded variable from `FATAL: kernel too old` ?

[zimoun]

Hi,

Thank you for all your explanations.


> The GWL may need to acquire a few more changes before I can propose it
> as a viable alternative for the team.

What should be these changes ?
What do you have in mind ?


> Unfortunately, you’ll need a supported kernel version.  3.10 is the
> minimum for the current glibc.  Installing a recent variant of the GNU
> system (e.g. with a recent Debian or GuixSD) would be a good idea.

I will, if I am able to free some time in the schedule ;-)


Thank you again.
All the best.
--
simon

Re: unbounded variable from `FATAL: kernel too old` ?

[Ricardo Wurmus]

Hi,

>> The GWL may need to acquire a few more changes before I can propose it
>> as a viable alternative for the team.
>
> What should be these changes ?
> What do you have in mind ?

I honestly don’t know yet.  First I should take some time to discuss
with Roel, who is the original author of the GWL and asked me to
co-maintain it with him.  Some time ago I added support for Wisp syntax
and I added a few macros to make the GWL syntax look a bit more like
what people are accustomed to when working with YAML or Python workflow
languages.  I’d like to make a release that includes these changes.

The manual certainly needs to be expanded before we can recommend the
GWL to other people.  (There is a website, but it is not in sync with
the included manual.)

The GWL needs to gain common checks to skip rules when existing results
are still “fresh”.  This has to be done manually now, but it doesn’t
need to be this way.

Another thing that I’d like to see is integration with existing
application bundles.  The GWL does very well by integrating Guix
software deployment with the workflow definition, but it can be useful
to mix and match Guix software with existing application bundles (e.g. a
squashfs image containing some software).

Another big thing I’d like to play with in the context of the GWL is
data provenance.  Can we come up with a way to track artefacts of the
workflow, so that users can find out where a piece of data has come from
and what its trajectory in the context of the workflow might be.  Maybe
there’s a chance to collaborate or integrate with iRODS.  Instead of
just producing files and encoding their origin and processing grade with
file names we could annotate them with the help of an object storage
system.

I think there are still many things that we can do with the GWL that
would make it much more interesting.

--
Ricardo