[Top][All Lists]

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

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

From: Ricardo Wurmus
Subject: Re: unbounded variable from `FATAL: kernel too old` ?
Date: Thu, 31 May 2018 13:57:07 +0200
User-agent: mu4e 1.0; emacs 26.1

Hi again,

>>> I am installing the rnaseq Pigx pipeline from
>> 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

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]