Re: is it em64t ?
Le jeudi 05 janvier 2006 à 11:09 +0100, Erik Mouw a écrit : On Thu, Jan 05, 2006 at 10:22:51AM +0100, Koen Vermeer wrote: On Thu, 2006-01-05 at 17:04 +0800, zzz haha wrote: i have a p4 machine. how can i know if it has em64t? A somewhat stupid but nevertheless possibly useful suggestion: Try to boot the Debian x86-64 installation CD. If it works, you either have an em64t or an amd64 processor. Since you state your machine is a p4, you may safely rule out the latter possibility. Alternatively, try to find out what processor is in there, and check the Intel website. Maybe there's also a flag in /proc/cpuinfo that indicates em64t capabilities. The lm flag in /proc/cpuinfo tells the CPU can do long mode, which means it has the 64 bit extensions. By the way: I need to work on a Xeon machine remotely, and I wondered if it had multiple processors (it is not a dual-core) or simply HyperThreading. How can I distinguish? Here is /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping: 1 cpu MHz : 3001.253 cache size : 1024 KB physical id : 0 siblings: 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid bogomips: 5947.39 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping: 1 cpu MHz : 3001.253 cache size : 1024 KB physical id : 0 siblings: 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid bogomips: 5996.54 Thanks Erik -- Jérôme Warnier FLOSS Consultant http://beeznest.neteb
Re: is it em64t ?
Jerome Warnier wrote: By the way: I need to work on a Xeon machine remotely, and I wondered if it had multiple processors (it is not a dual-core) or simply HyperThreading. How can I distinguish? Here is /proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid I'm no expert in processors, but I'd guess that ht there in the flags means it has HyperThreading support. -- Please recycle. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it em64t ?
Jerome Warnier wrote: By the way: I need to work on a Xeon machine remotely, and I wondered if it had multiple processors (it is not a dual-core) or simply HyperThreading. How can I distinguish? Here is /proc/cpuinfo: processor : 0 ... physical id : 0 siblings: 2 ... processor : 1 ... physical id : 0 siblings: 2 You can see two logical processors (numbered 0 and 1), which are both parts of a single physical processor (with physical id 0). Each processor is one of 2 siblings. = this is a single hyperthreaded processor Michal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it em64t ?
Le samedi 07 janvier 2006 à 21:46 +1100, Hamish Moffatt a écrit : On Sat, Jan 07, 2006 at 08:34:31AM -0200, Eduardo M KALINOWSKI wrote: Jerome Warnier wrote: By the way: I need to work on a Xeon machine remotely, and I wondered if it had multiple processors (it is not a dual-core) or simply HyperThreading. How can I distinguish? Here is /proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid I'm no expert in processors, but I'd guess that ht there in the flags means it has HyperThreading support. It does, but what if HyperThreading was present but disabled in the BIOS? I don't know how you would tell in that case. Or SMP support disabled in the kernel. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- Jérôme Warnier FLOSS Consultant http://beeznest.net
Re: is it em64t ?
Le samedi 07 janvier 2006 à 11:56 +0100, Michal Schmidt a écrit : Jerome Warnier wrote: By the way: I need to work on a Xeon machine remotely, and I wondered if it had multiple processors (it is not a dual-core) or simply HyperThreading. How can I distinguish? Here is /proc/cpuinfo: processor : 0 ... physical id : 0 siblings: 2 ... processor : 1 ... physical id : 0 siblings: 2 You can see two logical processors (numbered 0 and 1), which are both parts of a single physical processor (with physical id 0). Each processor is one of 2 siblings. = this is a single hyperthreaded processor Thanks, this is all I wanted to know, exactly the way I wanted it. Michal -- Jérôme Warnier FLOSS Consultant http://beeznest.net
Re: is it em64t ?
On Saturday 07 January 2006 11:46, Hamish Moffatt wrote: It does, but what if HyperThreading was present but disabled in the BIOS? I don't know how you would tell in that case. Most of these flags are not set simply because the kernel found a certain type of processor. They are the result of elaborate startup tests which detect these capabilities. If a capability is disabled in the bios, two things can happen 1) the kernel does not detect it at all; in which case the relevant flag is not set; 2) the kernel detects the capability but switched off; in which case the kernel will attempt to switch it on (if it can of course). If this succeeds the flag is set, if not you will often see an error and the flag is not switched on. I have been told, however, that a few processor capabilities are so bound to the a certain type of cpu that their flag is simply set if that cpu is found. I don't know under which category the hyperthreading flag falls, but knowing that hyperthreading can be disabled in the bios, I would not expect the kernel to simply set that flag blindly. Ernest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Qt 4.1 for debian amd64?
qt 4.1 is in unstable. On Friday 06 January 2006 12:13, Lars Schimmer wrote: Hi! Is there any package for Qt4.1 out there ? I try to built OpenWengoNG and this piece of Software really needs Qt 4.1 Cya Lars -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel.: +43 316 873-5405 E-Mail: [EMAIL PROTECTED] PGP-Key-ID: 0xB87A0E03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How PGP-key update
Hello all, are there no pgp keys for testing or unstable ? Why will apt-get update do not update the keys ? Any clue ? This is, what apt-get update is telling me: - snip OK ftp://ftp.de.debian.org unstable/non-free Sources Es wurden 1513B in 21s geholt (71B/s) W: GPG error: ftp://ftp.gwdg.de unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY BB5E459A529B8BDA W: GPG error: ftp://debian.tu-bs.de testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F W: GPG error: ftp://ftp.nerim.net sid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907 W: GPG error: ftp://ftp.de.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F W: GPG error: ftp://ftp.de.debian.org unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F E: Konnte Lock /var/lib/dpkg/lock nicht bekommen - open (11 Die Ressource ist zur Zeit nicht verfügbar) E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it? - snap Best regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone willing to seed sarge amd64 isos?
On Fri, Jan 06, 2006 at 08:56:35AM -0500, Lennart Sorensen wrote: Given the number of very fast mirrors debian has for http and ftp, jigdo is actually a rather efficient method. Well, in the past I had quite the opposite experiences. Jigdo downloads a lot of small files, and one extra HTTP query per file presents a _huge_ overhead. Downloading an image with jigdo is at least 2-4 times slower than downloading the single ISO image from the very same mirror. The interesting effect is that the faster your network connection the bigger the difference in speed will be. You can help somewhat if you increase the number of files to process in a batch (back when I played with it I had to edit the jigdo script for this; I don´t remember the numbers but about a 10 times increase noticably reduced the download time). Jigdo helps only if you already have an older version of the image and there are not much updates. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How PGP-key update
Hi,
On Sat, Jan 07, 2006 at 01:49:21PM +0100, Hans wrote:
are there no pgp keys for testing or unstable ? Why will apt-get update do
not update the keys ? Any clue ?
apt-get update should never ever update the keys automagically.
There is you (The Administrator) who declare trusted sites.
apt-get update can only refetch the {Release,Package,Source}.gpg and check
signatures.
Warnings you got from apt-get update just says that those repositories
are not trusted.
To trust declare the repository as trusted just should fetch a key
for the repository, make sure it is a valid key then run apt-key add.
For example, to make an official Debian repository trusted you should run:
wget http://ftp-master.debian.org/ziyi_key_2006.asc
apt-key add ziyi_key_2006.asc
If you just want to declare a repository as trusted just run:
gpg --recv-key KEY_ID gpg -a --export KEY_ID | apt-key add -
where KEY_ID is a string after NO_PUBKEY. For example for Blackdown
at ftp.gwdg.de you should replace KEY_ID with BB5E459A529B8BDA.
And last but not least.
To be precise: by adding a key to apt-get keyring you will trust
_all_ repositories signed with this key.
W: GPG error: ftp://debian.tu-bs.de testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY
010908312D230C5F
pub 1024D/2D230C5F 2006-01-03 [expires: 2007-02-07]
uid Debian Archive Automatic Signing Key (2006) [EMAIL
PROTECTED]
Well, you have a 32bit Debian on your box, isn't it?
Only officially released architecures are signed with
Debian Archive Automatic Signing Key. This key is change every year and you
should check http://ftp-master.debian.org/ for updates.
AMD64 is not yet a part of official Debian release and it is
signed with different key you can fetch from:
ftp://debian.tu-bs.de:/debian-amd64/archive.key
Best regards
Artur
--
Tata: Jak się nazywasz?
Synek: Igor spacja Sapijaszko.
signature.asc
Description: Digital signature
Re: install ifort 9.0 with alien...
Hi,
I just stumbled across the post (via a google search) on 13 Dec 2005 by
[EMAIL PROTECTED] about getting the Intel em64t compilers to work on amd64
debian. I got this to work a couple of days ago so am just sharing how I did
it...
Two points - first is the ia32-libs package needs to be installed (as Len
Sorensen had suggested to Fred).
Second - dh_gencontrol does not know that em64t and amd64 are the same. A
solution is to manually change em64t to amd64 during the alien conversion of
the Intel rpm.
1. alien -gsk to build a directory with all the necessary files - see the -g
flag of alien in the man page.
2. edit the debian/control file and change the architecture from em64t to
amd64.
3. run debian/rules binary to build the package. It complains about some
libstdc++ dependencies but apart from that it works for me.
Regards,
Daniel
On Tue, Dec 13, 2005 at 08:39:10PM +0100, fred wrote:
Hi all,
I attempt to install intel fortran compiler 9.0 amd64/EM64T
(intel-iforte9-9.0-021.em64t.rpm) with alien.
But alien fails :
alien intel-iforte9-9.0-021.em64t.rpm
Package build failed. Here's the log:
dh_testdir
dh_testdir
dh_testroot
dh_clean -k -d
dh_installdirs
dh_installdocs
dh_installchangelogs
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
xargs -0 -r -i cp -a {} debian/intel-iforte9
dh_compress
dh_makeshlibs
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libcprts.so: File
format not recognized
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libcxa.so: File
format not recognized
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libcxaguard.so: File
format not recognized
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libifcore.so: File
format not recognized
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libifcoremt.so: File
format not recognized
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libifport.so: File
format not recognized
objdump: debian/intel-iforte9/opt/intel/fce/9.0/lib/libunwind.so: File
format not recognized
dh_installdeb
dh_shlibdeps
/usr/bin/ldd: line 1: /lib/ld-linux.so.2: No such file or directory
ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)
dpkg-shlibdeps: failure: ldd on
`debian/intel-iforte9/opt/intel/fce/9.0/bin/codecov' gave error exit
status 1
dh_shlibdeps: command returned error code 256
make: [binary-arch] Error 1 (ignored)
dh_gencontrol
dpkg-gencontrol: error: current build architecture amd64 does not appear
in package's list (em64t)
dh_gencontrol: command returned error code 65280
make: *** [binary-arch] Error 1
find: intel-iforte9-9.0: No such file or directory
In fact, several *.so file are ascii text :
cat libunwind.so
INPUT ( libunwind.so.5 )
I could link these files alien would erase them.
What's wrong ?
-
Dr. Daniel Grimwood Room : 303.208
Nanochemistry Research Institute Email: [EMAIL PROTECTED]
Curtin University of Technology Phone: +61 8 9266 3204 (office)
P.O. Box U 1987, Perth +61 8 9266 3780 (lab)
Western Australia, 6845 Australia Fax : +61 8 9266 4699
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How PGP-key update
Am Samstag, 7. Januar 2006 15:21 schrieb Artur R. Czechowski:
Hi,
On Sat, Jan 07, 2006 at 01:49:21PM +0100, Hans wrote:
are there no pgp keys for testing or unstable ? Why will apt-get update
do not update the keys ? Any clue ?
Hi Artur, that help was great !
It is working now ! Thank you very much !
apt-get update should never ever update the keys automagically.
There is you (The Administrator) who declare trusted sites.
apt-get update can only refetch the {Release,Package,Source}.gpg and check
signatures.
Warnings you got from apt-get update just says that those repositories
are not trusted.
To trust declare the repository as trusted just should fetch a key
for the repository, make sure it is a valid key then run apt-key add.
For example, to make an official Debian repository trusted you should run:
wget http://ftp-master.debian.org/ziyi_key_2006.asc
apt-key add ziyi_key_2006.asc
If you just want to declare a repository as trusted just run:
gpg --recv-key KEY_ID gpg -a --export KEY_ID | apt-key add -
I did so !
where KEY_ID is a string after NO_PUBKEY. For example for Blackdown
at ftp.gwdg.de you should replace KEY_ID with BB5E459A529B8BDA.
Yes, I understand now the mechanismen.
And last but not least.
To be precise: by adding a key to apt-get keyring you will trust
_all_ repositories signed with this key.
W: GPG error: ftp://debian.tu-bs.de testing Release: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 010908312D230C5F
pub 1024D/2D230C5F 2006-01-03 [expires: 2007-02-07]
uid Debian Archive Automatic Signing Key (2006)
[EMAIL PROTECTED]
Well, you have a 32bit Debian on your box, isn't it?
I have both on different computers: desktop is 32-bit (still) and notebook is
64-bit (AMD)
Only officially released architecures are signed with
Debian Archive Automatic Signing Key. This key is change every year and you
should check http://ftp-master.debian.org/ for updates.
AMD64 is not yet a part of official Debian release and it is
signed with different key you can fetch from:
ftp://debian.tu-bs.de:/debian-amd64/archive.key
Yes, this works, too !
Best regards
Artur
Thanks a lot !
Best regards
Hans
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First Kernel Build Attempt Failed was: Re: 3ware 9550 SATA RAID controller problems
On Fri, Jan 06, 2006 at 06:37:43PM -0500, Stephen Woodbridge wrote: Lennart Sorensen wrote: On Fri, Jan 06, 2006 at 01:11:04AM -0500, Stephen Woodbridge wrote: Tried to build my first kernel, but no joy. This is what I did ... cd /usr/src wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.15.tar.bz2 Try getting the linux-source package from unstable instead. It has debian's patches and such. You can also get the config file from one of the newer kernels for your cpu as a start for oldconfig. It's a big jump from 2.6.8 to 2.6.15. A lot has changed. For that matter, you could probably see if there is a new linux-image package already for your cpu in unstable. Would be even simpler. Len Sorensen I tried to install it: sudo apt-get install linux-image-2.6.15-1-em64t-p4-smp The following packages have unmet dependencies: linux-image-2.6.15-1-em64t-p4-smp: Depends: yaird but it is not going to be installed or initramfs-tools but it is not going to be installed or linux-initramfs-tool I tried to install yaird: sudo apt-get install yaird The following packages have unmet dependencies: yaird: Depends: libc6 (= 2.3.5-1) but 2.3.2.ds1-22 is to be installed yaird is at backports.org but there are no amd64 arch packages at backports.org. Someone mentioned back porting yaird, how would I go about doing that if that is the right thing to do? apt-get source -b yaird If it has any build dependancies, do those too. It only depends on libc6 2.3.5-1 because it was build on sid not sarge. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it em64t ?
On Sat, Jan 07, 2006 at 11:00:44AM +0100, Jerome Warnier wrote: processor : 0 [snip] physical id : 0 siblings: 2 [snip] processor : 1 physical id : 0 siblings: 2 [snip] Both CPUs are physical ID 0 and both say they are part of a set of 2 siblings. I am quite sure that means it is using hyperthreading, and is not dual core or dual cpu. Just hyperthreading. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone willing to seed sarge amd64 isos?
On Sat, Jan 07, 2006 at 02:16:40PM +0100, Gabor Gombas wrote: Well, in the past I had quite the opposite experiences. Jigdo downloads a lot of small files, and one extra HTTP query per file presents a _huge_ overhead. Downloading an image with jigdo is at least 2-4 times slower than downloading the single ISO image from the very same mirror. The interesting effect is that the faster your network connection the bigger the difference in speed will be. wget uses persistent connections for every 10 files for jigdo, and the overhead is maybe 100bytes per file. There are not very many files in debian where this will work out to more than 1% overhead. You can help somewhat if you increase the number of files to process in a batch (back when I played with it I had to edit the jigdo script for this; I don?t remember the numbers but about a 10 times increase noticably reduced the download time). So change it to do 100 files at a time. The few seconds for each batch of 10 for the connection certainly could add up, and the persistent connection used longer could help that. Increases temp disk space slightly of course. Jigdo helps only if you already have an older version of the image and there are not much updates. Well for that it is very good. It also doesn't use any outgoing bandwidth, or depend on other people to be doing something special. Much more reliable that way. I find it no problem to saturate a decent connection with jigdo, although upping the 10 files at a time does help. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How do I know if...
Hi, I have not yet successfully installed an AMD64 port (tried several times, but keep getting a kernel panic for some reason), but when I do, I'd like to know and be sure that I'm using 64-bit mode, and not 32-bit mode. How can I check this to make sure I'm running the AMD64 port installation in 64-bit mode? Thanks much! Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Xorg 6.9.0.dfsg.1-2 20060107025648
It's good to see this appear in the unstable repository. Unfortunately I get a blank screen with it. The video card is an ATI Radeon 9600 (RV350 AP) on an ASUS K8V-X main board Kernel 2.6.15-1-amd64-k8. Processor AMD 64 3400+ SSH from another machine shows that the Xorg process is running at 99% or thereabouts. Console switching doesn't work and although kdm is called from the boot screen it doesn't get as far as appearing in the process table In the process of trying to get to a usable screen I appear to have lost any helpful Xorg.0.log messages in favour of No screens found when trying fbdev before settling for vesa. But having just swapped xorg.conf files again I can't see many warnings other than dri being experimental and missing font directories; in particular it finishes with some routine looking warnings about already registered font renderers rather than any error messages or warnings. I was looking forward to having my card supported by Xorg; no doubt in a few days it will be. Did I post to the right place, and would you like me to post an affected log? Angus Mackenzie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg blows up on etch amd64
On Saturday 07 January 2006 20:55, Aaron Stromas wrote: Greetings, Pid: 17468, comm: dpkg Not tainted 2.6.12-1-amd64-generic is the Oops systematic ? (every time you do the upgrade), or sporadic ? in the second case you might have a hardware problem. possibly memory. Try checking it with memtest86+ (apt-get install memtest86+) If it is systematic, as you are running an older kernel there is probably no point in sending this in as a kernel problem. Upgrading is your best bet. What you could do on a short notice is change the kernel you use from the generic one to one of the specific kernels for your processor. Etch has these other two kernel : linux-image-2.6.12-10-em64t-p4 linux-image-2.6.12-10-amd64-k8 the first one runs best on Intel, the other one on AMD. Cheers, Ernest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg blows up on etch amd64
On 1/7/06, Ernest jw ter Kuile [EMAIL PROTECTED] wrote: On Saturday 07 January 2006 20:55, Aaron Stromas wrote: Greetings, Pid: 17468, comm: dpkg Not tainted 2.6.12-1-amd64-genericis the Oops systematic ? (every time you do the upgrade), or sporadic ? in the second case you might have a hardware problem. possibly memory. Try checkingit with memtest86+ (apt-get install memtest86+)If it is systematic, as you are running an older kernel there is probably nopoint in sending this in as a kernel problem. Upgrading is your best bet. Systematic. What you could do on a short notice is change the kernel you use from the generic one to one of the specific kernels for your processor. This is an AMD Athlon 3000 box running linux-image-2.6-amd64-generic kernel Etch has these other two kernel :linux-image-2.6.12-10-em64t-p4linux-image-2.6.12-10-amd64-k8 the first one runs best on Intel, the other one on AMD.linux-image-2.6.12-10-amd64-k8, then? I'll give it a shot. Many thanks,-a Cheers,Ernest.--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SOLVED: dpkg blows up on etch amd64
On 1/7/06, Ernest jw ter Kuile [EMAIL PROTECTED] wrote: On Saturday 07 January 2006 20:55, Aaron Stromas wrote: Greetings, Pid: 17468, comm: dpkg Not tainted 2.6.12-1-amd64-genericEtch has these other two kernel :linux-image-2.6.12-10-em64t-p4 linux-image-2.6.12-10-amd64-k8the first one runs best on Intel, the other one on AMD.Installing linux-image-2.6.12-10-amd64-k8 (I have AMD Athlon) allows me to run apt-get. Thanks a 1M Ernest! -a
Re: How do I know if...
2006/1/7, Robert Cates [EMAIL PROTECTED]: Hi, I have not yet successfully installed an AMD64 port (tried several times, but keep getting a kernel panic for some reason), but when I do, Maybe you have sata devices. You can have a punch of solutions to many problems that appear during debian amd64 installation in the list archive. I'd like to know and be sure that I'm using 64-bit mode, and not 32-bit mode. How can I check this to make sure I'm running the AMD64 port installation in 64-bit mode? I belive there's nothing like a switch or command to do this. Debian AMD64 is a port based in a 64 bit kernel that supports either 32 and 64bit executables. Up till now all* the binary packages in debian AMD64 are 64bit so you will be what you call 64bit mode. But with the correct configuration and libs you can also run 32bit apps. * I think there's a package with the 32bit version of Openoffice and another package with 32bit librarys to easy the usage of 32 bit apps. Regards Aritz Beraza [Rei] -- Aritz Beraza Garayalde [Rei] ___ [ WWW ] http://www.ayanami.es [jabber] rei[en]bulmalug.net
Re: How do I know if...
On Sun, 8 Jan 2006 01:18:12 +0100 Aritz Beraza Garayalde [Rei] [EMAIL PROTECTED] wrote: 2006/1/7, Robert Cates [EMAIL PROTECTED]: Hi, I have not yet successfully installed an AMD64 port (tried several times, but keep getting a kernel panic for some reason), but when I do, Maybe you have sata devices. You can have a punch of solutions to many problems that appear during debian amd64 installation in the list archive. Yeah, I had that fun. But I did not get kernel panics, instead the installation could not find the drive at all. Unless the installation used a newer kernel than was installed, this shouldn't have been the problem. I'd like to know and be sure that I'm using 64-bit mode, and not 32-bit mode. How can I check this to make sure I'm running the AMD64 port installation in 64-bit mode? uname -a -- David L. Johnson __o | A foolish consistency is the hobgoblin of little minds, adored _`\(,_ | by little statesmen and philosophers and divines. --Ralph Waldo (_)/ (_) | Emerson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: install ifort 9.0 with alien...
Giacomo Mulas wrote: Yes, it works but... it will litter your nice standard debian filesystem with foreign directories, such as /opt and friends which are so standard on red hat, fedora and similar. I suggest (as I did myself) to add a 2.5 step in which you move files and directories to some decent debian-conforming place. This also involves minimal editing of the executable scripts, but you will get a clean, debian-conforming filesystem hierarchy, with no things in odd places. Yes that would be easy to do. The executable scripts need editing anyway, so it's not much extra work. I should rewrite my conversion script to do this properly. I asked Joey Hess about em64t vs amd64 and he said it is fixed in alien 8.61. Regards, Daniel. - Dr. Daniel Grimwood Room : 303.208 Nanochemistry Research Institute Email: [EMAIL PROTECTED] Curtin University of Technology Phone: +61 8 9266 3204 (office) P.O. Box U 1987, Perth +61 8 9266 3780 (lab) Western Australia, 6845 Australia Fax : +61 8 9266 4699 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it em64t ?
Just an example powerrechner:/# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping: 1 cpu MHz : 3000.261 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips: 6007.19 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping: 1 cpu MHz : 3000.261 cache size : 1024 KB physical id : 3 siblings: 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips: 6000.44 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping: 1 cpu MHz : 3000.261 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips: 6000.42 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping: 1 cpu MHz : 3000.261 cache size : 1024 KB physical id : 3 siblings: 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips: 6000.44 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: This is a dual Xeon with ht. Also an em64t. Am Samstag 07 Januar 2006 20:43 schrieb Lennart Sorensen: On Sat, Jan 07, 2006 at 11:00:44AM +0100, Jerome Warnier wrote: processor : 0 [snip] physical id : 0 siblings: 2 [snip] processor : 1 physical id : 0 siblings: 2 [snip] Both CPUs are physical ID 0 and both say they are part of a set of 2 siblings. I am quite sure that means it is using hyperthreading, and is not dual core or dual cpu. Just hyperthreading. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First Kernel Build Attempt Failed was: Re: 3ware 9550 SATA RAID controller problems
Fixed the cross-compile problem by adding --arch=amd64 to the make-kpkg command and the kernel compiles but of the package is strange and it will not install. fakeroot make-kpkg --arch=amd64 --initrd --append-to-version=.20060107 kernel-image The package name is: linux-image-2.6.15.20060107_2.6.15.20060107-10.00.Custom_amd64.deb which is strange because I gave the target as kernel-image not linux-image and 2.6.15.20060107 is added to the name twice. and yaird failed on the install see below. -Steve [EMAIL PROTECTED]:/usr/src$ sudo dpkg -i linux-image-2.6.15.20060107_2.6.15.20060107-10.00.Custom_amd64.deb Password: Selecting previously deselected package linux-image-2.6.15.20060107. (Reading database ... 41199 files and directories currently installed.) Unpacking linux-image-2.6.15.20060107 (from linux-image-2.6.15.20060107_2.6.15.20060107-10.00.Custom_amd64.deb) ... Done. Setting up linux-image-2.6.15.20060107 (2.6.15.20060107-10.00.Custom) ... Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. yaird error: unknown kernel version: 2.6.15.20060107 (fatal) mkinitrd.yaird failed to create initrd image. Failed to create initrd image. dpkg: error processing linux-image-2.6.15.20060107 (--install): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: linux-image-2.6.15.20060107 [EMAIL PROTECTED]:/usr/src$ sudo dpkg -P linux-image-2.6.15.20060107 (Reading database ... 41349 files and directories currently installed.) Removing linux-image-2.6.15.20060107 ... Running postrm hook /sbin/update-grub . Searching for GRUB installation directory ... found: /boot/grub . Purging configuration files for linux-image-2.6.15.20060107 ... Running postrm hook /sbin/update-grub . Searching for GRUB installation directory ... found: /boot/grub . dpkg: error processing linux-image-2.6.15.20060107 (--purge): subprocess post-removal script returned error exit status 128 Errors were encountered while processing: linux-image-2.6.15.20060107 Stephen Woodbridge wrote: OK, I am making some progress ... I found this link and it seems pretty clean and straight forward. http://www.dominik-epple.de/Sarge-Linux_2.6.14-yaird/ and I have followed these steps except I'm using 2.6.15, ie: Backporting yaird, texi2html, make, kernel-package I spent all day going through menuconfig and follow an example config file the Andrew sent me. But when I try to compile the kernel it looks like it thinks it should be trying to cross compile. I'm wonder if it is somehow confused by the packages I backported? $ fakeroot make-kpkg --initrd --append-to-version=.20060107 kernel-image [snip] /usr/bin/make EXTRAVERSION=.20060107 ARCH=x86_64 \ CROSS_COMPILE=x86_64-linux- bzImage make[1]: Entering directory `/usr/src/linux-2.6.15' CHK include/linux/version.h CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/conmakehash CC init/main.o CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o CC init/do_mounts.o CC init/do_mounts_rd.o CC init/do_mounts_initrd.o LD init/mounts.o /bin/sh: line 1: x86_64-linux-ld: command not found make[2]: *** [init/mounts.o] Error 127 make[1]: *** [init] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.15' make: *** [debian/stamp-build-kernel] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone willing to seed sarge amd64 isos?
Am following the discussion of jigdo with interest -- but in the meantime, no need to cc: me directly on all the posts; I'm subscribed to the list. Thanks! -c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I know if...
David L. Johnson [EMAIL PROTECTED] writes: On Sun, 8 Jan 2006 01:18:12 +0100 Aritz Beraza Garayalde [Rei] [EMAIL PROTECTED] wrote: 2006/1/7, Robert Cates [EMAIL PROTECTED]: Hi, I have not yet successfully installed an AMD64 port (tried several times, but keep getting a kernel panic for some reason), but when I do, Maybe you have sata devices. You can have a punch of solutions to many problems that appear during debian amd64 installation in the list archive. Yeah, I had that fun. But I did not get kernel panics, instead the installation could not find the drive at all. Unless the installation used a newer kernel than was installed, this shouldn't have been the problem. I'd like to know and be sure that I'm using 64-bit mode, and not 32-bit mode. How can I check this to make sure I'm running the AMD64 port installation in 64-bit mode? uname -a No, that will just tell you if you have a 64-bit kernel, but that kernel can be used for 32-bit installations as well. I think you might have to resort to something like 'file $SHELL' and look for '64-bit'. -- Carl Johnson[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First Kernel Build Attempt Failed - PROGRESS and new problem
Progress of sorts ... If I haven't mentioned it, I would like to say thanks to all for there comments, suggestions and support and special thanks Lennart and Andrew. After more reading and more attempts, I added to: /etc/kernel-img.conf: ramdisk = /usr/sbin/mkinitrd.yaird and I changed my make-kpkg params to: fakeroot make-kpkg --arch=amd64 --append-to-version=.20060107 kernel-image eg: I dropped the --initrd option as the kernel is monolithic with no modules and the kernel built and installed! reboot produces lots of messages the fly by to fast to read and ends up with: VFS: Cannot open root device sda1 or unknown-block (8,1) Please append a correct root= boot option. Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (8,1) sda1 is the root device on the old kernel, and I'm guessing that (8,1) is probably the 3ware controller. It is possible that I have not configured the correct drivers for the hardware. My working 2.6.8 kernel has: [EMAIL PROTECTED]:~$ lsmod Module Size Used by ipv6 280552 18 3w_9xxx36100 0 ext3 121616 5 jbd64176 1 ext3 mbcache11400 1 ext3 tsdev 9472 0 mousedev 12628 0 evdev 11648 0 psmouse20108 0 genrtc 11516 0 sd_mod 22400 7 usb_storage69184 0 e1000 83588 0 ide_cd 42784 0 cdrom 39848 1 ide_cd ide_disk 21504 0 ide_generic 2816 0 generic 6528 0 ide_core 154688 5 usb_storage,ide_cd,ide_disk,ide_generic,generic floppy 65104 0 fbcon 32164 70 vga16fb14464 1 vgastate 10240 1 vga16fb usbserial 33008 0 usbkbd 8960 0 ehci_hcd 32132 0 uhci_hcd 33056 0 thermal15116 0 processor 15224 1 thermal fan 5512 0 ata_piix9988 6 libata 42888 1 ata_piix scsi_mod 131072 4 3w_9xxx,sd_mod,usb_storage,libata unix 32032 26 font 10112 1 fbcon vesafb 7984 0 cfbcopyarea 5120 2 vga16fb,vesafb cfbimgblt 4352 2 vga16fb,vesafb cfbfillrect 5248 2 vga16fb,vesafb I have attached the config-workinprogress.txt file. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.15.20060107 # Sun Jan 8 02:05:29 2006 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # # CONFIG_MODULES is not set # # Block layer # # CONFIG_LBD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_MK8 is not set CONFIG_MPSC=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set # CONFIG_NUMA is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4
