FATAL: kernel too old

lifanov · 2010-02-04 17:29:18

Now that I got your attention, I'm trying to run Arch inside a FreeBSD jail.
I am familiar with and run many installations of both systems.
I am in love with Arch package system and repos, so it would be nifty for me to run Arch in FreeBSD jails on a desktop and use X11 forwarding to launch graphical application.
However, linuxulator that comes with FreeBSD is compatible with Linux 2.6.16 and Arch 'base' thinks it's too old. Is there a way to force it to work with an older kernel? ABS?

Here are some notes on what exactly I tried (it's not a script or anything, just notes):

cd /usr/src
make buildworld installworld distribution TARGET=i386 DESTDIR=/usr/jail/arch
fetch http://lifanov.com/files/pacmanForBSD.tar.gz
#(contents: pacman, mirrorlist, pacman.static)
#(edits: mirrorlist, transfer agent fetch, extra repos, removed .*)
mv pacmanForBSD.tar.gz /usr/jail/arch/root/

#set up jail
#example rc.conf:
jail_enable="YES"
jail_list="arch"

jail_arch_rootdir="/usr/jail/arch"
jail_arch_hostname="arch.lifanov.com"
jail_arch_ip="172.17.2.163"
jail_arch_devfs_enable="YES"

chflags -R 0 /usr/jail/arch
mount -t linprocfs linproc /usr/jail/arch/proc
cp {,/usr/jail/arch}/etc/resolv.conf
/etc/rc.d/jail start arch

jls
jexec 14 sh
cd

cp pacmanForBSD.tar.gz /
cd /
tar xvzf pacmanForBSD.tar.gz && rm pacmanForBSD.tar.gz
/usr/bin/pacman.static -Syf base base-devel
#everything up to this point works
cp /etc/pacman.conf{.pacorig,}

It complains about not being able to chroot. I allow hierarchical jails, so chroot should be no problem.
This might or might not be a stupid idea. You can tell me that; I won't be offended.

.:B:. · 2010-02-04 19:39:37

No it's not. Afaik it's backward compatibility compiled into the glibc packages.

[stijn@hermes ~]$ grep kernel /var/abs/core/glibc/PKGBUILD 
# toolchain build order: kernel-headers->glibc->binutils->gcc->binutils->glibc
depends=('kernel-headers>=2.6.32' 'tzdata')
      --enable-kernel=2.6.18 --disable-profile \
  # provided by kernel-headers

The only solution is to use an older Arch toolchain, or build your own.

lifanov · 2010-02-04 19:52:41

Perfect! Thank you much.
Although I still need a bit of guidance.
Do I compile the toolchain on an Arch system or does Arch have a build system that works on other platforms?
One idea would be to dig up one of my old Arch install discs and try ABS there.
Also, can I temporarily use glibc from another distro that I know works?

lifanov · 2010-02-04 20:22:25

Alright, I made a bit of progress.
I installed the fedora 10 compatibility layer and copied some libs from there.
Now sh, bash, and a lot of other programs work.
However,

bash-3.2# abs
==> Starting ABS sync...
receiving file list ... done

sent 107 bytes  received 60 bytes  66.80 bytes/sec
total size is 0  speedup is 0.00
bash-3.2#

I am using a modified srcpac script, but I can't do anything without an abs tree.
I might specify an alternate abs.conf.

Edit: I am playing around with 'abs', which is also a script.

Last edited by lifanov (2010-02-04 20:24:33)

lifanov · 2010-02-04 21:20:48

Another update:
I rsync'ed abs tree from another machine, but now this:

==> Starting build()...
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|timezone data has been split into the package sys-libs/timezone-data
|
|--- glibc-2.4/Makeconfig
|+++ glibc-2.4/Makeconfig
--------------------------
Patching file Makeconfig using Plan A...
Hunk #1 succeeded at 934 (offset 3 lines).
done
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Naur glibc-old/sysdeps/unix/sysv/linux/i386/clone.S glibc/sysdeps/unix/sysv/linux/i386/clone.S
|--- glibc-old/sysdeps/unix/sysv/linux/i386/clone.S    2009-05-09 13:35:30.000000000 +1000
|+++ glibc/sysdeps/unix/sysv/linux/i386/clone.S    2009-05-23 13:27:46.000000000 +1000
--------------------------
Patching file sysdeps/unix/sysv/linux/i386/clone.S using Plan A...
Hunk #1 succeeded at 120.
Hunk #2 succeeded at 152.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Naur glibc-old/sysdeps/unix/sysv/linux/x86_64/clone.S glibc/sysdeps/unix/sysv/linux/x86_64/clone.S
|--- glibc-old/sysdeps/unix/sysv/linux/x86_64/clone.S    2009-05-09 13:35:30.000000000 +1000
|+++ glibc/sysdeps/unix/sysv/linux/x86_64/clone.S    2009-05-23 13:27:46.000000000 +1000
--------------------------
Patching file sysdeps/unix/sysv/linux/x86_64/clone.S using Plan A...
Hunk #1 succeeded at 89.
Hunk #2 succeeded at 113.
done
mkdir: cannot create directory `glibc-build': File exists
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for suffix of object files... configure: error: in `/var/abs/core/glibc/src/glibc/glibc-build':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make: no target to make.
==> ERROR: Build Failed.
    Aborting...

Edit: yet another update
After enabling security.jail.sysvipc_allowed, compiling glibc with Linux 2.6.16 on an Arch machine, and disabling fakeroot, some things build in jail.
binutils does not build yet

Last edited by lifanov (2010-02-04 22:38:57)

.:B:. · 2010-02-05 01:42:29

I think the easiest way would be to install a bare Arch system, update to the latest and build from there. Since you say you already have it installed I guess you could copy the configs from that setup.

I haven't really rebuilt toolchain using Arch's ABS, so far I've only done it with the (C)LFS documentation.

lifanov · 2010-02-05 05:18:41

I've done LFS too, but that's barely helpful.
I actually thought that doing the build inside a chroot and jailing it later would solve all my problems...
It didn't, and I was very concerned about one of the makepkg commands breaking my chroot.
I don't want to complain, but ABS is inferior to the FreeBSD build system in some ways, even when building on Arch for Arch.
An Arch system that would result would become unmaintainable because updates would have to be built from source and there is no clean way to save modified PKGBUILDs for future builds other than making them immutable and raising the kernel security level, which would break such build.
The motivation behind Arch was partially due to the fact that it is a rolling release and rolling releases are easier to maintain.
I really don't want to give up; I'll just think about it some more.
Try to imagine: FreeBSD, but you can try out that latest Linux software in an isolated environment.
There is VirtualBox of course, but it is limited in ways that jails are not.

.:B:. · 2010-02-05 15:56:54

Well Arch is a rolling target. You can't really blame devs for skipping backward compatibility to some extent, even more if a non-Linux OS will 'break' by that. That's simply not their concern (I know, it's not nice, but hey). On top of that you're using ABS in a setting it wasn't really meant for. I wouldn't complain so much about it .

If you're mostly interested in running Linux binaries, why not use another distro that does still have support for 2.6.16? Should be easily solved, no?

lifanov · 2010-02-05 16:04:25

I'm not complaining. Sorry if it sounded like that.
Arch is a great distro for what it does and I used it myself for a very long time.
Using something else would miss the point because nothing else can compete with Arch package modernity and nothing else has AUR.
If there is a piece of software that comes out that anyone is remotely interested in, chances are, it already made its way to AUR.

FreeBSD ports tree already has everything one might need that runs natively, so using repos from another distro wouldn't be a huge gain, but AUR has some really obscure stuff.

Arch Linux

#1 2010-02-04 17:29:18

FATAL: kernel too old

#2 2010-02-04 19:39:37

Re: FATAL: kernel too old

#3 2010-02-04 19:52:41

Re: FATAL: kernel too old

#4 2010-02-04 20:22:25

Re: FATAL: kernel too old

#5 2010-02-04 21:20:48

Re: FATAL: kernel too old

#6 2010-02-05 01:42:29

Re: FATAL: kernel too old

#7 2010-02-05 05:18:41

Re: FATAL: kernel too old

#8 2010-02-05 15:56:54

Re: FATAL: kernel too old

#9 2010-02-05 16:04:25

Re: FATAL: kernel too old

Board footer