We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

17/04/05

Has got vserver running on a 6 way E4000. The procedure (in excessive detail) was:

Running Debian/SPARC 3.1 (sarge) ~ currently testing, installed:

kernel-source-2.4.27 version 2.4.27-8

kernel-patch-vserver version 1.9.5.3

then:

cd /usr/src

tar -xvj < kernel-source-2.4.27.tar.bz2

export PATCH_THE_KERNEL=yes

cd kernel-source-2.4.27

make-kpkg config menuconfig rootcmd fakeroot revision custom01 added-patches vserver --append-to-version +vserver --initrd binary_arch

(borrow the config file from 2.4.27-2-sparc64-smp)

cd ..

dpkg -i *.deb

reboot

All works fine.

22/04/05

... or so it seemed. A number of problems have arrisen.

Both the Debian 2.4.27 and 2.6.8 kernels build and run with the 1.9.5 patch however the exibit a number of problems:

After some analysis Bertl (via IRC) came to the conclusion that it was likely to be an interfacing problem between 32 bit userland apps and 64 bit kernel space. With some inspired hacking he managed to develop some syscall bindings that work for sparc64 and ppc, given they work when compiled as either 64 or 32 bit binaries this means they should work for sparc32 as well. He also says that the API used for the 2.6 kernels is mostly architecture and word size independant (except for a pointer used in passing filenames when dealing with quotas) and thus the chances of getting it working on 2.6 are much higher - that's where the effort should be (and is) going.

Tried 2.6.11.7-vs2.0-pre1 which seems to have the missing /proc/sys/vservers but is otherwise the same as 2.6.8.

It seems there are two possibilities (assuming that the kernel if functioning correctly - which we have (thus far) no reason to doubt):

1. compile up util-vserver as a 64 bit set of applications. This is really a hack rather than a long term solution as it would be cumbersome to distribute, etc.

2. integrate the new syscalls into util-vserver and it /should/ JFW (modulo the single use of pointers in the interface).

04/05/05

Bertl says that a 2.6.11 kernel with pre4, patched ( http://vserver.13thfloor.at/Stuff/DIETLIBC/ ) dietlibc 0.28 and vanilla

util-vserver 0.30.207 works.

15/05/05

Next attempt

kernel 2.6.11.9 patches, builds and runs fine with vs2.0-rc1

Building dietlibc requires some effort, the following patches

dietlibc-gethostbyname-fix01.diff

dietlibc-syscall-fix01.diff

from http://vserver.13thfloor.at/Stuff/DIETLIBC/ have to be applied and

.register %g2,#scratch

has to be added to libcompat/syscall.S and

  1. ifdef WANT_THREAD_SAFE

has to be commented out of dietfeatures.h

util-vserver-0.30.207 builds and links if -m64 is set in both CFLAGS and CXXFLAGS

chcontext and chbind both seem to work however vps and vtop don't as there seems to be a problem with unhiding the proc entries. Running vprocunhide gives:

Fixing /proc entries visibility.../usr/local/lib/util-vserver/vprocunhide: line 91: 11869 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11870 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11871 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11872 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11873 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11874 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11875 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11876 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11877 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11878 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11879 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11880 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11881 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11882 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11883 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11884 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11885 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11886 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11887 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11888 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11889 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11890 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11891 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11892 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11893 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11894 Bus error $_SETATTR -x "${params[@]}" "$@"

/usr/local/lib/util-vserver/vprocunhide: line 91: 11895 Bus error $_SETATTR -x "${params[@]}" "$@"

ERROR

A slightly more condensed example of this is:

  1. strace -o ~/trace -s 128 setattr --~hide /proc/uptime
umovestr: Input/output error

ptrace: umoven: Input/output error

  1. cat ~/trace
execve("/usr/local/sbin/setattr", ["setattr", "--~hide", "/proc/uptime"], [/* 13 vars */]) = 0

lstat(0xfffffecb, {...}) = 0

SYS_267(0, 0x3f, 0, 0, 0) = 65573

- SIGBUS (Bus error) @ 0 (0) -

+ killed by SIGBUS +

Which looks (to me) like an unaligned load / store but I could be wrong.

GDB initially suggests the fault occurs in perror(display_name); line 112, function handleFile of setattr.c By the looks of this it is called by vc_set_iattr (? failing and ?) returning -1.