Re: Tracking sarge
Kurt Yoder <[EMAIL PROTECTED]> writes: > On Feb 4, 2005, at 4:46 PM, Goswin von Brederlow wrote: > The iptables problems is known. You need a 64bit iptables. >>> >>> Do you know where this is? I tried compiling from source, but still >>> get >>> the error. I assume it's because I'm still compiling using 32-bit >>> libraries. >> >> Install the amd64 iptables package and amd64-libs. >> > > Sorry, maybe I'm just being dense, but I'm still having trouble with > this. > > Do you mean I should install the amd64-libs-dev and compile iptables > using th 64-bit libs? Or is there actually an amd64 compatible > iptables binary out there already? I found amd64-libs, but not an > amd64 iptables: You have to download the amd64 iptables from alioth and unpack/install it manually. Or create a 64bit chroot, install it there and then copy the binary and libs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge (Failed to create initrd image)
Petr Salinger <[EMAIL PROTECTED]> writes: >> The linux-gate.so library is the 32bit emulation layer of the kernels >> 32bit support. I don't know why it has to show up like this but that >> is how it is. > > This virtual ELF library is also in standard i386 2.6.x kernel. Even in 32bit kernels? That would make this a major issue. > Some information can be also found in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209145 > > > Fix for initrd-tools should be easy: > > --- /usr/sbin/mkinitrd.std 2005-01-23 19:38:08.0 +0100 > +++ /usr/sbin/mkinitrd 2005-02-15 18:46:16.0 +0100 > @@ -821,7 +821,7 @@ > else > x=$( > LD_LIBRARY_PATH=$INITRD_LD_LIBRARY_PATH \ > - ldd "$i" > + ldd "$i" | grep -v linux-gate.so > ) > fi > err=$? > > Petr In my bugreport I added the grep a few lines further down on the echo "$x" so even 2.4.x x86_64 kernels get the grep. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
On Feb 4, 2005, at 4:46 PM, Goswin von Brederlow wrote: The iptables problems is known. You need a 64bit iptables. Do you know where this is? I tried compiling from source, but still get the error. I assume it's because I'm still compiling using 32-bit libraries. Install the amd64 iptables package and amd64-libs. Sorry, maybe I'm just being dense, but I'm still having trouble with this. Do you mean I should install the amd64-libs-dev and compile iptables using th 64-bit libs? Or is there actually an amd64 compatible iptables binary out there already? I found amd64-libs, but not an amd64 iptables: [EMAIL PROTECTED]:~# apt-cache search amd-64 [EMAIL PROTECTED]:~# apt-cache search amd64 amd64-libs - Amd64 shared libraries for use on i386/x86_64 systems amd64-libs-dev - Amd64 development libraries and headers for use on i386/x86_64 systems dfsbuild - Build Debian From Scratch CD/DVD images kernel-headers-2.6-amd64-generic - Linux kernel headers for version 2.6 on generic x86_64 systems kernel-headers-2.6-amd64-k8 - Linux kernel headers for version 2.6 on AMD64 systems kernel-headers-2.6-amd64-k8-smp - Linux kernel headers for version 2.6 on AMD64 SMP systems kernel-headers-2.6.8-10-amd64-generic - Linux kernel headers 2.6.8 for generic x86_64 systems kernel-headers-2.6.8-10-amd64-k8 - Linux kernel headers for version 2.6.8 on AMD64 systems kernel-headers-2.6.8-10-amd64-k8-smp - Linux kernel headers for version 2.6.8 on AMD64 SMP systems kernel-image-2.6-amd64-generic - Linux kernel image for version 2.6 on generic x86_64 systems kernel-image-2.6-amd64-k8 - Linux kernel image for version 2.6 on AMD64 systems kernel-image-2.6-amd64-k8-smp - Linux kernel image for version 2.6 on AMD64 SMP systems kernel-image-2.6.8-10-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems kernel-image-2.6.8-10-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems kernel-image-2.6.8-10-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems kernel-patch-2.4-grsecurity - grsecurity kernel patch - 2.4.x security patch kernel-patch-kdb - Builtin kernel debugger lg-issue107 - Issue 107 of the Linux Gazette. linux32 - Wrapper to set the execution domain kernel-headers-2.6.9-9-amd64-generic - Linux kernel headers 2.6.9 for generic x86_64 systems kernel-headers-2.6.9-9-amd64-k8 - Linux kernel headers for version 2.6.9 on AMD64 systems kernel-headers-2.6.9-9-amd64-k8-smp - Linux kernel headers for version 2.6.9 on AMD64 SMP systems kernel-image-2.6.9-9-amd64-generic - Linux kernel image for version 2.6.9 on generic x86_64 systems kernel-image-2.6.9-9-amd64-k8 - Linux kernel image for version 2.6.9 on AMD64 systems kernel-image-2.6.9-9-amd64-k8-smp - Linux kernel image for version 2.6.9 on AMD64 SMP systems kernel-patch-grsecurity2 - grsecurity kernel patch - new major upstream version kernel-image-2.6.8-9-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems This was still using the aforementioned Debian testing and unstable 32-bit x86 sources. -- Kurt Yoder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge (Failed to create initrd image)
> The linux-gate.so library is the 32bit emulation layer of the kernels > 32bit support. I don't know why it has to show up like this but that > is how it is. This virtual ELF library is also in standard i386 2.6.x kernel. Some information can be also found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209145 Fix for initrd-tools should be easy: --- /usr/sbin/mkinitrd.std 2005-01-23 19:38:08.0 +0100 +++ /usr/sbin/mkinitrd 2005-02-15 18:46:16.0 +0100 @@ -821,7 +821,7 @@ else x=$( LD_LIBRARY_PATH=$INITRD_LD_LIBRARY_PATH \ - ldd "$i" + ldd "$i" | grep -v linux-gate.so ) fi err=$? Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
On Feb 15, 2005, at 11:44 AM, Goswin von Brederlow wrote: Hi, me again: Goswin von Brederlow <[EMAIL PROTECTED]> writes: Kurt Yoder <[EMAIL PROTECTED]> writes: Unpacking kernel-image-2.6-amd64-generic (from .../kernel-image-2.6-amd64-generic_100_i386.deb) ... Setting up kernel-image-2.6.8-9-amd64-generic (2.6.8-8) ... cpio: (0x): No such file or directory cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. Can you test the sid mkinitrd or is that the same version. That bug was reported some time ago and should have been fixed by now. Actualy the real culprit for that file is e2fsprogs. You need at least 1.35-7. From the changelog: * Filter out linux-gate.so, which is a pseudo entry for the 32->64bit translation for amd64 systems, in the initrd creation script. (Closes: #253595) MfG Goswin I installed current sid/unstable e2fsprogs (1.36release-1), and the initrd installation problem seems to have been resolved. I do still see a warning "cpio: (0x): No such file or directory", but now it doesn't seem to be fatal. Thanks for your help! Should there be something added to the amd64 documentation? Or maybe dependencies for the amd64 kernels such that e2fsprogs must be at least version 1.35-7? -- Kurt Yoder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Kurt Yoder <[EMAIL PROTECTED]> writes: > I just noticed that, according to "find", there is no "linux-gate.so" > on the system. I am unfortunately lacking in knowledge here. But if > there is no linux-gate.so on the system, wouldn't I be OK without the > "grep -v"? > > Sorry if that is an irrelevant question... The linux-gate.so library is the 32bit emulation layer of the kernels 32bit support. I don't know why it has to show up like this but that is how it is. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
On Feb 15, 2005, at 10:36 AM, Goswin von Brederlow wrote: Kurt Yoder <[EMAIL PROTECTED]> writes: On Feb 15, 2005, at 3:29 AM, Goswin von Brederlow wrote: That is the right one. My /usr/share/initrd-tools/scripts/e2fsprogs contains the following line: LIBS=`ldd $PROGS | grep -v linux-gate.so | sort -u | \ This looks like a partial line? I definitely don't have a line like that in my /usr/share/initrd-tools/scripts/e2fsprogs though. That is very strange. Maybe someone patched it for amd64 and forgot to increase the version. I will check into that. I just noticed that, according to "find", there is no "linux-gate.so" on the system. I am unfortunately lacking in knowledge here. But if there is no linux-gate.so on the system, wouldn't I be OK without the "grep -v"? Sorry if that is an irrelevant question... [EMAIL PROTECTED]:/tmp# apt-get install kernel-image-2.6.8-10-amd64-generic 2>&1 | tee log Reading Package Lists... Building Dependency Tree... Suggested packages: lilo kernel-doc-2.6.8 The following NEW packages will be installed: kernel-image-2.6.8-10-amd64-generic 0 upgraded, 1 newly installed, 0 to remove and 48 not upgraded. Need to get 12.6MB of archives. After unpacking 42.8MB of additional disk space will be used. Get:1 http://mirrors.kernel.org testing/main kernel-image-2.6.8-10-amd64-generic 2.6.8-11 [12.6MB] Fetched 12.6MB in 47s (266kB/s) Selecting previously deselected package kernel-image-2.6.8-10-amd64-generic. (Reading database ... 21247 files and directories currently installed.) Unpacking kernel-image-2.6.8-10-amd64-generic (from .../kernel-image-2.6.8-10-amd64-generic_2.6.8-11_i386.deb) ... Setting up kernel-image-2.6.8-10-amd64-generic (2.6.8-11) ... cpio: (0x): No such file or directory This is before the /usr/share/initrd-tools/scripts/e2fsprogs starts or sh -x would have shown some output already. So another script is buggy and needs to be fixed for the 32bit emulation. Ah. Then it looks to me like *something* is generating (or trying to generate) a file. But the script thinks the file is named "(0x)", when in actuality it should be named something else? So maybe the e2fsprogs script is OK? Do you have any ideas what script might be generating the "cpio: (0x): No such file or directory" message? Now /usr/share/initrd-tools/scripts/e2fsprogs starts: + cp /usr/share/e2fsprogs/initrd.ext3-add-journal /tmp/mkinitrd.4463/initrd/scripts/ext3-add-journal.sh + cp /sbin/tune2fs /tmp/mkinitrd.4463/initrd/sbin + cp /usr/bin/awk /tmp/mkinitrd.4463/initrd/bin/awk ++ ldd /sbin/tune2fs /usr/bin/awk Here the '| grep -v linux-gate.so' would be in my script. The rest is clear, without the grep it misbehaves. I guess I don't understand. I see: (... snipped normal-looking output of e2fsprogs...) + mkdir -p /tmp/mkinitrd.4982/initrd//lib + cp /lib/libuuid.so.1 /tmp/mkinitrd.4982/initrd//lib/libuuid.so.1 ++ dirname '/tmp/mkinitrd.4982/initrd/(0x)' + mkdir -p /tmp/mkinitrd.4982/initrd + cp '(0x)' '/tmp/mkinitrd.4982/initrd/(0x)' cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 So unless I am mistaken, it seems like a bogus file name "(0x)" is being set around the time I see the "cpio: No such file" message. e2fsprogs is unable to find the "0x00" file and gives up. So whether or not the "| grep -v linux-gate.so" is there, wouldn't I always get the same result? I suppose I could re-run the "regular" (32-bit x86) Debian installer to put me back on a 32-bit kernel and quit bothering everyone about this. However, I've noticed quite a few people who are having this problem (I run a blog where I posted about this error, and a lot of people seem to be looking for information on the error via search engine queries). So I'd prefer to fix and document the problem so everyone can benefit. -- Kurt Yoder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Hi, me again: Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Kurt Yoder <[EMAIL PROTECTED]> writes: >> Unpacking kernel-image-2.6-amd64-generic (from >> .../kernel-image-2.6-amd64-generic_100_i386.deb) ... >> Setting up kernel-image-2.6.8-9-amd64-generic (2.6.8-8) ... >> cpio: (0x): No such file or directory >> cp: cannot stat `(0x)': No such file or directory >> run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return >> code 1 >> Failed to create initrd image. > > Can you test the sid mkinitrd or is that the same version. That bug > was reported some time ago and should have been fixed by now. Actualy the real culprit for that file is e2fsprogs. You need at least 1.35-7. From the changelog: * Filter out linux-gate.so, which is a pseudo entry for the 32->64bit translation for amd64 systems, in the initrd creation script. (Closes: #253595) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Kurt Yoder <[EMAIL PROTECTED]> writes: > On Feb 15, 2005, at 3:29 AM, Goswin von Brederlow wrote: >> That is the right one. My /usr/share/initrd-tools/scripts/e2fsprogs >> contains the following line: >> >> LIBS=`ldd $PROGS | grep -v linux-gate.so | sort -u | \ >> > > This looks like a partial line? I definitely don't have a line like > that in my /usr/share/initrd-tools/scripts/e2fsprogs though. That is very strange. Maybe someone patched it for amd64 and forgot to increase the version. I will check into that. ... > I had tried alioth, but was unable to install any packages using > it. Is this the problem? I'm still using the 32-bit userland and > 64-bit kernel. Alioth has nothing there for 64bit kernel with 32bit userland. You have to use the official debian there. >> If so please change the first line from '#!/bin/sh' to '#!/bin/sh -x' >> and run >> >> apt-get install --reinstall kernel-image-2.6.8-9-amd64-generic 2>&1 >> | tee log >> >> >> MfG >> Goswin >> >> > > I no longer have 2.6.8-9 available, but I do have 2.6.8-10: > > > [EMAIL PROTECTED]:/tmp# apt-get install kernel-image-2.6.8-10-amd64-generic > 2>&1 | tee log > Reading Package Lists... > Building Dependency Tree... > Suggested packages: >lilo kernel-doc-2.6.8 > The following NEW packages will be installed: >kernel-image-2.6.8-10-amd64-generic > 0 upgraded, 1 newly installed, 0 to remove and 48 not upgraded. > Need to get 12.6MB of archives. > After unpacking 42.8MB of additional disk space will be used. > Get:1 http://mirrors.kernel.org testing/main > kernel-image-2.6.8-10-amd64-generic 2.6.8-11 [12.6MB] > Fetched 12.6MB in 47s (266kB/s) > Selecting previously deselected package > kernel-image-2.6.8-10-amd64-generic. > (Reading database ... 21247 files and directories currently installed.) > Unpacking kernel-image-2.6.8-10-amd64-generic (from > .../kernel-image-2.6.8-10-amd64-generic_2.6.8-11_i386.deb) ... > Setting up kernel-image-2.6.8-10-amd64-generic (2.6.8-11) ... > cpio: (0x): No such file or directory This is before the /usr/share/initrd-tools/scripts/e2fsprogs starts or sh -x would have shown some output already. So another script is buggy and needs to be fixed for the 32bit emulation. Now /usr/share/initrd-tools/scripts/e2fsprogs starts: > + cp /usr/share/e2fsprogs/initrd.ext3-add-journal > /tmp/mkinitrd.4463/initrd/scripts/ext3-add-journal.sh > + cp /sbin/tune2fs /tmp/mkinitrd.4463/initrd/sbin > + cp /usr/bin/awk /tmp/mkinitrd.4463/initrd/bin/awk > ++ ldd /sbin/tune2fs /usr/bin/awk Here the '| grep -v linux-gate.so' would be in my script. The rest is clear, without the grep it misbehaves. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
On Feb 15, 2005, at 3:29 AM, Goswin von Brederlow wrote:
Kurt Yoder <[EMAIL PROTECTED]> writes:
Sorry to reply so late...
On Feb 4, 2005, at 4:46 PM, Goswin von Brederlow wrote:
Can you test the sid mkinitrd or is that the same version. That bug
was reported some time ago and should have been fixed by now.
Where is the sid mkinitrd? I installed initrd-tools 0.1.77, and am
still getting this error.
That is the right one. My /usr/share/initrd-tools/scripts/e2fsprogs
contains the following line:
LIBS=`ldd $PROGS | grep -v linux-gate.so | sort -u | \
This looks like a partial line? I definitely don't have a line like
that in my /usr/share/initrd-tools/scripts/e2fsprogs though.
which should prevent that error.
Could you please double check that you actualy do have 0.1.77 and that
it contains that line?
I do have 0.1.77:
[EMAIL PROTECTED]:~# cat /usr/share/initrd-tools/version
VERSION=0.1.77
but it is from the main Debian sources. Here's my sources.list:
[EMAIL PROTECTED]:~# less /etc/apt/sources.list
#deb http://ftp.us.debian.org/debian/ sarge main
deb http://mirrors.kernel.org/debian/ testing main
deb-src http://mirrors.kernel.org/debian/ testing main
deb http://security.debian.org/ testing/updates main
deb http://mirrors.kernel.org/debian/ unstable main
deb-src http://mirrors.kernel.org/debian/ unstable main
#deb http://debian-amd64.alioth.debian.org/pure64 testing main
#deb-src http://debian-amd64.alioth.debian.org/pure64 testing main
#
#deb http://debian-amd64.alioth.debian.org/pure64 unstable main
#deb-src http://debian-amd64.alioth.debian.org/pure64 unstable main
I had tried alioth, but was unable to install any packages using it. Is
this the problem? I'm still using the 32-bit userland and 64-bit
kernel.
If so please change the first line from '#!/bin/sh' to '#!/bin/sh -x'
and run
apt-get install --reinstall kernel-image-2.6.8-9-amd64-generic 2>&1 |
tee log
MfG
Goswin
I no longer have 2.6.8-9 available, but I do have 2.6.8-10:
[EMAIL PROTECTED]:/tmp# apt-get install kernel-image-2.6.8-10-amd64-generic 2>&1
| tee log
Reading Package Lists...
Building Dependency Tree...
Suggested packages:
lilo kernel-doc-2.6.8
The following NEW packages will be installed:
kernel-image-2.6.8-10-amd64-generic
0 upgraded, 1 newly installed, 0 to remove and 48 not upgraded.
Need to get 12.6MB of archives.
After unpacking 42.8MB of additional disk space will be used.
Get:1 http://mirrors.kernel.org testing/main
kernel-image-2.6.8-10-amd64-generic 2.6.8-11 [12.6MB]
Fetched 12.6MB in 47s (266kB/s)
Selecting previously deselected package
kernel-image-2.6.8-10-amd64-generic.
(Reading database ... 21247 files and directories currently installed.)
Unpacking kernel-image-2.6.8-10-amd64-generic (from
.../kernel-image-2.6.8-10-amd64-generic_2.6.8-11_i386.deb) ...
Setting up kernel-image-2.6.8-10-amd64-generic (2.6.8-11) ...
cpio: (0x): No such file or directory
+ cp /usr/share/e2fsprogs/initrd.ext3-add-journal
/tmp/mkinitrd.4463/initrd/scripts/ext3-add-journal.sh
+ cp /sbin/tune2fs /tmp/mkinitrd.4463/initrd/sbin
+ cp /usr/bin/awk /tmp/mkinitrd.4463/initrd/bin/awk
++ ldd /sbin/tune2fs /usr/bin/awk
++ sort -u
++ awk '{print $3}'
++ dirname /tmp/mkinitrd.4463/initrd//lib/libblkid.so.1
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib
+ cp /lib/libblkid.so.1 /tmp/mkinitrd.4463/initrd//lib/libblkid.so.1
++ dirname /tmp/mkinitrd.4463/initrd//lib/libcom_err.so.2
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib
+ cp /lib/libcom_err.so.2 /tmp/mkinitrd.4463/initrd//lib/libcom_err.so.2
++ dirname /tmp/mkinitrd.4463/initrd//lib/tls/libc.so.6
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib/tls
+ cp /lib/tls/libc.so.6 /tmp/mkinitrd.4463/initrd//lib/tls/libc.so.6
++ dirname /tmp/mkinitrd.4463/initrd//lib/tls/libc.so.6
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib/tls
+ cp /lib/tls/libc.so.6 /tmp/mkinitrd.4463/initrd//lib/tls/libc.so.6
++ dirname /tmp/mkinitrd.4463/initrd//lib/libe2p.so.2
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib
+ cp /lib/libe2p.so.2 /tmp/mkinitrd.4463/initrd//lib/libe2p.so.2
++ dirname /tmp/mkinitrd.4463/initrd//lib/libext2fs.so.2
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib
+ cp /lib/libext2fs.so.2 /tmp/mkinitrd.4463/initrd//lib/libext2fs.so.2
++ dirname /tmp/mkinitrd.4463/initrd//lib/ld-linux.so.2
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib
+ cp /lib/ld-linux.so.2 /tmp/mkinitrd.4463/initrd//lib/ld-linux.so.2
++ dirname /tmp/mkinitrd.4463/initrd//lib/tls/libm.so.6
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib/tls
+ cp /lib/tls/libm.so.6 /tmp/mkinitrd.4463/initrd//lib/tls/libm.so.6
++ dirname /tmp/mkinitrd.4463/initrd//lib/libuuid.so.1
+ mkdir -p /tmp/mkinitrd.4463/initrd//lib
+ cp /lib/libuuid.so.1 /tmp/mkinitrd.4463/initrd//lib/libuuid.so.1
++ dirname '/tmp/mkinitrd.4463/initrd/(0x)'
+ mkdir -p /tmp/mkinitrd.4463/initrd
+ cp '(0x)' '/tmp/mkinitrd.4463/initrd/(0x)'
cp: cannot stat `(0x)': No such file or directory
run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return
code 1
Fail
Re: Tracking sarge
Kurt Yoder <[EMAIL PROTECTED]> writes: > Sorry to reply so late... > > On Feb 4, 2005, at 4:46 PM, Goswin von Brederlow wrote: >> Can you test the sid mkinitrd or is that the same version. That bug >> was reported some time ago and should have been fixed by now. >> > > Where is the sid mkinitrd? I installed initrd-tools 0.1.77, and am > still getting this error. That is the right one. My /usr/share/initrd-tools/scripts/e2fsprogs contains the following line: LIBS=`ldd $PROGS | grep -v linux-gate.so | sort -u | \ which should prevent that error. Could you please double check that you actualy do have 0.1.77 and that it contains that line? If so please change the first line from '#!/bin/sh' to '#!/bin/sh -x' and run apt-get install --reinstall kernel-image-2.6.8-9-amd64-generic 2>&1 | tee log MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Sorry to reply so late... On Feb 4, 2005, at 4:46 PM, Goswin von Brederlow wrote: The initrd on the other hand should work. What was the error? I was trying to install various kernel images, including one I compiled myself using make-kpkg. I would get past the kernel installation to the initrd installation and then see this: Unpacking kernel-image-2.6-amd64-generic (from .../kernel-image-2.6-amd64-generic_100_i386.deb) ... Setting up kernel-image-2.6.8-9-amd64-generic (2.6.8-8) ... cpio: (0x): No such file or directory cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. Can you test the sid mkinitrd or is that the same version. That bug was reported some time ago and should have been fixed by now. Where is the sid mkinitrd? I installed initrd-tools 0.1.77, and am still getting this error. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Sven Mueller <[EMAIL PROTECTED]> writes: > Or in other words: With a 64bit (amd64) kernel, where are the actual > limits for: > 32bit Apps ~4 GiB > 64bit Apps 17179869184 GiB theoretically ~262144 GiB on current CPUs (- a few GiB the kernel reserves) > > Thanks, > Sven MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Re: address space (was Re: Tracking sarge)
I guess other people might be interested in this too. Kurt --- Begin Message --- On Sun, Feb 06, 2005 at 01:24:26AM +0100, Sven Mueller wrote: > Kurt Roeckx wrote on 03/02/2005 18:24: > > > >Actually, you can use 4GB of address space for userspace. > > For 32bit userspace or also for 64bit userspace? > > Or in other words: With a 64bit (amd64) kernel, where are the actual > limits for: > 32bit Apps 4GB, but you can change it to 3GB if you want. > 64bit Apps /proc/cpuinfo says: address sizes : 40 bits physical, 48 bits virtual And from /usr/include/asm/processor: /* * User space process size: 512GB - 1GB (default). */ #define TASK_SIZE (0x007fc000) Which is only 39 bit. There is also this in page.h: /* See Documentation/x86_64/mm.txt for a description of the * memory map. */ #define __START_KERNEL 0x8010 #define __START_KERNEL_map 0x8000 #define __PAGE_OFFSET 0x0100 /* 1 << 40 */ #define __PHYSICAL_MASK_SHIFT 40 #define __PHYSICAL_MASK ((1UL << __PHYSICAL_MASK_SHIFT) - 1) #define __VIRTUAL_MASK_SHIFT48 #define __VIRTUAL_MASK ((1UL << __VIRTUAL_MASK_SHIFT) - 1) And from Documentation/x86_64/mm.txt: The paging design used on the x86-64 linux kernel port in 2.4.x provides: o per process virtual address space limit of 512 Gigabytes o top of userspace stack located at address 0x007f o PAGE_OFFSET = 0x8000 o start of the kernel = 0x8 o global RAM per system 2^64-PAGE_OFFSET-sizeof(kernel) = 128 Terabytes - 2 Gigabytes Note that that doc is about the 2.4 kernel and they're already talking about removing the 512GB per process limit. I think it shouldn't be a problem moving it to the 47 bit limit (512TB), but that's probably going to take some work. Kurt --- End Message ---
Re: Tracking sarge
Kurt Roeckx wrote on 03/02/2005 18:24: >> On Thu, Feb 03, 2005 at 05:54:35PM +0100, Goswin von Brederlow wrote: >> > >From what I heart you won't feel the difference. The advantage of a 64bit kernel lies in having more than 3GB address space (more than 4GB for 64bit) programs and the possibility of more than 4GB physical ram alltogether. > >> >> >> Actually, you can use 4GB of address space for userspace. For 32bit userspace or also for 64bit userspace? Or in other words: With a 64bit (amd64) kernel, where are the actual limits for: 32bit Apps 64bit Apps Thanks, Sven PS: Sorry Kurt for sending the initial reply to you privately. Was intended for this list. signature.asc Description: OpenPGP digital signature
Re: Tracking sarge
Kurt Yoder <[EMAIL PROTECTED]> writes: > > >> > I did this last week and ran into trouble. I could no longer use the >> > iptables binary, though the module was loading fine. I also was > unable >> > to install new kernels because something about the initrd installer >> > didn't like the new 64-bit kernel. >> >> The iptables problems is known. You need a 64bit iptables. > > Do you know where this is? I tried compiling from source, but still get > the error. I assume it's because I'm still compiling using 32-bit > libraries. Install the amd64 iptables package and amd64-libs. >> The initrd on the other hand should work. What was the error? > > I was trying to install various kernel images, including one I compiled > myself using make-kpkg. I would get past the kernel installation to the > initrd installation and then see this: > > Unpacking kernel-image-2.6-amd64-generic (from > .../kernel-image-2.6-amd64-generic_100_i386.deb) ... > Setting up kernel-image-2.6.8-9-amd64-generic (2.6.8-8) ... > cpio: (0x): No such file or directory > cp: cannot stat `(0x)': No such file or directory > run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return > code 1 > Failed to create initrd image. Can you test the sid mkinitrd or is that the same version. That bug was reported some time ago and should have been fixed by now. >> > From what I'd read in previous threads on this list, I got the >> > impression that "mix and match" using 32 bit user-space and 64-bit >> > kernel would not work. I had actually planned to reinstall using the >> > amd64 Debian installer. So if my understanding is incorrect and it > is >> > indeed possible to use a 64-bit kernel and 32-bit user-space, I'd > like >> > to know about it... >> >> It is possible with some glitches, like iptables or alsa not having a >> 32->64 bit translatio layer. > > I'm ok with alsa not working. Are there any other glitches that might > affect using this on a production server? Nothing I've seen being reported. > I guess what I really want to know is: what is the best way to get the > 64-bit performance advantages out of my hardware? I don't want glitches > with the software I'm running, such as Apache2, mod-perl, mysql, > postgres, and postfix. I would be OK with my currrent setup (32-bit > userland, 64-bit kernel), but it seems like there are reliability issues > doing this. Are these all taken care of by moving to 64-bit userland? > Are there any arguments *against* moving to 64-bit userland? > > > Thanks for your answers so far If you want risk free use 32bit kernel and 32bit userland. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Le vendredi 04 février 2005 à 10:01 -0500, Kurt Yoder a écrit : > > > > > I did this last week and ran into trouble. I could no longer use the > > > iptables binary, though the module was loading fine. I also was > unable > > > to install new kernels because something about the initrd installer > > > didn't like the new 64-bit kernel. > > > > The iptables problems is known. You need a 64bit iptables. > > Do you know where this is? I tried compiling from source, but still get > the error. I assume it's because I'm still compiling using 32-bit > libraries. Yes, maybe the amd64-libs-lev package is what you need? Let me know if you do it and succeed. [..] > > It is possible with some glitches, like iptables or alsa not having a > > 32->64 bit translatio layer. > > I'm ok with alsa not working. Are there any other glitches that might > affect using this on a production server? I'm running only one Pure64 server (Apache 2.0, Glasnost, SpamAssassin, ...), without any problem. It is running only free software, though. > I guess what I really want to know is: what is the best way to get the > 64-bit performance advantages out of my hardware? I don't want glitches > with the software I'm running, such as Apache2, mod-perl, mysql, > postgres, and postfix. I would be OK with my currrent setup (32-bit > userland, 64-bit kernel), but it seems like there are reliability issues > doing this. Are these all taken care of by moving to 64-bit userland? > Are there any arguments *against* moving to 64-bit userland? Running proprietary software (user-land) not available for amd64, though it may be circumvented with the chroot technique. I manage another 3 Opteron boxes where I had to stay 32-bits because of a hardware lock with only available proprietary kernel module. There are some Java programs running on those too, and I felt not confident about running them on Pure64, and was in a hurry so could not test before-hand. Last but not least, I manage also one dual-Opteron box with Sarge x86 on a 64-bits kernel because of Java again. > Thanks for your answers so far
Re: Tracking sarge
Jérôme Warnier wrote: Le jeudi 03 février 2005 à 20:14 +0100, Goswin von Brederlow a écrit : Kurt Yoder <[EMAIL PROTECTED]> writes: Alice Stamping <[EMAIL PROTECTED]> writes: Hello guys. Hopefully a quick question. I would like to use some AMD Opteron kit in production with Debian. I don't, therefore, fancy tracking unstable with these boxes. :) I want to track sarge with these computers. Is it possible to : - install Debian Sarge from the i386 iso yes - using make-kpkg build a 64-bit kernel on the newly installed box for the AMD 64 bit platform. Not comfortably. apt-get install kernel-image-2.6-amd64- kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon I did this last week and ran into trouble. I could no longer use the iptables binary, though the module was loading fine. I also was unable to install new kernels because something about the initrd installer didn't like the new 64-bit kernel. The iptables problems is known. You need a 64bit iptables. Any easy solution? Is there a package somewhere? In Sarge? Well, there are definitely AMD64 iptables packages in the Debian AMD64 port. They only seem to depend on (AMD64) libc6. The initrd on the other hand should work. What was the error? From what I'd read in previous threads on this list, I got the impression that "mix and match" using 32 bit user-space and 64-bit kernel would not work. I had actually planned to reinstall using the amd64 Debian installer. So if my understanding is incorrect and it is indeed possible to use a 64-bit kernel and 32-bit user-space, I'd like to know about it... It is possible with some glitches, like iptables or alsa not having a 32->64 bit translatio layer. Nothing else? As far as I know ALSA does have a translation layer (snd-ioctl32). But probably I don't know as much about that as Goswin :) -- Javier Kohen <[EMAIL PROTECTED]> ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
> > I did this last week and ran into trouble. I could no longer use the > > iptables binary, though the module was loading fine. I also was unable > > to install new kernels because something about the initrd installer > > didn't like the new 64-bit kernel. > > The iptables problems is known. You need a 64bit iptables. Do you know where this is? I tried compiling from source, but still get the error. I assume it's because I'm still compiling using 32-bit libraries. > The initrd on the other hand should work. What was the error? I was trying to install various kernel images, including one I compiled myself using make-kpkg. I would get past the kernel installation to the initrd installation and then see this: Unpacking kernel-image-2.6-amd64-generic (from .../kernel-image-2.6-amd64-generic_100_i386.deb) ... Setting up kernel-image-2.6.8-9-amd64-generic (2.6.8-8) ... cpio: (0x): No such file or directory cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. > > From what I'd read in previous threads on this list, I got the > > impression that "mix and match" using 32 bit user-space and 64-bit > > kernel would not work. I had actually planned to reinstall using the > > amd64 Debian installer. So if my understanding is incorrect and it is > > indeed possible to use a 64-bit kernel and 32-bit user-space, I'd like > > to know about it... > > It is possible with some glitches, like iptables or alsa not having a > 32->64 bit translatio layer. I'm ok with alsa not working. Are there any other glitches that might affect using this on a production server? I guess what I really want to know is: what is the best way to get the 64-bit performance advantages out of my hardware? I don't want glitches with the software I'm running, such as Apache2, mod-perl, mysql, postgres, and postfix. I would be OK with my currrent setup (32-bit userland, 64-bit kernel), but it seems like there are reliability issues doing this. Are these all taken care of by moving to 64-bit userland? Are there any arguments *against* moving to 64-bit userland? Thanks for your answers so far
Re: Tracking sarge
Le jeudi 03 février 2005 à 20:14 +0100, Goswin von Brederlow a écrit : > Kurt Yoder <[EMAIL PROTECTED]> writes: > > >> Alice Stamping <[EMAIL PROTECTED]> writes: > >> > >> > Hello guys. > >> > > >> > Hopefully a quick question. > >> > > >> > I would like to use some AMD Opteron kit in production with Debian. > > I > >> > don't, therefore, fancy tracking unstable with these boxes. :) > >> > > >> > I want to track sarge with these computers. Is it possible to : > >> > > >> > - install Debian Sarge from the i386 iso > >> > >> yes > >> > >> > - using make-kpkg build a 64-bit kernel on the newly installed box > >> > for the AMD 64 bit platform. > >> > >> Not comfortably. > >> > >> apt-get install kernel-image-2.6-amd64- > >> kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp > >> kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon > > > > I did this last week and ran into trouble. I could no longer use the > > iptables binary, though the module was loading fine. I also was unable > > to install new kernels because something about the initrd installer > > didn't like the new 64-bit kernel. > > The iptables problems is known. You need a 64bit iptables. Any easy solution? Is there a package somewhere? In Sarge? > The initrd on the other hand should work. What was the error? > > > From what I'd read in previous threads on this list, I got the > > impression that "mix and match" using 32 bit user-space and 64-bit > > kernel would not work. I had actually planned to reinstall using the > > amd64 Debian installer. So if my understanding is incorrect and it is > > indeed possible to use a 64-bit kernel and 32-bit user-space, I'd like > > to know about it... > > It is possible with some glitches, like iptables or alsa not having a > 32->64 bit translatio layer. Nothing else? Thanks a lot for the good work! > MfG > Goswin
Re: Tracking sarge
Kurt Yoder <[EMAIL PROTECTED]> writes: >> Alice Stamping <[EMAIL PROTECTED]> writes: >> >> > Hello guys. >> > >> > Hopefully a quick question. >> > >> > I would like to use some AMD Opteron kit in production with Debian. > I >> > don't, therefore, fancy tracking unstable with these boxes. :) >> > >> > I want to track sarge with these computers. Is it possible to : >> > >> > - install Debian Sarge from the i386 iso >> >> yes >> >> > - using make-kpkg build a 64-bit kernel on the newly installed box >> > for the AMD 64 bit platform. >> >> Not comfortably. >> >> apt-get install kernel-image-2.6-amd64- >> kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp >> kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon > > I did this last week and ran into trouble. I could no longer use the > iptables binary, though the module was loading fine. I also was unable > to install new kernels because something about the initrd installer > didn't like the new 64-bit kernel. The iptables problems is known. You need a 64bit iptables. The initrd on the other hand should work. What was the error? > From what I'd read in previous threads on this list, I got the > impression that "mix and match" using 32 bit user-space and 64-bit > kernel would not work. I had actually planned to reinstall using the > amd64 Debian installer. So if my understanding is incorrect and it is > indeed possible to use a 64-bit kernel and 32-bit user-space, I'd like > to know about it... It is possible with some glitches, like iptables or alsa not having a 32->64 bit translatio layer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
> Alice Stamping <[EMAIL PROTECTED]> writes: > > > Hello guys. > > > > Hopefully a quick question. > > > > I would like to use some AMD Opteron kit in production with Debian. I > > don't, therefore, fancy tracking unstable with these boxes. :) > > > > I want to track sarge with these computers. Is it possible to : > > > > - install Debian Sarge from the i386 iso > > yes > > > - using make-kpkg build a 64-bit kernel on the newly installed box > > for the AMD 64 bit platform. > > Not comfortably. > > apt-get install kernel-image-2.6-amd64- > kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp > kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon I did this last week and ran into trouble. I could no longer use the iptables binary, though the module was loading fine. I also was unable to install new kernels because something about the initrd installer didn't like the new 64-bit kernel. From what I'd read in previous threads on this list, I got the impression that "mix and match" using 32 bit user-space and 64-bit kernel would not work. I had actually planned to reinstall using the amd64 Debian installer. So if my understanding is incorrect and it is indeed possible to use a 64-bit kernel and 32-bit user-space, I'd like to know about it...
Re: Tracking sarge
On Thu, Feb 03, 2005 at 05:54:35PM +0100, Goswin von Brederlow wrote: > > >From what I heart you won't feel the difference. The advantage of a > 64bit kernel lies in having more than 3GB address space (more than 4GB > for 64bit) programs and the possibility of more than 4GB physical ram > alltogether. Actually, you can use 4GB of address space for userspace. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Alice Stamping <[EMAIL PROTECTED]> writes: > Hi, > > Many thanks for your quick reply. > > On Thu, 03 Feb 2005 16:24:27 +0100, Goswin von Brederlow > <[EMAIL PROTECTED]> wrote: >> Alice Stamping <[EMAIL PROTECTED]> writes: >> > I would like to use some AMD Opteron kit in production with Debian. I >> > don't, therefore, fancy tracking unstable with these boxes. :) >> > I want to track sarge with these computers. Is it possible to : >> > - install Debian Sarge from the i386 iso >> yes > > Good. > >> > - using make-kpkg build a 64-bit kernel on the newly installed box >> > for the AMD 64 bit platform. >> Not comfortably. >> apt-get install kernel-image-2.6-amd64- >> kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp >> kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon > > Less work for me if someone at Debian was kind enough to make a kernel > already. :) They have. Its even in sarge. >> > - build the packages we normally build from source from sources after >> > booting into the 64 bit kernel (e.g. apache/php) >> That needs all the build-depends too. A lot of building and all of it >> not prepared for in a 32bit userland. It's possible but a lot of work. > > Of course (I was planning to take a --get-selections from the current > Xeon doing the job, taking my own packages out, then running a > --set-selections on the new Opteron kit - that way I'll get the > build-deps, but of course they wont be 64-bit - that small matter had > escaped me.) > > If I just used a 64 bit kernel, and kept the rest of the system > tracking 32-bit packages, would I still see stronger performance than > an equivilently specced Xeon system? >From what I heart you won't feel the difference. The advantage of a 64bit kernel lies in having more than 3GB address space (more than 4GB for 64bit) programs and the possibility of more than 4GB physical ram alltogether. > Your help is very much appreciated. > > > BR > ALICE MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Hi, Many thanks for your quick reply. On Thu, 03 Feb 2005 16:24:27 +0100, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Alice Stamping <[EMAIL PROTECTED]> writes: > > I would like to use some AMD Opteron kit in production with Debian. I > > don't, therefore, fancy tracking unstable with these boxes. :) > > I want to track sarge with these computers. Is it possible to : > > - install Debian Sarge from the i386 iso > yes Good. > > - using make-kpkg build a 64-bit kernel on the newly installed box > > for the AMD 64 bit platform. > Not comfortably. > apt-get install kernel-image-2.6-amd64- > kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp > kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon Less work for me if someone at Debian was kind enough to make a kernel already. :) > > - build the packages we normally build from source from sources after > > booting into the 64 bit kernel (e.g. apache/php) > That needs all the build-depends too. A lot of building and all of it > not prepared for in a 32bit userland. It's possible but a lot of work. Of course (I was planning to take a --get-selections from the current Xeon doing the job, taking my own packages out, then running a --set-selections on the new Opteron kit - that way I'll get the build-deps, but of course they wont be 64-bit - that small matter had escaped me.) If I just used a 64 bit kernel, and kept the rest of the system tracking 32-bit packages, would I still see stronger performance than an equivilently specced Xeon system? Your help is very much appreciated. BR ALICE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking sarge
Alice Stamping <[EMAIL PROTECTED]> writes: > Hello guys. > > Hopefully a quick question. > > I would like to use some AMD Opteron kit in production with Debian. I > don't, therefore, fancy tracking unstable with these boxes. :) > > I want to track sarge with these computers. Is it possible to : > > - install Debian Sarge from the i386 iso yes > - using make-kpkg build a 64-bit kernel on the newly installed box > for the AMD 64 bit platform. Not comfortably. apt-get install kernel-image-2.6-amd64- kernel-image-2.6-amd64-generic kernel-image-2.6-amd64-k8-smp kernel-image-2.6-amd64-k8 kernel-image-2.6-amd64-xeon > - build the packages we normally build from source from sources after > booting into the 64 bit kernel (e.g. apache/php) That needs all the build-depends too. A lot of building and all of it not prepared for in a 32bit userland. It's possible but a lot of work. > - keep the rest tracking the 32 bit sarge repositories > > ... and enjoy a machine with the kernel and some of the apps running a > nice 64 bit build, and the rest of the software running 32 bit > versions? > > My understanding is clearly a little ropey, but I want to ensure we're > not going to waste money on this kit if it's not going to earn us some > performance increase. > > BR > ALICE I would suggest installing a 64bit chroot and compiling 64 bit software there directly. For e.g. apache you probably want to run it inside a chroot anyway for security reasons. For user programs adding a dchroot wrapper works fine or, if you realy want, copy the binary and any needed libs to outside the chroot (look at the amd64-libs package for locations). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
