Re: Install Report: Tyan Thunder K8S Pro / dual Opteron 250 / 2GB / SATA root
Next time, try mount / -o remount,rw. Don't forget to mount / -o remount,ro when you're done, for a clean shutdown. In fact, I tried it this time. By stuck in readonly I meant that even in single user mode it refused to remount root read-write. I still don't know why this happened. -David
Install Report: Tyan Thunder K8S Pro / dual Opteron 250 / 2GB / SATA root
Executive Summary: I didn't use the installer, rather I debootstrapped on a HDD and then put it in the new machine. Unlike any of my previous debian-amd64 installs, everything just worked. Thanks debian-amd64 developers for all of your hard work, as this port has come a long way! A Few Details: After rocky experiences installing debian-amd64 on Athlon64 boxen, I nevertheless decided to use it for my new computation server. This machine will be used for various long-running computationally-intensive mathematical tasks. The specs are: Tyan Thunder K8S Pro (s2882) with BIOS 2.03 Dual Opteron 250 2 GB Kingston ECC/Registered PC3200 DDR RAM Samsung SP1213C 120GB SATA HDD (By the way, the BIOS version may be important here. Tyan's web site says that Opteron 250 support was only recently added, but thankfully 2.03 has this feature.) I bootstrapped the installation rather than using a bootable CDROM; my procedure was: 1) Install HDD in working debian-amd64 box, partition and create filesystems. 2) cdebootstrap from alioth 3) chroot and apt-get miscellaneous utilities (scsi-tools, etc.) 4) compile kernel with hardware support as listed on debian-amd64 K8 mainboard compatibility list and safe options (e.g. no NUMA) 5) edit fstab and other config files to reflect predicted configuration of new machine 6) install GRUB 7) transplant HDD into dual Opteron machine and boot 8) apt-get more applications, recompile kernel with optimal settings (SMP, NUMA etc) The only hitch was that I left a /dev/sdb in fstab that needed to be /dev/sda, and as a result fsck failed on boot. The root filesystem seemed stuck in readonly mode, so my solution was to add the kernel parameter rw and skip fsck on boot. I was then able to edit fstab. The K8 mainboard compatibility list was very helpful and all of the onboard hardware was supported immediately when I compiled a kernel with the drivers listed there. Maybe, though, it would be good to add a list of XFree86 drivers for the onboard video where appropriate? The K8S Pro has builting ATI Rage/XL which works fine with the ati driver. Hardware monitoring with lm_sensors works well but really requires the custom sensors.conf available from http://www.tyan.com. So far, I can definitely recommend this board/CPU combination for use with debian-amd64. I will post an update if anything changes significantly. -David
Re: Bug#260747: removing --enable-final allows successful compilation of arts-1.3.0
I was referring to the rules for arts-1.3.0-1, specifically, lines 73-76: # run configure with build tree $(objdir) cd $(objdir) \ CC=gcc-3.3 CXX=g++-3.3 ../configure $(configkde) --enable-final \ --with-alsa However, as you point out, gcc/g++ 3.3 is used to build the package by default. I removed the CC and CXX settings and rebuilt with the default version on my system (3.4.1), and experienced the segfault in mcopidl. I then removed the suspicious --enable-final option and the package compiled successfully with 3.4.1. Thus in the end I replaced the rules quoted above with: # run configure with build tree $(objdir) cd $(objdir) \ ../configure $(configkde) \ --with-alsa -David On Sun, 15 Aug 2004 21:56:08 +0200, Matthias Klose [EMAIL PROTECTED] wrote: the version you cite is not made by the gcc-3.4 package in unstable nor do I see that --enable-final is passed at configure time. Matthias David Dumas writes: I experienced the segfault in mcopidl when compiling arts-1.3.0 with gcc 3.4.1 under debian unstable (amd64). I looked at debian/rules and found that --enable-final is passed to configure; this option has the following description in the configure usage message: --enable-final build size optimized apps (experimental - needs lots of memory) Why would the debian package optimize for size? Anyway, removing this option allowed a successful build, i.e. no segfault in mcopidl. -David $ gcc -v Reading specs from /usr/lib/gcc/x86_64-linux/3.4.1/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --disable-werror x86_64-linux Thread model: posix gcc version 3.4.1 (Debian 3.4.1-5.0.0.2.amd64)
unison 2.9.1 segfault on amd64
When I try to synchronize my laptop (running debian i386 unstable) with my desktop (running debian amd64 unstable) the unison process on the desktop segfaults just before starting to update files. Is anyone else experiencing this problem? (BTW I mentioned before that there isn't a segfault in debian amd64 that recompiling with gcc 3.4 doesn't fix. I must now retract that statement, though 3.4 is still the right way to go.)
Re: gcc-defaults: Please make gcc-3.4 the default on amd64
On Mon, 19 Jul 2004 23:00:34 +0200, Andreas Jochens [EMAIL PROTECTED] wrote: Please make gcc-3.4 the default on amd64. It has much better support for the amd64 architecture and also much better performance on amd64 than gcc-3.3. Yes, please do. I recently switched to the amd64 port full-time, and have not yet encountered a segfault that recompiling with gcc-3.4 didn't fix. Moreover, I think this relatively new port should standardize on a gcc with good K8 support while it is still young. -David
Re: amd64 sleeps too quickly
$ time ssh pergolesi.debian.org sleep 5; echo done done real0m2.957s The problem is not universal: $ uname -a Linux feynman 2.6.7.2004-07-11feynman-amd64 #3 Sun Jul 11 03:09:04 EDT 2004 x86_64 GNU/Linux $ time sleep 5 real0m5.001s user0m0.000s sys 0m0.002s $ dpkg -l coreutils Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii coreutils 5.0.91-2 The GNU core utilities
