init : libssl.so : cannot open shared object file : kernel panic!
rgollub at uninet.com.br
Thu Jul 3 16:36:29 PDT 2003
richard at nezumi.plus.com wrote:
> On 2003-07-03 09:55:48 +0000, Richard wrote:
> > a) who are those "knowledgables", and where have they expressed their
> > opinions, in support of such claims (chroot is "bad"/substrate kernel
> > "interference", and future problems to be expected, by using the
> > technique)?
> In the past I have had problems with alsa compiling for the running
> kernel instead of the one installed in the chroot environment where
> alsa was being compiled. I had a problem with glibc. I did not have
> problems anything else, including X, but at that time I was not using
Interesting. I have used in the past alsa-0.5.10/12, and most recently,
0.9.2 and never had any problem with them. Likewise, glibc never offered
I must say, in fairness, that there are subtleties and pitfalls to be
looked after, especially kernel modules. For instance, older versions of
pctel (a modem driver) had to have their configure/Makefiles tweaked, so
that the new kernel was the object of the attention, and not the running
kernel. But this is to be expected, as no maintainer/developer would
ordinarily imagine a situation like ours and cater for it. It takes,
obviously, a bit of experience to be able to recognise, and alter
accordingly, similar situations. After all, this is the realm of LFS.
My objection stemmed from the categorical tone of the statement. There
is nothing inherently bad in using the chroot technique. Of course,
sometimes certain adjustments need to be made, and a few common sense
rules must be followed in order to avoid the pitfalls. But the results
are as sound as if the packages were ordinarily built from the booted up
Now, just in clarification: could you explain me your reference to DRM.
I could not gather the implication.
> For all I know, these old problems have been fixed. I would not know
> because I now upgrade the host kernel before building a new LFS.
Except for the first and second generation, where the kernels were the
same, the last two ones have always built for a kernel different from
the running one. Never saw a problem related to the technique in that
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support