Etch is REALLY fast! :-)
Hi all, I ran into problems with Gnome automounting CDs and USB flash drives over the weekend. I have been sticking with Sarge, and I had been using a backports kernel (2.6.15) that I custom compiled back in February, but when I bought a new video card recently I found that I had to compile a new kernel module to get 3D working properly. At that point, I decided that I might as well grab the latest kernel sources and upgrade the entire kernel (to 2.6.18). Unfortunately, 'hal' stopped working, and that broke 'gnome-volume- manager'. I saw that backports had an upgrade for 'udev', and I installed that hoping for a quick fix. The backports 'udev' conflicted with 'hal' and 'hotplug', and I found myself facing a big decision. Since Etch is nearly ready to be released, I decided that my best bet was to keep the new kernel and replace everything else! ;-) I chose to dist-upgrade to Etch. I've been using Etch now since Sunday night, and everything is working really smooth. Everything seems a lot faster, too. No doubt some of that is due to the improved video card, but boot time is faster and everything I do when working without X also seems faster. I would like to thank the developers who are busting their buns to get Etch ready for release! Can anyone suggest other Debian mailing lists I can post my thanks to, so that the greatest possible number of developers will see it? (I realize that "thanks" is just noise, and not productive, but everyone wants to hear that their hard work is appreciated!) Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch is REALLY fast! :-)
andy wrote: Dave Witbrodt wrote: Hi all, I ran into problems with Gnome automounting CDs and USB flash drives over the weekend. I have been sticking with Sarge, and I had been using a backports kernel (2.6.15) that I custom compiled back in February, but when I bought a new video card recently I found that I had to compile a new kernel module to get 3D working properly. At that point, I decided that I might as well grab the latest kernel sources and upgrade the entire kernel (to 2.6.18). Unfortunately, 'hal' stopped working, and that broke 'gnome-volume- manager'. I saw that backports had an upgrade for 'udev', and I installed that hoping for a quick fix. The backports 'udev' conflicted with 'hal' and 'hotplug', and I found myself facing a big decision. Since Etch is nearly ready to be released, I decided that my best bet was to keep the new kernel and replace everything else! ;-) I chose to dist-upgrade to Etch. I've been using Etch now since Sunday night, and everything is working really smooth. Everything seems a lot faster, too. No doubt some of that is due to the improved video card, but boot time is faster and everything I do when working without X also seems faster. I would like to thank the developers who are busting their buns to get Etch ready for release! Can anyone suggest other Debian mailing lists I can post my thanks to, so that the greatest possible number of developers will see it? (I realize that "thanks" is just noise, and not productive, but everyone wants to hear that their hard work is appreciated!) Dave W. Dave As a matter of interest, can you describe what happened when you say that you ran into problems with Gnome's automounting CDs and flash drives. Did your system freeze up, or was it some other problem? Cheers Andy No crashes, slow-downs, or other Windows-like behavior. I simply realized that inserting a CD or a USB flash drive no longer resulted in Gnome giving me a desktop icon. As mentioned above (see 2nd paragraph in OP) the root cause was 'hal' failing to run, which broke 'gnome-volume-manager' (and 'gnome- volume-properties'). I had been running stock Debian kernels (2.6.8) until Feb. 2006, when I made my first custom kernel (2.6.15; source from backports.org). Sarge continued to run good with that kernel, but I decided to compile a new kernel (2.6.18) this month, on the occasion of having to compile 3D support for a new ATI video card. That kernel broke 'hal' apparently, but I didn't realize it until I noticed that Gnome automounting wasn't working. My first stop on the debugging pilgrimage was '.xsessions-errors', where I found a one-liner about 'gnome-volume-manager' failing to load because 'hal' wasn't running. My next stop was 'dmesg', where I confirmed that 'hal' was failing to run at startup. I then realized that my new kernel had broken things, but immediately concluded that it was my own fault for straying too far from the officially supported set of internal organs for Sarge. I believe that I made a quick look for backports of 'hal' and/or 'hotplug' and didn't see any. (Or maybe that is a false memory, and I made no such check.) However that may be, I _did_ find a backport of 'udev', and wondered (or desperately hoped) that it might make a quick fix of the situation. Instead, the 'udev' from backports somehow conflicted (according to 'aptitude') with 'hal' and 'hotplug'. (I found this bizarre, since a quick look at http://packages.debian.org/testing/admin/hal showed that Etch's 'hal' still depends on 'udev', not conflicting at all!) So, I dist-upgraded to Etch... and lived happily ever after! (So far.) DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch is REALLY fast! :-)
Gustavo Franco wrote: (...) Since Etch is nearly ready to be released, I decided that my best bet was to keep the new kernel and replace everything else! ;-) I chose to dist-upgrade to Etch. I've been using Etch now since Sunday night, and everything is working really smooth. Everything seems a lot faster, too. No doubt some of that is due to the improved video card, but boot time is faster and everything I do when working without X also seems faster. Hi Dave, You feedback is really appreciated. Btw, if you want to install the same set of packages as the default (GNOME) desktop environment, i recommend you: aptitude update && aptitude install desktop gnome-desktop (there are xfce-desktop and kde-desktop too). Keep in mind that desktop and gnome-desktop aren't metapackages but tasks (as in tasksel). In other words, d-i uses tasksel to install set of packages and not metapackages or a 'hardcoded into d-i' list of packages. Well, it's much too late for me to be able to follow this advice. In fact, I carried out my upgrade to Etch in a bizarre sort of way: 1. The 'apt' tools were so easy to use when I first started learning about Debian that I just installed tons of packages that I either only looked at once or never used at all. 2. Selecting "desktop system" when I first installed caused both Gnome and KDE to get installed, but I ended up preferring Gnome and wanted to remove as much of K as possible. 3. I read the _Debian GNU/Linux 3.1 Bible_ and a lot of Martin Krafft's _The Debian System_ during 2006, as part of my long-term project to learn how Linux (Debian in particular) works under the hood, ramping up to develop my own software (or maybe become a DD in the future). This combination of factors led me to modify 'sources.list' and 'apt.conf' to point to Etch, then run 'aptitude' -- with which I was able to pick over my entire Debian system one package at a time, watching the effects of upgrading one important package, removing unwanted cruft, seeing the list of "broken" packages jump to nearly 100, then counting down to zero as I continued to mark stuff for upgrades (or purges). It took hours and hours... I was reading masses of documentation as I discovered new and interesting things about what really goes on inside a Debian OS. In the end, I realized that the process that took me about 9 hours could have been carried out automatically by aptitude update aptitude dist-upgrade in about 40 minutes -- for it took only 25 minutes to download 663MB of packages and 15 minutes for the debconf questions and setups -- but I would not have learned nearly as much, and would have not felt nearly as satisfied! ;-) I thought it was particularly hilarious that I had to recompile my entire kernel, whereas my original decision to upgrade to Etch was intended to allow me to preserve it. Sarge runs XFree86, but my new video card required a new driver blob and kernel module. The Etch upgrade, of course, installed XOrg and the module I had compiled for Sarge was targetting XFree86. I thought I could just compile a new kernel module, but then realized that I had just installed a new version of 'gcc'. I got "gcc version 4.1.2 ..." when I ran 'gcc -v', but I had compiled my kernel with gcc 3.3.5. So, I had a fresh '.config' file to use, and just recompiled the whole kernel along with the ATI module -- it only took about 15 minutes. Later, I realized that there is also a 'gcc-3.3' package on my system, and probably could have just compiled the ATI module alone after all. (Sometimes ya gotta learn the hard way!) I've a question on behalf of the Debian Ombudsman Team: - Is there any current issue you would like to see solved into our post-etch release (Lenny) ? Well, I have been pretty busy since upgrading on Sunday. I'm more familiar with peeves I had with Sarge, such as: - 'fam' often refusing to let me unmount my USB drives until I ran '/etc/init.d/fam restart'. - 'gdm' going postal if I tried to log in more than once -- solved by adding "AlwaysRestartServer=true" in 'gdm.conf'. (I guessed this had to do with the proprietary ATI driver, though.) - the font called "Cursor" causing much of Gnome to go apopleptic if you tried to use it. I haven't had time to put Etch through the ringer since upgraded on Sunday. Your question seems sort of open-ended. Did you mean to narrow the range of "issues" at all, or are you inviting comments, criticisms, and gripes in the broadest possible sense? BTW, the constructive criticism from Wim de Smet is a good one. I noticed that myself, about 'info' giving manpages instead, but I either assumed I was doing something wrong or that the documentation was out of date. Reading the bug page for #139569 makes, unfortunately, for hilarious reading. It's like a cat chasing its own tail... imagine the Debian swirl! Dave W. -- To UNSUBSCRIBE, email to [EMAIL P
Re: Etch is REALLY fast! :-)
Liam O'Toole wrote: On Wed, 31 Jan 2007 23:10:25 -0500 Dave Witbrodt <[EMAIL PROTECTED]> wrote: [...] I thought it was particularly hilarious that I had to recompile my entire kernel, whereas my original decision to upgrade to Etch was intended to allow me to preserve it. Sarge runs XFree86, but my new video card required a new driver blob and kernel module. The Etch upgrade, of course, installed XOrg and the module I had compiled for Sarge was targetting XFree86. I thought I could just compile a new kernel module, but then realized that I had just installed a new version of 'gcc'. I got "gcc version 4.1.2 ..." when I ran 'gcc -v', but I had compiled my kernel with gcc 3.3.5. So, I had a fresh '.config' file to use, and just recompiled the whole kernel along with the ATI module -- it only took about 15 minutes. Later, I realized that there is also a 'gcc-3.3' package on my system, and probably could have just compiled the ATI module alone after all. (Sometimes ya gotta learn the hard way!) [...] I'm sure that was a valuable learning experience, but there is an easier way of installing the ATI drivers. See the packages fglrx-driver and fglrx-kernel-src, both in the non-free section. The latter can be auto-installed using module-assistant. Thanks for the tip. As it turns out I already knew about this. It's just that AMD/ATI just released a brand new driver package this month, and I wanted that: [EMAIL PROTECTED]:~$ apt-cache policy fglrx-kernel-src fglrx-kernel-src: Installed: 8.33.6-1 Candidate: 8.33.6-1 Version table: *** 8.33.6-1 0 100 /var/lib/dpkg/status 8.28.8-4 0 400 http://debian.uchicago.edu etch/non-free Packages Installed is the new proprietary package, 8.33 ; the Etch archive contains 8.28. (It's very likely that I wouldn't have noticed any difference, though, unless my card was not supported by 8.28 or something. It was NOT supported yet in 8.23.) Thanks again, DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Etch is REALLY fast! :-)
Colin wrote: Dave Witbrodt wrote: Thanks for the tip. As it turns out I already knew about this. It's just that AMD/ATI just released a brand new driver package this month, and I wanted that: [EMAIL PROTECTED]:~$ apt-cache policy fglrx-kernel-src fglrx-kernel-src: Installed: 8.33.6-1 Candidate: 8.33.6-1 Version table: *** 8.33.6-1 0 100 /var/lib/dpkg/status 8.28.8-4 0 400 http://debian.uchicago.edu etch/non-free Packages This is also what I'm waiting for. I see that sid currently has 8.31 which doesn't do my Radeon X1600 Pro any good. 8.33 is the first version to fix the xvideo problem so I can use tvtime with x.org. You may have misunderstood. When I said I wanted 8.33, I meant that I installed ATI's proprietary driver by compiling it myself, instead of using the Debian 8.28 package. I didn't mean that I'm still _waiting_! I found it terribly easy to install, though I've done it before so maybe I'm just getting used to it. I can tell you the steps I used, if you're interested DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: off to try my hand at "hurd"ing
Andrew Sackville-West wrote: here i go, installing the hurd. I'll report back. If you don't hear from me by the spring, I'm either dead or found paradise. Either way send whiskey and reinforcements. What hardware are you installing on? (Just curious.) Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian & ATI Radeon X300 don't mix?
Now that my NIC is working, it's time that I bring up the next issue with my new PC: the ATI video card.When I bought this PC, I had SuSE on my mind (which is what I used to use on my old PC and my laptop), but I started to like using Debian from work. With that said, I did not have compatiblity issues in my head while I was picking out components for my PC so I chose the Radeon (I didn't need 512MB of the best 3D acceleration tha t money could buy; I just needed something cheap, but decent), because I know for a fact that fglrx drivers can be found for RH and SuSE on the ATI website and installed easily. Sadly, that is not the case with Debian (even now, I'm just using the VESA driver at 800x600 res.). After some googling, I found the following website with detailed instructions: _http://www.stanchina.net/~flavio/debian/fglrx-installer.html_ I followed the steps and everything went smoothly without any sort of errors. When I rebooted, my login screen was in the 1024x768 resoultion that I wanted. *hooray!* But would hang/freeze while loading GNOME :( To be honest, I don’t' really care whether the ATI card gets interfaced properly, I just want 1024x768 resolution since I use it only for work (mostly coding) and not play. Does anybody have any suggestions on how I can achieve that? I actually had problems using 'vesa' with my X300 card the first time I installed Debian on that machine. Switched to text consoles resulted in corrupted screens, though I could clean it up using 'clear'. Therefore, I needed the proprietary ATI drivers just for peace of mind. I was compiling my own kernels (for an old P3 and the new P4 with the X300) for the first time, so I decided to investigate what was necessary to get the ATI drivers working. I found that compiling in any kernel modules with 'RADEON' or 'DRM' would block my ATI drivers from working. (I was compiling all needed features into the kernel, no modules at all to avoid needing an initrd.) If you are using a stock kernel, you may have to blacklist a module or two. I've been very happy with the ATI drivers since I got them to work after a false start or two. Hope you get it to work on your box! Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Support For ATI Sapphire Radeon Graphics Card
Redefined Horizons wrote: However, he is having some problem with his graphics card. He is using the ATI Sapphire Radeon 1650. Does anyone now if it is still necessary to go through these steps to install support for the video card? http://www.debianhelp.org/node/4447 I have used 2 different X1650Pro cards since December with Etch. That may not be exactly the same as X1650, but my bet is that your friend's will work fine with the proprietary drivers. The instructions on the link you provided aren't quite the steps I follow, but if they worked for someone else they will probably work for you. (There is more than one way to get the same result here.) I should point out that any changes to your kernel will require uninstalling and reinstalling the ATI driver. That may annoy your friend a lot, compared with how things work with Windows. Updating to new (proprietary) drivers involves the same process. If the Debian fglrx packages support this card (last time I checked they did NOT, but you should check again) that would make your life a whole lot easier -- updating the driver, for whatever reason, would be so much easier. The main problem with that approach is the lag between current ATI drivers and the Debian packages. The ATI proprietary drivers since January have performed much better than previous ones. HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with login/logout freezes (solved myself)
FYI, I run Debian Sarge on a P4 Dell Dimension 8400 workstation. I use a self-compiled kernel and the proprietary ATI driver for my X300SE video card. I also have an older machine (HP Pavilion 8766C) with proprietary NVidia drivers for the onboard Vanta dinosaur. On my older machine I had set up 2 user accounts, one for everyday usage and another for more serious work which I want to protect from loss in case of internet security problems. This worked well, though creating the new account revealed a few problems with Debian I wouldn't have known about otherwise: using the "Cursor" font in Sarge causes 'nautilus' to crash; and the 'esd' sound daemon randomly fails to shut down when logging out, preventing the next user from being able to use sound. (The fixes are: don't use the "Cursor" font with Sarge, and kill the 'esd' process and login again.) On my new machine today, I was setting up that second account and copying files via NFS so that I can reconfigure the old machine for other uses. I discovered that switching between user accounts would cause Debian freeze during a logout -- the machine was unresponsive to the keyboard except for a Ctl-Alt-Delete shutdown. (Several times even that failed, forcing me to use the dreaded power button, resulting in an 'fsck' cycle on reboot.) Googling for clues, I found references to a 'gdm' configuration option that forces the X server to shutdown and restart at a user logout, instead of reusing the same X server instance. That has cured my problem: I can now do as many logout/login cycles as I want without problems. I don't know what part of the system is failing -- my guess is that it is a problem with the proprietary video driver -- but because I'm using a tainted kernel there is no point in reporting this as a bug using the BTS. If anyone out there ever has the same problem edit this file: /etc/gdm/gdm.conf and look for a setting called "AlwaysRestartServer" and set it to "true". It helped in my case, but YMMV. If you're having a similar problem it's worth a try, though. HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Log out problem?
Jonathan Roberts wrote: Hey thanks, I've solved it now actually... Somebody else posted a similar problem and said they'd worked around it by setting AlwaysRestartServer to true in /etc/gdm/gdm.conf This fixed it! Thanks for the reply tho - hopefully this fix might help someone else too? I was the one who posted the "AlwaysRestartServer" suggestion last night, after trying to trace my own problem. I really was posting it for the 'debian-user' archives, for future Googlers. I didn't realize there was a current thread with folks trying to deal with the same issue. Glad you saw it... glad it helped! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ia32-apt-get on Sid
Goswin von Brederlow wrote:
Dave Witbrodt writes:
I use Sid, and have been interested in the appearance of the new
ia32-apt-get facility.
I see that ia32-apt-get has its own configuration files in
/etc/ia32-apt
After reading /usr/share/doc/ia32-apt-get/README.Debian, I'm a bit
confused on how this new system works
Sorry, I forgot to update README.Debian when I uploaded version
22. The NEWS file is right about dropping the diversions.
OK, that helps clear up some confusion.
2) When the new packages were first installed, my understanding was
that commands like 'aptitude' and 'apt-get' had been diverted, and
running them would actually run the corresponding 'ia32-apt*' wrapper
instead. Reading NEWS.Debian.gz in /usr/share/doc/ia32-apt-get now
seems to indicate that the diversion scheme has been dropped.
That raises many questions:
Should users be using 'aptitude', or 'ia32-aptitude', or both?
The later.
OK, from now on I will stick with the 'ia32-*' scripts.
They are wrapper scripts, right? It seems like the dependencies force
'aptitude' to be installed, but not 'apt' though.
Should repository servers be listed in
/etc/apt/sources.list
and /etc/apt/sources.list.d/*.list
or should they be in
/etc/ia32-apt/sources.list
and /etc/ia32-apt/sources.list.d/*.list?
The later.
OK, that's very helpful. The README.Debian file really needs to make
that clear.
3) Do the 'ia32-apt*' wrappers keep their own database file for
installed packages, or do they share the same database with the
primary APT system. For example, I have noticed that 'aptitude' still
correctly shows my automatic dependencies, but running 'ia32-aptitude'
indicates that none of my installed packages are marked as automatic
dependencies.
The database for installed packages is kept by dpkg in
/var/lib/dpkg/status. That remains common for everything. But the
database of available packages is in /var/cache/ia32-apt/ and the
sources files are in /var/lib/ia32-apt/lists and will only bee used by
ia32-*.
I don't use aptitude myself but it looks to me like
/var/lib/apt/extended_states contains informations about automatically
installed packages. With the wrappers
/var/lib/ia32-apt/extended_states is used instead. Does it help to
copy /var/lib/apt/extended_states to /var/lib/ia32-apt/extended_states?
Yes. I copied both files,
/var/lib/{ia32-,}apt/extended_states
to a safe place, then overwrote the version in '/var/lib/ia32-apt' with
the version from '/var/lib/apt'. You should consider providing a
debconf question allowing the admin to copy this file (if desired) the
first time installing the 'ia32-apt-get' package. Even if policy
forbids this, you should mention the issue in README.Debian.
Thank you for the reply. It was very helpful, and I now feel a lot
better about using 'ia32-aptitude' exclusively.
I'm still somewhat confused about the selection of packages available
using 'ia32-apt*'. For example, I don't have 'wine' installed, but I
see that there are packages called 'wine*' and 'ia32-wine*'. Is this
merely because 'wine' is available in both 'amd64' and 'i386' versions
in the repositories, and both packages are made available using the
'ia32-apt*' system? Is this the sort of thing meant to be solved by the
new system -- since the 'i386' and 'amd64' packages are essentially the
same thing?
Thanks again,
Dave W.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
apt.conf and ia32-apt-get
Does the new 'ia32-apt-get' system honor anything in /etc/apt after initially being installed, such as 'apt.conf'? Or should 'apt.conf' be copied to '/etc/ia32-apt'? Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Anyone know what happened to kernel-archive.buildserver.net?
Anyone know what happened to kernel-archive.buildserver.net? Seems like it has been down for about 2 weeks now. Curious, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Kernel 31
Mark Allums wrote: Anyone with experience with 2.6.31 yet? Anything we need to know? What's the consensus? I compiled my own 2.6.31-rc6 on Aug. 18. Out of over a dozen boots, I experienced: - a couple of hangs during boot - some hangs logging out and logging in as a different user (in X, not virtual terminals) - a stack trace during shutdown (at least once) - some (apparently) harmless errors during boot. Between then and now http://kernel-archive.buildserver.net has gone away, but I did download the mainline git tree from kernel.org and built the 2.6.31 when it was released. I've been running it since Sep. 9, and have experienced: - no hangs - no errors or warnings during boot - no stack traces during shutdown In short, it looks very good. I am using a very carefully customized .config file, however, and no experimental/unstable features such as KMS (kernel mode setting). I hope to pick up a new ATI card in the next month or two, and will probably experiment with KMS then. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Kernel 31
KMS works very fine here (recent Intel graphics) since I learned that you have to disable the framebuffer in the kernel config. :) That's a really great feature. Switching from X to a VT is almost as fast as switching workspaces. Cool! I look forward to playing with it. My understanding is that you need development versions of some of the X system software to use the radeon KMS driver with X. I have quite of few things to which I have to give priority right now, but should have some time to look into these things around the time I buy that new card. ;) DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Exim4 configuration file (non split) on Debian
Peter F Bradshaw wrote: Hi; Anybody know which configuration file Exim4 uses when it is configured for "non split" configuration on Debian? /etc/exim4/exim4.conf.template Many people can get away with just tweaking the debconf settings with dpkg-reconfigure exim4 Those settings are in /etc/exim4/update-exim4.conf.conf DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian vs. ATI Radeon x1650
Ken Heard wrote: I want a new display adapter/video card with two DVI ports to use for a two screen setup to replace the adapter/card built in to my Foxconn mainboard which has only one VGA port. I found a place in Toronto where I can buy a Radeon X1650 XT for CA$40.00. I checked the URLs in thveillon.debian's post, with the following results described inline in those parts of the post quoted below (thanks Tom): [...] So, based on the foregoing, should I take the plunge and buy it in the hope that I can get it to work? If it does not then I am out the CA$40.00, because I will not be able to return it. I'm using an old Radeon X1650 Pro to temporarily replace my GeForce 7950GT which died over the summer. I have been using it with the 'radeonhd' driver for about 2 months. The NVidia proprietary driver would not recognize my 1920x1200 monitor's preferred resolution, but 'radeonhd' always has. My understanding is that the other free software driver, 'radeon', is now more in better shape and even has initial support for kernel mode setting (if you have a new enough kernel, with the proper settings enabled). I have a new Radeon coming in the mail, and will be playing with 'radeon' and KMS quite soon! :) HTH, Dave W. PS: I don't think I would buy a card that I could not return. What if the thing is DOA? What if the fan screams like a subway train? I think you should keep your options open when it comes to returns. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Courier Font package
Wayne Topa wrote: I hope to install Courier font in my lenny but I did not find the proper package. Whant package should I install ? Thanks in advance. You should learn how to use the Debian tools. 1. Install the apt-cache package. 2. Read the apt-cache man file ie man apt-cache. There is no package in Debian called 'apt-cache'. There is a program called 'apt-cache', provided in the package called 'apt'. The 'apt' package is categorized as Essential, so anyone who installs Debian is pretty much guaranteed to have it installed. On my system, I seem to have Courier fonts... but I cannot say which font package I have installed which provides those fonts: $ fc-list |grep -i courier Courier New:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali, Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,thường,Arrunta Courier 10 Pitch:style=Bold Italic Courier New:style=Bold Italic,Negreta cursiva,tučné kurzíva,fed kursiv,Fett Kursiv,Έντονα Πλάγια,Negrita Cursiva,Lihavoitu Kursivoi,Gras Italique,Félkövér dőlt,Grassetto Corsivo,Vet Cursief,Halvfet Kursiv,Pogrubiona kursywa,Negrito Itálico,Полужирный Курсив,Tučná kurzíva,Fet Kursiv,Kalın İtalik,Krepko poševno,Lodi etzana Courier 10 Pitch:style=Italic Courier New:style=Italic,Cursiva,kurzíva,kursiv,Πλάγια,Kursivoitu,Italique, Dőlt,Corsivo,Cursief,Kursywa,Itálico,Курсив,İtalik,Poševno,nghiêng,Etzana Courier 10 Pitch:style=Regular Courier New:style=Bold,Negreta,tučné,fed,Fett,Έντονα,Negrita,Lihavoitu,Gras, Félkövér,Grassetto,Vet,Halvfet,Pogrubiony,Negrito,Полужирный,Fet,Kalın,Krepko,đậm,Lodia Courier 10 Pitch:style=Bold No doubt others on this list who are more familiar with fonts (and their respective packages) can name the packages. All that I can say is that Courier fonts are available (somehow) via the Debian repositories. Possibly I have them because of the package called 'ttf-mscorefonts- installer'. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Console font size change on xorg exit
Chris Jones wrote: .. oh bugger.. I meant the framebuffer lists, naturally. To which "framebuffer lists" do you refer? I have some framebuffer issues of my own that I would like to discuss with knowledgeable people, but I don't know where to look or subscribe. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Console font size change on xorg exit
Chris Jones wrote: On Tue, Mar 17, 2009 at 07:49:10PM EDT, Dave Witbrodt wrote: To which "framebuffer lists" do you refer? I have some framebuffer issues of my own that I would like to discuss with knowledgeable people, but I don't know where to look or subscribe. You can subscribe - or browse the archives at: https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users The fbdev-users list is probably what you want unless you are submitting bug reports or patches. Good info. Thanks! DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Latest Power Management tool for AMD64
T o n g a écrit : My CPU is AMD 64. What's the latest and easiest power management tool for AMD64? powernowd is less complicated than cpufreqd or cpudyn, but I also heard sayings that the 2.6 kernel ondemand cpufreq governor might be even more simpler, and there are many other tools like acpid, powersaved, powertop, etc, etc. I personally use 'powernowd' with my Athlon 64 X2 desktop CPU, but it is true that the kernel's ondemand governor is "simpler" in the sense that it can be used without having to install (and configure) other software. If you choose to use software to control CPU frequency, it probably will have to be configured just once, and thereafter will be as "simple" to use as the kernel governors. CPU power management has always been a problem to me, I never get it worked before for my desktop PC. Any hint or points to detailed explanations/steps is appreciated. It can be true -- in the case of 'powernowd', for example -- that there are some hurdles to get by before the CPU frequency control software will work. On Ubuntu, just installing 'powernowd' doesn't actually enable it; only editing /etc/default/powernowd gets it working. I use Debian, so installing it enables it... except Debian kernels have as many kernel features as possible compiled into loadable modules, so I had to add a couple of lines to /etc/modules to make the appropriate kernel modules available at boot: cpufreq_userspace powernow-k8 Debian-based distributions provide for tweaking of 'powernowd' settings in /etc/default/powernowd. (See 'man powernowd' for details.) For the kernel governors, some good explanations can be found in the kernel documentation. You can install and unpack the package 'linux-source-' on your system, or it is not too difficult to find the same reading material on the internet. If you look in linux-source-/Documentation/cpu-freq For example, the file "governors.txt" has a description of how the various kernel governors (such as "ondemand") function, and how you can control them. thveillon.debian wrote: I use cpufreq ondemand compiled inside the kernel, no userspace daemon, only libcpufreq and cpufrequtils to interact with the kernel. On an amd64 x2 the results are very good since the cpu supports more speed steps, on the other hand there is not much to gain on my intel core2duo since it only have a few steps, the lower being 2Ghz for a 2.66Ghz cpu. Yes, your description of the difference between AMD and Intel CPUs reminds me of something I read in the package description of 'powernowd': $ apt-cache show powernowd [...] The name is somewhat misleading, as any CPUfreq capable processor will work, not just those from AMD. However, it works better on CPUs that support more than two speed steps, like those with AMD's PowerNow! or Intel's Pentium M series. . This daemon is less complicated than cpufreqd or cpudyn, at the cost of absolutely depending on a 2.6 kernel with the userspace governor and sysfs support enabled. In my (limited) experience ondemand is the only governor worse using, other aren't doing much or they simply slow things down by always reducing the cpu frequency. Well, this is Linux, so you can usually expect to find more options for customizing than you care to read about! ;) In the case of 'powernowd', for example, it is possible to control things like: - polling time (how often frequency adjustments are made) - upper and lower CPU usage thresholds (which control the decision about whether to step CPU frequency up or down) - step size (how much frequency is altered when stepped up or down... though this is very much constrained by hardware limitations) - mode (basic behavior of the CPU governor) The 'powernowd' software defaults to "aggressive" mode, which jumps the CPU frequency to maximum when the upper threshold on CPU usage is reached. This is what I use, and I set both the lower and upper boundaries quite low in order to kick the CPU into high gear easily, and keep it there as long as anything is going on. In spite of these tweaks my CPU typically stays at it's minimum frequency, which is not a problem since most daily tasks simply don't require maximum horsepower. The moment I start doing anything that even resembles demanding behavior, the system immediately jumps to maximum frequency, just the way I like it! My kernels have been home-rolled for a long time, I don't now the default cpufreq governor in Debian kernels, I would guess "userspace" as for most distributions. A stock Debian kernel is configured this way: $ grep FREQ /boot/config-2.6.28-1-amd64 CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ
Re: Latest Power Management tool for AMD64
T o n g wrote: The default kernel governor is ONDEMAND, so Tong has probably been using CPU frequency controls all along without knowing it. :) Not after I've installed a bunch of packages that google implies necessary, because I'm using a minimum set of packages. What are the minimum set of packages to enable kernel space cpufreq ondemand governor? To quote my own previous message: I personally use 'powernowd' with my Athlon 64 X2 desktop CPU, but it is true that the kernel's ondemand governor is "simpler" in the sense that it can be used without having to install (and configure) other software. The ONDEMAND governor is a Linux kernel feature. No userspace software is required at all! These kernel features are available in any kernel compiled with the relevant options. The latest Sid kernel (2.6.28-1) builds PERFORMANCE and ONDEMAND into the kernel (i.e., they are always present, and cannot be unloaded even when not being used) and makes the other governors available as modules: CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m The default in this Sid kernel is to set ONDEMAND as the governor running when the kernel boots: # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set You can look at the settings for your running kernel by opening a terminal and running grep FREQ /boot/config-$(uname -r) Other software you have installed, if it touches the CPU frequency kernel support, can interfere with which governor is currently being used on your system. In the case of 'powernowd', for example, it is possible to control things like: - polling time (how often frequency adjustments are made) - upper and lower CPU usage thresholds (which control the decision about whether to step CPU frequency up or down) - step size (how much frequency is altered when stepped up or down... though this is very much constrained by hardware limitations) - mode (basic behavior of the CPU governor) What's your current frequency limits, and step sizes? This is a matter of personal preference, so you should experiment with your own system until you like its behavior. I suggest sticking with the defaults, unless something about those settings annoys you. I _did_ find myself annoyed, so I experimented and settled on these settings: $ cat /etc/default/powernowd #default file for powernowd, see man 1 powernowd # # Options OPTIONS="-v -u 40 -l 5 -m 1 -s 20 -p 500" These options give me: verbose output during boot (-v); upper usage threshold of 40% (-u 40); lower threshhold of 5% (-l 5); behavior model set to aggressive (-m 1) [unnecessary to list, since it is the default, but I specify it anyway as a reminder to self]; frequency step of 200,000 Hz (-s 20); and polling time of 1/2 second (-p 500). The behavior I get from these settings is: - jump to max frequency if CPU usage hits 5% - do not decrease frequency unless usage drops below 40% - when dropping frequency, drop in 0.2 GHz decrements My Athlon 64 X2 has a maximum frequency of 3.2 GHz, and a minimum of 1.0 GHz. For simple daily tasks, the frequency stays at 1.0 GHz, even with the hair-trigger settings I use. Any hint of taxing the CPU resources causes the afterburners to kick in (my desired setting), and they mostly stay in use until they are really not needed at all. After learning to compile my own kernels, and exhaustively researching which settings were truly needed and disabling everything not needed for my system, I found that these settings allow me to compile the kernel and package the DEBs in 6 minutes. My CPU frequency stays pegged at 3.2 GHz for most of that time, and quickly drops back to 1.0 GHz once the DEBs are produced. :-) Having enabled my kernel ondemand cpufreq governor, this is what I get: $ cpufreq-info | grep frequency CPUs which need to switch frequency at the same time: 0 1 available frequency steps: 2.30 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz current policy: frequency should be within 1000 MHz and 2.30 GHz. current CPU frequency is 1000 MHz (asserted by call to hardware). Can I further lower the 1000 MHz boundary any way? That is determined entirely by the hardware, not by the software. it was mentioned earlier in this thread that Intel CPUs (so far) are much less flexible than AMD CPUs in this regard. The 'powernowd' software defaults to "aggressive" mode, which jumps the CPU frequency to maximum when the upper threshold on CPU usage is reached. This is what I use, and I set both the lower and upper boundaries quite low in
Re: System monitoring tool for AMD64
T o n g wrote: What are the recommended system monitoring tool for AMD64? I tried xmbmon, but it doesn't seems to show me the mb/cpu temperature, fan speed etc. I then tried xsensors, but get % xsensors Sensor 'k8temp' not supported by xsensors! This is also a matter of personal preference. I actually prefer the XFCE desktop environment, and I have been using a little plugin that sits on my desktop panels called 'xfce4-sensors-plugin'. Unfortunately, the latest version of that plugin in Sid is crashing for me, so I am trying to learn enough about 'gdb' to be useful in helping the Debian XFCE Maintainers to locate the problem and get it fixed. The previous version was working for me, however, and I saved its DEB so that I can still use it if I get desperate. ;) DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: repotbug not loading ui
Amit Uttamchandani wrote: I have used reportbug successfully a few times with the urwid interface without any problems. However, recently I can't get reportbug to load urwid or even gtk2 ui settings. Tried to look at the bug reports posted on debian but no luck. Even tried reconfiguring and using debug mode but can't figure it out. Any ideas? This is reportbug 4.1 with debian squeeze all packages up to date as of this email. I have also never been able to try out the new gtk2 interface. When I try to get the GUI interface from a menu, nothing happens -- not even an error message in a log file. When I try from an X terminal, I get the text interface instead of the GUI interface. I believe this is a known bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524857 I'm waiting for this bug to be closed, and the next release of 'reportbug' after than, before pursuing this problem further. I'm so used to using the text interface, anyway, that merely consider the situation annoying. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kernel-package??
Randy Patterson wrote: My intention at this point is to make a detailed list of the components on a particular system so I can remove everything that is not needed. These would be older systems that will never be upgraded or need new hardware so the kernel don't need a lot of options concerning hardware. For example, I have used ext3 on the drives and they don't need to access anything else and will remove all support for ext2, ext4, NTFS and everything else. I intend to compile everything into the kernel without using modules. It's my understanding from what I have read that this will result in a leaner and some what faster kernel for that system. Is that a reasonable assumption and approach? What is "reasonable" is a matter of opinion. Even though I carried out the massive research project you are describing above, and determined the exact set of configuration options needed to compile a custom kernel which exactly fits my hardware (and _only_ my hardware), I would not recommend anyone else to do so unless they had some specific need or purpose. My purpose has been to learn how Debian works "under the hood," with the intent of being able to contribute useful work later -- in the form of fixing bugs, writing and packaging my own software, and (possibly) becoming a Debian developer. Leaner? My own experience is that my kernel binaries are _larger_ than a Debian kitchen-sink kernel, while the disk space taken up for the initial ramdisk (initrd) and loadable modules in /lib/modules goes away almost entirely: # ls -lA /boot | cut -f5- -d' ' [...] 7653318 2009-04-20 07:43 initrd.img-2.6.28-1-amd64 [...] 2041664 2009-02-18 13:02 vmlinuz-2.6.28-1-amd64 2921024 2009-03-21 12:57 vmlinuz-2.6.28-2s13145.090321.desktop.uvesafb # du -s -b /lib/modules/* 210911107 /lib/modules/2.6.28-1-amd64 15089013/lib/modules/2.6.28-2s13145.090321.desktop.uvesafb The 15 MB of modules in my current custom kernel's /lib/modules path are mostly unnecessary, and could easily be reduced below 2 MB (maybe even 1 MB). Faster? I promise that you would not notice the speedup. Conceivably your kernel will boot slightly faster without having to carry out the hardware detection for the 99% of modules that have no relevance for your particular system, but you would have great difficulty measuring the alleged time savings accurately. (There are great opportunities for decreasing the time needed to boot a Debian system, but these have to do with customizing the initialization scripts, not with replacing the kitchen-sink kernel with a custom kernel.) As far as being in a hurry to leave out unnecessary things like ext2, ext4, and NTFS... I would ask you to reconsider. What happens if you meet other Linux users in your area, and they want to give you some files off of their USB flash drive formatted in ext2 or ext4? Or what happens if some Windows user you meet has some files on their external hard drive... formatted in NTFS? Now your really great idea about compiling your own kernel is really going to make you look smart to those folks, right? Your choices at that point will be to recompile your custom kernel, or boot to a Debian kitchen-sink kernel. (Which just raises the question of why you weren't using the Debian kernel in the first place.) I'm not trying to discourage you from building your own kernel. I'm trying to offer information that I think you should consider, and I'm offering the advice that you shouldn't bother building your own kernel unless you have some really good reason. (Really good reasons might include a burning desire to simply know how, or to be able to say you did it, but if one of those is you only reason then I think you will regret it by about halfway through the process.) The Debian kernel team works really hard to make sure that the kernels work, and they do a good job. In the end, I was able to customize my kernel configuration to the point that I can compile a kernel in about 6 minutes on my desktop machine... which is (at least) 6 minutes longer than it would take me to install a Debian kernel. ;) If I hadn't had problems with ALSA support with this machine when I first put it together, I probably would not have bothered to learn to compile my own kernels. The amount of time in invested in learning how to do it now causes me to want to keep doing it, so I don't have the feeling that I wasted those dozens of hours -- and so I am condemned to the punishment of Sisyphus. The whole subject of initrds scripts is something I will need to study up on. But are you saying that if I don't use modules that I don't need to worry about needing these scripts? When you boot a kernel, then any feature required by your system to be able to boot will have to be available before your hard disks are mounted. There are two ways to accomplish this: 1. Build the features directly into the kernel binary, instead of building th
Re: kernel-package??
Randy Patterson wrote: So on a dedicated system that is used for nothing but running a processor intensive application 24/7, do you think there would be any real increase in performance from a custom kernel? My gut reaction is "no," but I do not claim to have data to back that up. If there is a measurable inefficiency introduced into system calls to a loaded module versus a built-in module, then you could arguably get some minimal throughput gain over a long time period given the situation you're describing. For actual data, you might try asking on the mailing list for the Debian Kernel Team, or even at the Linux Kernel Mailing List. Please read some FAQs first, because this may well be a question that has been asked-and-answered to death. Since you're admittedly using "older" systems anyway, we're talking about (at the very most) losing a tiny percentage of efficiency on machines that weren't going to be the major contributors of throughput in the first place. I'm thinking I would be a Bad and Evil person if I encouraged you to custom compile your own kernels for _only_ the purpose you are describing. (If there were some educational goal on your own part that you were pursuing, it would start to make more sense, IMHO.) DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Reportbug-maint] repotbug not loading ui
Sandro Tosi wrote: On Fri, May 1, 2009 at 12:07, Dave Witbrodt wrote: Amit Uttamchandani wrote: I have used reportbug successfully a few times with the urwid interface without any problems. However, recently I can't get reportbug to load urwid or even gtk2 ui settings. Tried to look at the bug reports posted on debian but no luck. Even tried reconfiguring and using debug mode but can't figure it out. Any ideas? This is reportbug 4.1 with debian squeeze all packages up to date as of this email. I have also never been able to try out the new gtk2 interface. When I try to get the GUI interface from a menu, nothing happens -- not even an error message in a log file. When I try from an X terminal, I get the text interface instead of the GUI interface. I believe this is a known bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524857 I'm waiting for this bug to be closed, and the next release of 'reportbug' after than, before pursuing this problem further. I'm so used to using the text interface, anyway, that merely consider the situation annoying. This is a known issue, already fixed in our git repo; the next upload will fix this too. I just upgraded from 'reportbug' 4.1 to 4.2. The gtk2 interface seems to work nicely -- at least it comes up now, and I can actually see it for the first time -- so I'll be able to give it a try the next time I have a bug to report. (I was going to try it out by commenting on this bug in the 'reportbug' package, but it was already closed. I found that the latest 'debianutils' had a 'tempfile' program which was crashing and preventing X from loading, but that also was already reported, fixed, and closed.) Thanks, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Anyone here using socket AM3 motherboard MSI 790FX-GD70 or Gigabyte GA-MA790FXT-UD5P?
If so, would you be so kind as to post your 'dmesg'? Thanks, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: shutdown in Xfce
No improvement. The Log Out button quits the X session. The Shut Down and Reboot buttons produce a complaint and then quit the X session. Does the reboot/shutdown gadget work properly for everyone else using Xfce in Squeeze? I'm using Sid, and it is working just fine. The behavior you're getting happens to me if I am logged in more than once -- say, in X and on a virtual terminal. After investigating this new behavior, I discovered that it is a new feature instead of a bug, and has to do with the new dependency on PolicyKit. I read the docs (and Googled) until I learned how to configure my system to allow shutdowns from my ordinary user's account even if others were logged in. Then I removed all of my changes to allow that... because I thought about it and realized the default PolicyKit behavior actually would prevent me from forgetting to finish things that I had started (bug had forgotten to finish). If I were you, I would make sure all of the dependencies for 'xserver-xorg' are installed correctly. XOrg now depends on 'hal', which brings in stuff like 'policykit' and 'consolekit', and the problem you're describing sounds like it has to do with those things. HTH eventually, DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: SOLVED, Re: amd64 install hangs installing base system
gcr...@vcn.bc.ca wrote: Thing is, I ran memtest86+ last night but it the computer froze midway through test #3 of the first pass. I assumed it was because I was running a 32 bit version of memtest on a 64 bit architecture, but lacking anything better to try, I ran it again. Sure enough, there was a bad stick. It was a bit surprising since the memory recently tested fine in another machine. Anyway, prob solved. Thanks for your suggestions. Not to be disagreeable, but I had a bad experience with memtest86+ when I added a second 2x2GB set to my first 2x2GB set. The memtest86+ would fail with all 8GB inserted, but would pass with either 4GB set inserted. I tried an alternative, memtester, and it ran through all of the 8GB it could access just fine. I've been running 8GB on this desktop for over a year with not problems at all, so it was just a bug in memtest86+ ... no doubt related to some hardware incompatibility with my particular parts. The experience you are describing sounds quite similar, so I hope your conclusion that you had bad memory was correct! Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: CONFIG_INITRAMFS_SOURCE ??
What is CONFIG_INITRAMFS_SOURCE ?
How can I use it to update my Debian GNU/Linux system kernel to 2.6.30 ?
You cannot "use it" to update your kernel. It is merely one kernel
configuration option among many.
The CONFIG_INITRAMFS_SOURCE option is for providing a text file (during
the kernel build procedure) which lists files and directories to be
included _inside_ the kernel binary image. This makes it possible to
provide files to the kernel before ordinary disk filesystems have been
mounted.
Ordinarily, that is the purpose of an initial ramdisk ("initrd") -- an
archive file loaded by the boot manager (grub, lilo, etc.) during the
boot process allowing access to files (usually kernel modules) needed to
complete the boot process. Packing an initramfs archive directly into
the kernel binary makes it possible to avoid using an initrd -- for
example, if you only have a small number of files that must be available
during boot and you didn't want the initrd baggage. I use an initramfs
archive for exactly this purpose: I compile my own kernels and normally
would not need an initrd, but I need a small userspace binary (v86d)
that a 64-bit kernel can use as a helper to set video modes through a
32-bit BIOS. I just let the kernel know about the list of files I want
packed with the kernel (CONFIG_INITRAMFS_SOURCE) and make sure that
those files are actually present and, bingo, no need for an initrd!
You can read about this in the documentation provided with the kernel
sources. Take a look at this file:
/Documentation/filesystems/ramfs-rootfs-initramfs.txt
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ia32-apt-get on Sid
I use Sid, and have been interested in the appearance of the new ia32-apt-get facility. I see that ia32-apt-get has its own configuration files in /etc/ia32-apt After reading /usr/share/doc/ia32-apt-get/README.Debian, I'm a bit confused on how this new system works 1) The README.Debian file seems to indicate that updating should be performed using ordinary commands such as apt-get update or aptitude update However, 'dpkg -L ia32-apt-get' indicates that new wrappers are provided, 'ia32-apt-get' and 'ia32-aptitude', which makes it seem like updating should be done with those wrappers instead, like this: ia32-apt-get update or ia32-aptitude update 2) When the new packages were first installed, my understanding was that commands like 'aptitude' and 'apt-get' had been diverted, and running them would actually run the corresponding 'ia32-apt*' wrapper instead. Reading NEWS.Debian.gz in /usr/share/doc/ia32-apt-get now seems to indicate that the diversion scheme has been dropped. That raises many questions: Should users be using 'aptitude', or 'ia32-aptitude', or both? Should repository servers be listed in /etc/apt/sources.list and /etc/apt/sources.list.d/*.list or should they be in /etc/ia32-apt/sources.list and /etc/ia32-apt/sources.list.d/*.list? 3) Do the 'ia32-apt*' wrappers keep their own database file for installed packages, or do they share the same database with the primary APT system. For example, I have noticed that 'aptitude' still correctly shows my automatic dependencies, but running 'ia32-aptitude' indicates that none of my installed packages are marked as automatic dependencies. If someone could clear up the confusion for me, I would really appreciate it. Thanks, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: requirements for xfsm-shutdown-helper
Peter Crawford wrote: Folk, A year or two back in Etch, xfsm-shutdown-helper with the appropriate entry in /etc/sudoers, allowed "Log Out", "Restart" and "Shut Down". Now in Lenny, this message is on the console after Log Out. ** Message: xfsm-shutdown-helper.c:215: Hal not available or does not permit to shutdown/reboot the computer, trying sudo fallback instead. What should be changed to allow xfsm-shutdown-helper to work fully? Should there be a file /etc/hal.conf or /etc/hal/hal.conf? Are udev rules needed? Have you read '/usr/share/doc/xfce4-session/README.Debian'? === QUOTE === Managing shutdown - There are three ways to enable user to shutdown the computer from Xfce: - use sudo, and allow user to run /usr/sbin/xfsm-shutdown-helper in sudoers - use dbus and hal - hal and dbus should be installed, up and running - user should be in powerdev group - use policykit and a compatible login manager (gdm is known to work) === END QUOTE === Personally, I switched to the hal/dbus method after having used the 'sudo' method for a while. Both worked fine, but I decided that adding myself to the "powerdev" group made more sense to me than needing to grant myself root permissions just to power off. Opinions will vary, of course -- the rest of the Linux world seems to be much less suspicious of things like 'su' and 'sudo' than myself. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: update-alternatives: how do i get a listing of the names of all link groups?
Paul E Condon wrote: There are several command options to update alternative that require that the user supply a name or a specific link group. 'link group' is a term of art for which there is much discussion in the man page, but I don't see instructions for merely listing all the legitimate current values of the names -- sort of a pick list from which I can choose a string that will result in a symantically correct invocation of update-alternatives. How do I list the names of existing link groups? I'm interested in an answer to this, too. I've been using ls /etc/alternatives Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New kernel / stable Debian fails to detect USB printers
Jen Craigson wrote: > I still cannot normally operate any USB printer connected to my system > after I upgraded to stable Lenny with the stock 2.6.26-2-amd64 kernel. > > It's clear now after more testing that this problem described below is > not ehci_hcd specific as I can get the "module reload" workaround > kludge to work with any of the three USB modules. If playing with modules helps make the printer work, then it sounds like a kernel problem. > What I'd like to know is if there's anything else I can do to get this > to work properly. This problem only happened after upgrading to the > latest "stable" Debian. > > Right now if I ever want to print I have to unload ehci_hcd (or > uhci_hcd or ohci_hcd) and then reload it after the printer is on. > Otherwise they do not see my printer when it's turned on. Do I need to > have some other module loaded for autodetection to take place? Does > this have to do with udev or hotswap? I'm stumped and could use some > help. Ordinarily, problems with printing are the result of user error or bugs in CUPS. To rule out user error, you should follow the standard procedures recommended to set up a CUPS printer. You can use the docs on your own computer installed with CUPS, or use the internet. For example, there is the CUPS Book: http://www.cups.org/book.php If you cannot get it to work following the recommended steps, I would usually recommend searching to see if the problem has already been reported in the Debian Bug Tracking System (BTS). http://bugs.debian.org If you find a similar bug report, you can add your two cents using email or, better, the 'reportbug' program. If you find no similar report, you can start your own new bug report: http://www.debian.org/Bugs/Reporting If you can make CUPS work correctly with your printer after unloading and loading kernel modules, the bug should be filed against the kernel instead of CUPS. > I'd also like to know if this is a bug or if I just did something > wrong. And is there a better place to ask this question then > debian-user or am I at the right place? I appreciate any help or > guidance since I am not a technology oriented person. Debian is a community-based distribution. The developers and maintainers are volunteers, and this mailing list is mostly read by Debian users (with a sprinkling of maintainers and developers). If others aren't having EXACTLY the same problem you are having, then you will most likely not receive an EXACT solution to your problem here. The Right Way to use Debian is to engage in as much self-help as you can, then rely on the resources that exist to get further help. I follow a procedure like this when I run into nasty problems: 1. Read the 'man' (manual) pages and the documentation in /usr/share/doc/ on my own system first. 2. The info from (1) allows me to try experiments to see if I can get things working on my own. 3. Failing success with step (2), I search the internet -- Google, forums, mailing list archives, Debian-specific websites -- to try to learn beyond what I found in the docs on my own machine. I then go back to step (2). 4. Failing step (3), I will ask someone for help here on debian-user, or I may drop an email on some package-specific Debian mailing list (see lists.debian.org) to see if anyone else already knows about the problem I'm having. 5. Failing step (5), I file a bug report. I hate doing this, since the BTS is often overwhelming the volunteers who are supporting the Debian packages, but this is what the BTS is for. If a package isn't working as advertised, then something is broken and needs to be fixed. But under no circumstances do I proceed to step (5) unless the previous four steps are exhausted. Hmm, seems like I omitted step (0): please read the valuable overviews of Debian usage provided here: http://www.us.debian.org/doc The "Debian Reference" is great. If you're new to Debian, you can also look at the NewbieDOC site: http://newbiedoc.berlios.de/wiki (This can be downloaded locally in the package called "newbiedoc".) HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b7ee807.7050...@sbcglobal.net
Re: 2.6.32 kernel needs noapic on Acer Travelmate 430 which earlier kernels did not need
David Goodenough wrote: I recently upgraded the kernel on an elderly Acer laptop from 2.6.26 to 2.6.32 and found that it hung just after initialising the pcmcia socket. Looking at the dmesg output from booting 2.6.26 there seemed to be something about ACPI interrupts, so I added noapic and it now boots. You really need to file a bug report for this. Figure out what kernel you are using (try running 'uname -r', and then match that up with 'aptitude search ~ilinux-image' to get the package name), then run reportbug linux-image- [This depends on you having either configured your networking so that 'reportbug' can use whatever mail server you have installed to send the message, or the proper configurations in your ~/.reportbugrc file so that 'reportbug' can send directly to the Debian BTS server.] DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b897856.5080...@sbcglobal.net
Re: ATI Radeon HD 5600?
On 04/10/2010 10:37 AM, vr wrote: I just picked up a laptop that has that display adapter. lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Redwood [Radeon HD 5600 Series] The highest resolution I've been able to get so far is 1400x1040 but using the VESA driver. xrandr: Screen 0: minimum 800 x 600, current 1400 x 1050, maximum 1400 x 1050 default connected 1400x1050+0+0 0mm x 0mm 1400x1050 60.0* 1280x1024 61.0 1280x960 61.0 1152x864 60.0 1024x768 61.0 800x60061.0 The VESA driver only allows you to use 4:3 modes, with none of the nice features (acceleration, power management) that the Evergreen hardware has to offer. The proprietary ATI fglrx driver only works with versions of the X server before 1.7. What version of Debian are you using? What version of the X server do you have installed? (Try 'apt-cache policy xserver-xorg-core'.) Open source support (via "radeon", but not "radeonhd") for Evergreen cards has been starting to appear since February. Debian Sid has very recent versions of the "radeon" driver (xserver-xorg-video-radeon, v. 6.13.0-1) which includes all of the X support made available so far upstream; but you will really want a very new kernel if you want to take advantage of kernel mode setting. The Debian Kernel Team has backported a lot of DRM support from 2.6.33 into recent 2.6.32 kernels, and also has made available experimental 2.6.33 kernels. (I'm actually using 2.6.34-rc3 compiled from upstream because some Evergreen specific commits appeared yesterday which update Evergreen support, and I am testing a Radeon HD 5750 card which I own.) Some of this open source software has probably trickled into Squeeze/testing by now, if you are not using Sid and don't want to move to it. I've tried to install the ATI driver from AMD's website but when I specify fglrx in xorg.conf X doesn't launch, but the module loads. dmesg | grep fglrx [ 12.403952] [fglrx] module loaded - fglrx 8.71.4 [Mar 2 2010] with 1 minors lsmod | grep fglrx fglrx2236840 0 Does anyone have one of these working @ 1920x1080 resolution? Or maybe offer some pointers to help me get up to 1920x1080? You need an old (pre-1.7) X server to use 'fglrx', and you have to make sure to install kernel headers matching the same version of the kernel you are using, for 'fglrx'. It's possible that ATI will release a new 'fglrx' this month (or next) which is compatible with X server 1.7.X. (I haven't been using 'fglrx', though; I'm only interested in testing the open drivers, and helping to get them to work. If you just want to use the card in a normal way, you should probably try to get 'fglrx' to work until more features are provided by the "radeon" driver later this year.) HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc09b53.2000...@sbcglobal.net
Re: LD_PRELOAD= versus /etc/modules ... ; was "Re (2): LD_PRELOAD= versus /etc/modules ... "
On 03/10/2011 09:46 PM, peasth...@shaw.ca wrote: From: Liam O'Toole Date: Thu, 10 Mar 2011 22:24:29 + (UTC) I'm not aware of a kernel module named v4l1compat, so I can't see how explicitly loading such a module would have helped anyway. [...] The problem you were facing was a userspace one, namely, how to force an executable to load a library that would not otherwise be loaded. That's what LD_PRELOAD achieves. Is "loading /usr/lib/libv4l/v4l1compat.so" synonymous with "loading module v4l1_compat"? If so, then why does the library work for skype in one case and not in the other? Dude, Liam explained that. The file 'v4l1compat.so' is a library file, known as DLL files (dynamic link libraries) in Windows and as SO files (shared object) in Linux. It is not a part of the kernel, and therefore is not a module that can be modprobe'd, blacklisted, etc. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d798ed4.8030...@sbcglobal.net
Re: 2.6.31 kernels
David Baron wrote: There are 2.6.32-rc's around as well, but not on Debian. Why should there not be current stable kernel version on Debian? I always compile my own. Question is that if Debian is keeping it back, is it safe. Version 2.6.31 is available in "experimental". You can use 'kernel-package' with Debian kernel sources from "unstable" or "experimental", or even with upstream source from tarballs or git. My impression is that the kernel team considers 2.6.31 to have been a bit buggier than usual, but they are feeling better about 2.6.32 and plan to use it for Squeeze (when released). I was using the kernel team's test-package server, kernel-archive .buildserver.net, but that machine bit the dust with no known ETA for restoring it to life. I have since moved on to keeping my own upstream git repository and building test kernels from there. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian-installer (squeeze-ia64) fails on new machine
Frank Miles wrote: Has anyone tried installing 'squeeze' recently on a i7/860 machine? [...] Any insights welcome! Isn't Core i7 an amd64 architecture, instead of ia64? I think you need to burn another installer CD, instead of that first coaster you burned. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need to reconfigure sound on every boot
Neal Hogan wrote:
On Tue, Nov 3, 2009 at 9:19 AM, Andreas Ronnquist
wrote:
Hi!
I need to do a alsaconf after every boot, otherwise I don't get any
sound. This is on a ABit motherboard, Nvidia nforce 590 chipset, with
built-in sound. How can I make it configure the built-in sound-card
automatically on every boot?
Once you set you sound settings ('alsamixer' is one way of doing so),
you need to enable /etc/init.d/alsasound. Be sure to make sure that
the script is pointing to the correct location of your config
(asound.state) file (on my gentoo machine it is in /etc).
Debian does not have /etc/init.d/alsasound. It has
/etc/init.d/alsa-utils instead... at least on Sid, which I use.
Lenny might be different than Sid, so I hope someone corrects what I'm
saying if it is, but the startup script is provided by the package
called 'alsa-utils'.
Andreas, do you have 'alsa-utils' installed on your system? If you're
not sure, try opening a terminal and running
apt-cache policy alsa-utils
Here's what I get:
$ apt-cache policy alsa-utils
alsa-utils:
Installed: 1.0.21-1
Candidate: 1.0.21-1
Version table:
*** 1.0.21-1 0
990 http://debian.osuosl.org unstable/main Packages
100 /var/lib/dpkg/status
Neal's description of what the startup script is supposed to do is quite
correct, though. On Debian, the file called 'asound.state' (where your
mixer controls are saved) is located in '/var/lib/alsa'.
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: running acceleraation on ati-hardware
Steven Demetrius wrote: Sthu Deus wrote: I have ATI x1100 on a laptop and in x-server logs I see that it load >> Radeon driver with GLX module... - AFAIK it should allow 3D direct >> rendering - but it is not - visually and the glxinfo utility states >> the same. It also states about setting [...] > Are you using the open-source module or the proprietary module? In order to use 3D acceleration you have to use the proprietary module from ATI/AMD. You can install it via the Fglrx model package in the Debian repository or download it directly from ATI/AMD. The safest way is to use the Debian package. This is not correct. The open source drivers, 'radeon' and 'radeonhd' should both be able to handle 3D on Radeon X1000 generation hardware. Here is a quote from the 'radeonhd' wiki http://www.x.org/wiki/radeonhd "The driver supports full modesetting (read: any mode is usable, not only those provided by the BIOS), and is compatible to RandR 1.3. 2D and Xv (video) acceleration is provided for all supported GPUs; 3D acceleration via Mesa is supported for r5xx/rs690 GPUs (X1xxx) and is in progress for r6xx/r7xx GPUs (HD2xxx-HD4xxx)." Open source support for 3D depends not only on the X server (DDX) driver, but also having a version of Mesa compiled with DRI drivers for your hardware and DRM modules in the Linux kernel. I would advise folks having problems with 3D on 'radeon' or 'radeonhd' to send emails to the mailing lists for the driver they are using. Info about the mailing lists can be found on the freedesktop.org wiki: see above for the 'radeonhd' wiki URI, and the URI for the 'radeon' wiki is http://wiki.x.org/wiki/radeon Read the README and other text files that come with the Fglrx package, you have to install it first. I've found that in some cases I have to rebuild the Fglrx module with Module-Assistant (m-a). After you install the module and other dependent packages you have to run At this point, 'fglrx' is a poor choice for Radeon X1000 cards, since ATI has dropped Linux support for their old hardware. The only choice for people with old ATI cards now is the open source drivers. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is Squeeze right for me?
Having spent just a day in testing I am not happy with the quantity of
bugs.
[...]
But at the same time I want the latest and greatest.
These 2 comments are a contradiction.
Make a decision between those two, and you will have made your decision
regarding whether to switch away from Ubuntu.
The local Linux friends who thought I should move on from Ubuntu
suggested testing as the closest in the Debian world to the Ubuntu way
of doing things. After today I am thinking they were wrong.
They were right only if YOU are willing to learn to deal with breakage
caused by "the latest and greatest" packages. If you don't want to do
that kind of work, then they were wrong.
I need advice.
Use Debian stable ("Lenny") and make yourself familiar with backports.org.
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: copying files from home directory on one machine to directory on another machine
Alexander Kaphuk wrote: G'day, I'd appreciate somebody pointing me where to look for info on how to copy files from a home directory on one machine to a directory on another machine via network. I've got about 100GB of data I need to copy from my desktop running ubuntu 9.04 on to a laptop running Debian Squeeze which are both at my home. I'm not even sure how to word it in just a few words so I can google it. Maybe simplest way is using 'ssh'. You can also use 'rsync', but if you've never used either before then learning about 'ssh' is arguably more important than learning 'rsync'. First read this: http://wiki.debian.org/ssh Then read about 'scp' (included with 'ssh'): http://en.wikipedia.org/wiki/Secure_copy HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: copying files from home directory on one machine to directory on another machine
Alexander Kaphuk wrote: Dave Witbrodt wrote: Alexander Kaphuk wrote: G'day, I'd appreciate somebody pointing me where to look for info on how to copy files from a home directory on one machine to a directory on another machine via network. I've got about 100GB of data I need to copy from my desktop running ubuntu 9.04 on to a laptop running Debian Squeeze which are both at my home. I'm not even sure how to word it in just a few words so I can google it. Maybe simplest way is using 'ssh'. You can also use 'rsync', but if you've never used either before then learning about 'ssh' is arguably more important than learning 'rsync'. First read this: http://wiki.debian.org/ssh Then read about 'scp' (included with 'ssh'): http://en.wikipedia.org/wiki/Secure_copy HTH, Dave W. That's right. I've never used either tool before. Thanks a lot for the tip! Sure. If you're in the mood to learn about every possibility... You might also consider NFS: it allows you to mount directories from one machine on the other machine. If the userid's are the same on both machines, this would be terribly simple and would allow you set up the NFS mount using very few (of its long list of) options. If the userid's don't match, then you can: a) mount with root privileges, copy the files, and change ownership afterward using 'chown -R' or b) mount with special NFS options to change the userid (and/or groupid) -- I sometimes do this using a directory on my GUI desktop, and then file copying automatically results in the userid/groupid matching your user on the destination machine Of course, NFS is not really an option if your source machine (or destination) is running Windows. [In that case, there's always Samba! ;-) ] Just food for thought, DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Compiling kernel
Kumar Appaiah wrote: On Sat, Dec 05, 2009 at 06:59:48AM -0700, deb...@toursbymexico.com wrote: I have a doubt about kernel compilation. Two days ago I compiled by hand 2.6.31.6 and it crashed during the boot process. The configuration was made by hand, starting from the default configuration and perhaps I missed something. Since I had to restore my old slackware bakcup to recover some files and information, I got a copy of the already running (at slack) 2.6.31.6 kernel configuration that is finely tuned for my desktop... my question is: can I simply load such kernel configuration in the 'make xconfig' that is working (same desktop and cpu configuration) and compile it with debian? I mean, it is the same computer and hardware, the same kernel version, etc. Yes. In addition, I would highly recommend using kernel-package to compile your kernel to generate a deb. Here's a nice primer: http://newbiedoc.sourceforge.net/system/kernel-pkg.html I would recommend using the 'make-kpkg' command from the "kernel-package" package as well. But I would not recommend following this old web page document -- it is WAY out of date. Read the documentation in /usr/share/doc/kernel-package after installing it, or Google for a tutorial that is more recent. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Udev ATTR instead of SYSFS
David Baron wrote: Getting a lot of warnings about this on recent udev upgrades. I tried substituting in some of the rules files but might have caused problems. Fact is that this was tested with the recent broken udev and problems were (also?) from udev itself. Should ATTR be simply substituted for SYSFS? Should bugs be filed against the offending rules parents or will these changes simply be systematically done in course? If you are using Sid -- and I think you are, because I had the recent udev breakage and I get the udev error messages you are talking about -- then don't do anything. Nothing is really wrong. The error message is a warning: it only affects the 'hplip' package, and a bug report has already been filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559289 Once the hplip gets around to upgrading the files they drop into /etc/udev/rules, all will be well again. In the meantime, the warning is scarier than it looks. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hp-deskjet-6122 printer and cups
I Rattan wrote:
I am trying to install hp deskjet 6122 printer via cups page.
It finds a driver that has the attribute:
.. Foomatic/gutenprint-ijs.5.2
and configures it. When a test page is printed the error
message ".. guntenprint-ijs" is not installed.
What package might contain this software?
Well, I don't use gutenprint, but I do own that printer... and I do use
CUPS.
For me, the current HPLIP and CUPS packages on Sid are working
perfectly. If you install these packages using 'aptitude', you will get
all of the stuff you need for that printer automatically:
cups
cups-bsd
hplip
hplip-gui
hpijs-ppds
I also recommend
hplip-doc
You should delete any attempts you have made to configure the DeskJet
6122 using CUPS, then configure it using HPLIP. It will automatically
find the proper PPD file ('hp-deskjet_6122-hpijs.ppd', from the
'hpijs-ppds' package) if you do things this way. (If you don't, you
deserve whatever problems result! ;-)
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VGA cards
Johannes Wiedersich wrote:
Camaleón wrote:
On Mon, 14 Dec 2009 13:54:53 +0100, Sven Joachim wrote:
On 2009-12-14 13:28 +0100, Camaleón wrote:
Be sure to avoid Nvidia graphics cards then.
Why?
There is "nv" driver (2D) and soon it will be "nouveau" (2D+3D) driver
available. Both are open source.
The nv driver is heavily obfuscated¹ and, perhaps more importantly, it
lacks some very basic features.
[snip]
It seems we have not many real choices, then :-(
[...]
FWIW, I gave up on using the ati drivers for my card, because I could
not be bothered with all the bugs and with having to reinstall and
configure it on every new kernel version.
So ATI are another brand, I'd recommend to avoid. From what I read, the
overall hassle is generally far less on using Intel cards. YMMV, of
course and not all models of any manufacturer behave the same...
I also gave up on ATI's proprietary 'fglrx' driver several years ago,
exactly because it doesn't work as advertised: it seemed to be more
like a practical joke on users than a functional device driver.
So, when I built a new desktop machine in 2007 I bought an NVidia card:
a GeForce 7950 GT. I was happy with its performance, and was annoyed
with jumping through the hoops to keep the proprietary 'nvidia' driver
up to date... but at least those drivers work. (Usually.)
But then it turned out that NVidia had released two generations of
defective parts -- GeForce 6 and GeForce 7 -- and got their rear ends
sued off. My own GeForce 7950 GT died on me this past summer, just a
few months ago... barely a 2-year old card.
In the meantime, I had been following the new developments with the open
source ATI drivers. I noticed that within 6 months of the initial
release of documentation by AMD/ATI, users of those cards were reporting
that video was working better with the open source drivers than with
'fglrx'. I decided then that my next card would have to be ATI... and
when the 7950 GT died, I was even more motivated to switch to ATI.
I've had a Radeon HD 4850 for a couple of months now. Basic 2D support
is just fine. Acceleration (both 2D and 3D) on my generation of cards
has just appearing recently -- and I have been fighting/playing with
cutting edge source code, including upstream kernels, upstream Mesa and
libdrm libraries, and upstream X drivers (radeonhd, radeon) -- with very
positive results.
Progress on 3 fronts -- DRM in the kernel, 3D support in Mesa, and
advances in the 'radeon' driver ('radeonhd' is now lagging behind, and
is probably doomed) -- is very rapid. At the beginning of November,
OpenGL support was corrupt and useless on my card. By mid-November,
fixes in 'radeon' and Mesa gave me nice accelerated 2D/3D for simple
desktop activity, video, and non-demanding OpenGL games. At the moment,
I am trying to triage a Mesa bug which is causing the more demanding
OpenGL games to suddenly die and disappear (though not crashing X), and
I believe that before the end of 2009 I will have a completely
functional 2D/3D support for this card.
So, after years of preferring NVidia over ATI, I am actually
recommending for folks to switch to ATI (or Intel, if they don't care
about good 3D acceleration) because of their demonstration of support
for open source drivers and, now, because those drivers are actually
working quite well. All of the hassles with building upstream source
code I have been dealing with lately will be gone by Q1 2010, and merely
using stable packages from ordinary repositories will give me ATI
support that Just Works!
IMHO, very good time to be using, or switching to, ATI!
Just my 2 cents,
Dave W.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VGA cards
Camaleón wrote: On Tue, 15 Dec 2009 15:28:19 -0800, Kelly Clowers wrote: On Tue, Dec 15, 2009 at 14:39, Camaleón wrote: That "100 people" was just a "supposition", sir :-) Hmmm, then that sentence needs some qualifiers or something: "so even *if we had* 100 dedicated engineers working on ATI drivers, we *would* still have an incomplete open source driver." Which probably isn't true anyway, with that much in the way of resources, you could reverse engineer it in short enough order. "Reverse engineering" is not legal in some countries and it's not a fair approach when we are speaking about a company (AMD/ATI) that you are naming it as "linux-friendly". Hey, we have the docs and specs, why should we need reverse engineer it at all? >:-) Why are you trolling about this? Go troll on some other list. The ATI people have been great, but they have stated from the outset that some aspects of their closed source driver cannot be opened due to legal issues. The vast majority of the features of their devices, though, are covered by the documentation they have released. In addition, they have also released examples of working source code and they have several _paid_ employees working on the open source drivers and documentation. Your whining is idiotic trolling. The status of the supported capabilities by "radeon" and "radeonhd" drivers is as follows: http://xorg.freedesktop.org/wiki/RadeonFeature http://xorg.freedesktop.org/wiki/radeonhd%3Afeature Does not look so good. I am very familiar with those pages. There is still more work to do of course, but all in all, it looks like very good progress. And you don't bother why AMD/ATI (being a "linux-friendy" company) does not provides these drivers? If I were AMD/ATI, I will like to see at the same level of quality and performance *any* of the drivers I am providing to my users, being windows, linux, *bsd or solaris users. It's one thing to criticize the quality of the drivers: 'fglrx' has always been an insult to Linux users, IMO. But it's another thing to claim that the status of the open source drivers is poor, or that ATI is somehow to blame for the drivers not being perfect already. The documentation on started being released a couple of years ago, and the drivers written with it have been written from scratch since that time. Not all of the docs were released at the same time, so support for those aspects should be expected to be delayed... by anyone who lives in the real world, anyway. (Maybe not by a useless troll who is unable to figure out simple things like this.) I agree that Xorg people have done a very good job (by their own) with radeon/radeonhd drivers. I wasn't speaking of the independent xorg devs (although they also do a good job), I was saying AMD is doing a very good job. In what way is doing a very good job? A good job could be if they collaborate a bit for the development of their drivers, not just by providing "some" specs and letting other doing its job. Pure trolling. Anyone familiar with the development of these drivers knows that AMD/ATI employees are working on this everyday. They respond to comments and questions from users, work on development of the drivers (and related components of the graphics subsystems), and work with other developers to improve all of this software. Your comments merely reveal your ignorance. But I have to disagree in regards AMD/ATI. It's not a linux-friendly company and has not released the full specs for their vga cards. Just some papers. In these days, that's not enough. Just some papers? What else would they release? What specifically do you think they need to release? They need to release the drivers. They need to open source the full drivers to their users. By "they" I mean AMD/ATI, of course, not X.org. The only "drivers" they could have "released" was 'fglrx'. They have always stated that they cannot: intellectual property from other parties prevents them from legally releasing that code. (One may choose to disbelieve them, since we cannot see the code. That is a different question, however.) Instead, AMD/ATI began releasing documentation and example code. As I said in a previous message in this thread: within 6 months the open source drivers were doing video playback more reliably than years of development on 'fglrx' had provided for most Linux users. Look at the r600 docs for example: a 342 page Instruction Set Architecture guide, a 43 page 3D acceleration guide, a 166 page 3D register guide and sample code for manipulating the atom command processor. Look at its current status: http://jbridgman.livejournal.com/945.html "(...) The 6xx/7xx 3D driver is starting to do useful things again after moving over to the radeon-rewrite mesa code base. As of last night, it seems to be behaving properly on 14 of the 63 tests in progs/redbook, drawing incorrectly on 24, and either not drawing or crashing on t
Re: Ugly VGA fonts with console-setup (Squeeze)
Stephen Powell wrote: Things have changed in the area of text-mode console fonts between Lenny and Squeeze. And I'm not happy about it. [snip: that was long!] By running "dpkg-reconfigure console-setup" I can get a VGA font of the right point size (as long as what I need is 8, 14, or 16). But the VGA fonts in console-setup are really *ugly* compared to the very-nice-looking fonts that I'm used to from the kbd and console-tools packages, chiefly lat1u-08, lat1u-14, and lat1u-16. I have kbd installed under Squeeze now, and I can set the font on the fly by using setfont lat1u-08 for example, and then things look OK. But if I switch to the X console with Alt+F7, then switch back to a text console with Cntl+Alt+F1, I'm back to the ugly font from console-setup. Some of the fonts are worse than others. The 8-point font isn't *too* bad, but the 14-point font is horrible. The lower-case "s", for example, doesn't even start on the same baseline as the other letters. Is there some way to make console-setup use the nice-looking fonts from /usr/share/consolefonts that were designed for kbd and/or console-tools? There's a wide selection of them, and a lot of time and effort has been spent over the years to make them look nice. And now that all gets thrown out by the hastily-thrown-together, limited selection, ugly fonts in console-setup. Yuck! What did the 'console-setup' documentation say about setting fonts? Did you at least read the comments in '/etc/default/console-setup'? If reading the docs does not solve the problem for you, you can wait for an answer from debian-user for a while. If no answer comes, you could file a bug against 'console-setup'... but I'm sure the maintainers will tell you: it's not a bug, please RTFM (and they may even tell you how to do it). I actually use settings in '/etc/default/console-setup' to _prevent_ the package from replacing the kernel fonts -- I somehow discovered the weird 10x18 font provided by the kernel a few years ago, and grew to love it! I can tell 'console-setup' to not load any software font at all, and I end up with that 10x18 thing on all my VTs. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Copying only files that are not into the destination
Merciadri Luca wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have two folders, say .../source/ and .../destination/. There are many files in /source/ and in /destination/. There are some more files in /source/. There are so many files in /source/ that I cannot check the ones that are not in /destination/ by myself. I want the files of /source/ which are not in /destination/ to be copied in /destination/. Using cp -i is not a good idea, as there could be something like ~5000 files which are not in /destination/, but which are in /source/. Any idea? man cp | grep -A 2 -- -u HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: running powernowd on debian lenny
Umarzuki Mochlis wrote: 2009/12/27 Dave Witbrodt Umarzuki Mochlis wrote: I have a cq40-115au latop with AMD Turion x2 RM-70 processor. I want to enable powernowd. After i compiled it from source Because you built your own, it becomes more difficult for the rest of us to help you. The Debian 'powernowd' package has been altered from upstream to put its configuration options in /etc/default/powernowd. My answers below are from my own experiences using the Debian 'powernowd' package; you will have to read the documentation in the source code, and figure out how to translate my answers to work for your own setup. (In my view, it was a waste of time for you to compile your own 'powernowd', since Debian already has the package.) i had removed it (now) with #make clean #rm -f /usr/bin/powernowd and installed powernowd package, enabled needed modules #modprobe cpufreq_userspace powernow-k8 So, did that work or not? , when i ran # powernowd here are the output: powernowd: PowerNow Daemon v1.00, (c) 2003-2008 John Clemens /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus: No such file or directory powernowd: err=2 powernowd: Found 2 scalable units: -- 1 'CPU' per scalable unit /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory PowerNowd encountered and error and could not start. Please make sure that: - You are running a v2.6.7 kernel or later - That you have sysfs mounted /sys - That you have the core cpufreq and cpufreq-userspace modules loaded into your kernel - That you have the cpufreq driver for your cpu loaded, (for example: powernow-k7), and that it works. Check 'dmesg' for errors. # uname -r 2.6.26-2-686-bigmem I assume that is a Debian kernel? The default CPU_FREQ_GOV* settings have changed over time. What do you get if you run this: grep CPU_FREQ /boot/config-2.6.26-2-686-bigmem CONFIG_CPU_FREQ=y [...] CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m So, you have an old kernel that defaults to "performance". That will cause your CPU to run at full speed, instead of cycling down when not needed. What is in /etc/fstab? If you installed using a Debian installer, you should have a line like this: sysfs /sys sysfs defaults 0 0 # proc/proc procdefaults0 0 /dev/sda1 / ext3errors=remount-ro 0 1 /dev/sda2 /home ext3defaults0 2 /dev/sda5 noneswapsw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 sysfs /sys sysfs defaults 0 0 Looks OK. # mount -t sysfs none /sys mount: none already mounted or /sys busy mount: according to mtab, sysfs is already mounted on /sys Yep, you already had /sys... no need to try to mount it again. What should I do next? If the 'sysfs' line is missing from /etc/fstab, add it then mount it using 'mount /sys'. With Debian kernels, you need to add two lines to /etc/modules to make it possible for 'powernowd' to run with recent AMD CPUs: cpufreq_userspace powernow-k8 You can load these without rebooting using 'modprobe'. (I build my own kernels, so when I _used_ to use 'powernowd', I simply built these options directly into the kernel.) If you were using 'powernowd' packages from Debian, you could edit /etc/default/powernowd to enable loading the program during the boot sequence and to customize its settings. Since you built your own 'powernowd', tweaking the configuration may involve editing a bootscript or something. (You're on your own here: RTF docs.) One last thought. I played with 'powernowd' for a while. I liked it well enough. Then I found out that the Linux kernel has the CPU_FREQ_GOV_ONDEMAND driver, which can be built into the kernel or used as a loadable module. Debian kernels began defaulting to it a while ago, though your kernel may be old enough that it was not yet using it by default. I decided that 'powernowd' was superfluous, and began using 'cpufreq_ondemand' and never looked back. My advice would be that you do t
Re: running powernowd on debian lenny
Umarzuki Mochlis wrote: 2009/12/27 Dave Witbrodt Umarzuki Mochlis wrote: 2009/12/27 Dave Witbrodt i'm still having the same failure message, there's something amiss from what i had done? Definitely. If your setup was correct, it would be working. I would like to see the output from the following commands: ls -dl /s* mount lsmod cat /etc/default/powernowd So, you have an old kernel that defaults to "performance". That will cause your CPU to run at full speed, instead of cycling down when not needed. this had caused my laptop to shutdown when playing games like secret maryo chronicles That would be an overheating issue. You have a hardware problem with your laptop not keeping itself cool. CPU frequency controlling software is meant to extend your battery life, not to act as a bandaid for inadequate CPU cooling. Any time that you start using your laptop heavily, the software will boost the frequency and you will have the same problems with shutdowns anyway. The only problems that will be solved by running 'powernowd' (or switching to CPU_FREQ_ONDEMAND) are longer battery life and lower temps when not being used for demanding tasks. What is in /etc/fstab? If you installed using a Debian installer, you should have a line like this: sysfs /sys sysfs defaults 0 0 # proc/proc procdefaults0 0 /dev/sda1 / ext3errors=remount-ro 0 1 /dev/sda2 /home ext3defaults0 2 /dev/sda5 noneswapsw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 sysfs /sys sysfs defaults 0 0 Looks OK. the last line was just added by me Oh, I misinterpreted your response as meaning it was already in 'fstab'. How did you install Debian, so that the sysfs line was _not_ in 'fstab' to begin with? DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: building a custom kernel:IT WORKED
Paul Cartwright wrote: on my 4-year old Dell laptop, running Ubuntu, I now have a nice new 2.6.32.1 kernel running! at first it couldn't boot, then I noticed that there was no initrd.. I "forgot" that option... once I built it again, it now boots. SO, I just have to go back through and make it SMALLER... Congrats! Nice job. Make sure you save your '.config' file somewhere safe. You can lose everything else, but if you lose that... you'll have to do all of that nightmare over again. Once you figure it out the first time, it's always easier after that Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: building a custom kernel:IT WORKED
Paul Cartwright wrote: so, the config file works over & over? even for different kernels? Not exactly, but almost. When a new kernel is released, you can reuse most of your old .config by copying it into your Linux source top-level directory and running 'make oldconfig'. This answers the long list of configuration questions automatically, using your old settings, except for options that disappear (features that change, or are dropped entirely, in the new version) and options that are new. For the new options, you'll have to manually provide an answer -- most often (but not always!) the default option is what you want, and you can simply hit . DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Best Keeps Getting Bigger
Just out of curiosity, what's the size of your kernel image file? I also use lilo and no initrd. I'm using 2.6.31.1 with Lenny and have not run into any boot problems yet. -rw-r--r-- 1 root root 12781374 Oct 29 18:11 /usr/src/linux-image-2.6.31- davidb_2.6.31-davidb-10.00.Custom_i386.deb -rw-r--r-- 1 root root 12785544 Nov 16 22:14 /usr/src/linux-image-2.6.31- davidb-svn14611_2.6.31-davidb-svn14611-10.00.Custom_i386.deb -rw-r--r-- 1 root root 12870190 Oct 28 19:29 /usr/src/linux-image-2.6.31-rt- davidb_2.6.31-rt-davidb-10.00.Custom_i386.deb -rw-r--r-- 1 root root 13104356 Dec 27 21:23 /usr/src/linux-image-2.6.32.1- davidb_2.6.32-davidb-10.00.Custom_i386.deb -rw-r--r-- 1 root root 13109468 Dec 28 19:41 /usr/src/linux-image-2.6.32- davidb_2.6.32-davidb-10.00.Custom_i386.deb The last one is the 2.6.32.3 image. Simply note the progression :-) The 2.6.31.1 (first one) is much much smaller. You were not asked for the size of the DEB files, but for the size of the kernel binary image. Like so: $ ls -lA /boot/vmlinuz* -rw-r--r-- 1 root root 2340800 Dec 18 23:34 /boot/vmlinuz-2.6.32 -rw-r--r-- 1 root root 2992976 Dec 20 10:44 /boot/vmlinuz-2.6.32.2-0git091220+k10temp+f71889fg.desktop.uvesafb -rw-r--r-- 1 root root 3232736 Dec 22 21:12 /boot/vmlinuz-2.6.32.2-0git+k10temp+f71889fg+r600fix.091222.desktop.kms Note that most of the space suggested by the size of your DEB files is taken up in the initrd images and in the modules directories: $ ls -lA /boot/init* -rw-r--r-- 1 root root 7424984 Dec 26 17:14 /boot/initrd.img-2.6.32 -rw-r--r-- 1 root root 7427240 Dec 26 17:09 /boot/initrd.img-2.6.32.bak $ du -s /lib/modules/2.6.32* 91452 /lib/modules/2.6.32 3948/lib/modules/2.6.32.2-0git091220+k10temp+f71889fg.desktop.uvesafb 2708/lib/modules/2.6.32.2-0git+k10temp+f71889fg+r600fix.091222.desktop.kms HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: .xsession-errors massive
On 02/21/2011 05:36 PM, Michelle Konzack wrote: Hello Paul Cartwright, Am 2011-02-21 16:01:58, hacktest Du folgendes herunter: $ grep 'XID collision, trouble ahead' .xsession-errors | wc 275772 1930404 18116684 wow, ya got me beat:) $ grep 'XID collision, trouble ahead' .xsession-errors | wc 137884 965188 9100344 I was googling& it looks like a gtk version error, but that was a different distro I think. I think I have to write some bug reports since there are three programs DOSing the .xsession-errors. 680 MByte in 3 days is inacceptable. However, if I stay as usualy one month and longer online my partition will crash... I've been plagued by this one for over a year. The Debian BTS has a bug report for it already, and in comment 35 there I listed similar reports on other bug tracking systems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550352#35 The bug seems to be related to Adobe Flash Player, though a few people have reported the bug being triggered by other apps. A patch was posted which does not fix the underlying problem but provides some relief from the symptoms. I also posted a modified version of that patch, which simply spams .xsession-errors much less frequently. I'm hoping that the upcoming libgtk version 3 will cure the problem. It may be a while before the problematic programs are built against the new version, however. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d631c6e.6080...@sbcglobal.net
Re: hardware acceleration, radeon driver 6.14 (unstable)
On 02/20/2011 03:40 AM, Jim McCloskey wrote: [...] And it seemed to work. /var/log/Xorg.0.log reports that direct rendering and acceleration are enabled. And glxinfo reports: %glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CEDAR OpenGL version string: 2.1 Mesa 7.10 OpenGL shading language version string: 1.20 But when I run glxgears, it reports 60 frames per second, which isn't exactly the level of performance that I had been hoping for. And given that, it's hardly surprising that applications like Google Earth are unusable. The 'glxgears' program is not a benchmark. There is a feature in the radeon driver (vline) which limits the 'glxgears' maximum frame rate to your monitor's refresh rate. Try a benchmark program, or a game that displays the current frame rate (such as 'torcs'), to get a better idea of the performance of the driver on your system. I should point out that Gallium 3D support in Mesa for Radeon cards has been making great strides since the beginning of the year. I use Radeon HD 5750 in my desktop machine, and Mesa 7.11 (unreleased; obtained from upstream, not Debian packages) provided me with a huge jump in performance towards the end of January: one track I use in 'torcs' to test performance jump from min/max frame rate of 18/35 up to 28/60. Some recent commits caused a regression in performance, and I have not received word from Mesa developers yet whether those changes are desirable in spite of the performance issue, or whether they will be taken back. But I am very happy with what I have been seeing lately. Is there anyone who could give me some advice about what is missing here? Or where would be a good place to ask? One good place is the Phoronix Forums. There are trolls and flame wars there, but there are also knowledgeable people (with regard to Radeon hardware and drivers) who are very responsive. I do not participate there (yet) since I only toy with this stuff in my spare time, and have not (yet) been able to dive into it seriously. When it comes to Evergreen (Radeon HD 5XXX) support and performance, the newer your kernel and drivers the better. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d632ea9.2040...@sbcglobal.net
Re: 3.0 kernel fails to compile
On 08/01/2011 08:21 PM, Stephen Powell wrote: I haven't tried this out myself yet, but this may be another symptom of Debian bug report 635536. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635563). At the very least, the above bug report illustrates that there are known problems with kernel-package with the 3.0 kernel. I assume that Manoj is working on it. My understanding is that the Debian Kernel Team recommends using the 'make deb-pkg' target now; they argued that kernel-package should be considered deprecated, but Manoj wanted to continue supporting it since so many people have used it for so long and there is nothing really wrong with it (until now, though it's probably easy to fix). I just finished building my first linux-3.0 custom kernel using the deb-pkg target, and everything works fine. (I frequently test cutting-edge upstream changes to the radeon driver and mesa, and these often involve changes to the radeon DRM in the kernel.) I was a long-time user of make-kpkg, but since I learned how to use the in-kernel deb-pkg target I have been taking the Debian Kernel Team's advice and recommending building custom kernels that way. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e37649e.1080...@sbcglobal.net
Re: 3.0 kernel fails to compile
On 08/02/2011 04:50 AM, Stan Hoeppner wrote: On 8/1/2011 9:44 PM, Dave Witbrodt wrote: I was a long-time user of make-kpkg, but since I learned how to use the in-kernel deb-pkg target I have been taking the Debian Kernel Team's advice and recommending building custom kernels that way. As was I. One downside (depending on how you look at it) IIRC the make..deb-pkg method doesn't pay attention to CONCURRENCY_LEVEL. First run took about twice as long as make-kpkg. Specifying -j2 fixes it, but the whole point of environment variables is so you don't have to. A dtep backwards here IMO. I also had some personal adjustments to make. I made the switch around the same time that I moved from the old GRUB to the new one, and I did not like the order that my installed kernels were being displayed in the GRUB menu at boot; I also found that initrd images were being built for my custom kernels, but I configure my kernels so that no initrd is necessary. Solving the GRUB menu and initrd issues required some intervention with custom hacks, but frankly I don't consider the loss of the CONCURRENCY_LEVEL variable to be a serious problem. This is because of the versioning I use with my custom kernels to distinguish them from those provided by the Debian Kernel Team. For example, to build with 5 concurrent processes (# of CPU cores + 1); modify the kernel's Makefile setting for EXTRAVERSION to reflect that this is a local kernel (and not a Debian kernel); record the date and git commit ID of the last patch I cherry-picked from drm-radeon-testing; and save all output in a log file in case I want a close look at how the build went, I run 'make' something like this: make -j 5 EXTRAVERSION=.1-3dwlocal \ KDEB_PKGVERSION=2.6.39~git+drt110529.2a9e5862 \ deb-pkg 2>&1 | tee ../build-logs/build-log-2.6.39.1-3dwlocal.txt I add the "dwlocal" suffix in EXTRAVERSION so that I can hack '/etc/kernel/postinst.d/initramfs-tools' to look for it and _not_ build an initrd for a kernel with that string in its name. Other (normal) people build custom kernels with initrd's, so they do not need to jump through these hoops. If you are really devoted to CONCURRENCY_LEVEL so much, why don't you leave it in your environment and write a script (or a bash alias) to automatically use it for your custom kernel builds? make -j $CONCURRENCY_LEVEL deb-pkg You could even call the script or alias 'make-kpkg' if you want! ;-) Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e388ebc.8060...@sbcglobal.net
Re: 3.0 kernel fails to compile
On 08/02/2011 07:45 AM, Stephen Powell wrote: On Mon, 01 Aug 2011 22:44:46 -0400 (EDT), Dave Witbrodt wrote: My understanding is that the Debian Kernel Team recommends using the 'make deb-pkg' target now; they argued that kernel-package should be considered deprecated, but Manoj wanted to continue supporting it since so many people have used it for so long and there is nothing really wrong with it (until now, though it's probably easy to fix). I just finished building my first linux-3.0 custom kernel using the deb-pkg target, and everything works fine. (I frequently test cutting-edge upstream changes to the radeon driver and mesa, and these often involve changes to the radeon DRM in the kernel.) I was a long-time user of make-kpkg, but since I learned how to use the in-kernel deb-pkg target I have been taking the Debian Kernel Team's advice and recommending building custom kernels that way. Actually, the kernel team recommends yet another method, which involves downloading the source package with, for example, apt-get --only-source source linux-2.6 then using dpkg-buildpackage to build it. But that has a number of drawbacks. For one, only official Debian source packages (and usually, only the latest one, unless source packages are available at snapshot.debian.org) may be used. Second, the modified package usually replaces the stock package, and I like to keep my old kernel as a backout. We're not really talking about the same thing. The "Debian Linux Kernel Handbook" includes both a method for building kernels identical (or nearly identical) to those produced by the Debian Kernel Team and a method for building custom kernels (which may vary greatly from Debian kernels). For those interested, the handbook is available on the web at http://kernel-handbook.alioth.debian.org or can be installed via the debian-kernel-handbook package in Wheezy or Sid. No mention of 'dpkg-buildpackage' even occurs in ch. 4 of the handbook. (I do use 'dpkg-buildpackage' frequently to build other software packages, such as the X server, the radeon driver, libdrm, and mesa, but not the kernel.) I use the method described in section 4.5 of the handbook (with some personal modifications, of course) even though I am often building kernels from upstream git repos. (Section 4.6 describes this, but simply refers back to the process in section 4.5 for the actual build once the sources are obtained and configured.) I don't like "make deb-pkg" that well for a number of reasons. One of them is that I get a linux-headers-* package and a libc-dev package too, whether I want them or not. make-kpkg is more flexible. I only get the packages that I want. I agree that this is a lack of flexibility. The reason I am not bothered by it is that the in-kernel deb-pkg target builds all of those packages extremely efficiently, and my Phenom II quad core builds my custom kernel and all of the DEB packages in just under 3 minutes when I build using 5 parallel processes. For me, your criticism here is quite underwhelming; you might simply file a wishlist bug report to see whether the Kernel Team is willing to provide some of the extra flexibility you are asking for. > It may be considered deprecated by the kernel team, but it is still supported by Manoj Srivastava, the upstream author and Debian Package Maintainer for kernel-package. See http://users.wowway.com/~zlinuxman/Kernel.htm for a complete explanation of my kernel-building methodology and the reasons behind it. You are of course entitled to disagree with me. ;-) I've read it. I do disagree, but not strongly. I was grateful for the existence of 'kernel-package' and Manoj's work supporting it, and always will be. But times change, and having an in-kernel build target which produces DEBs means that breakage becomes an upstream problem instead of a Debian-only problem. The fact that 'kernel-package' cannot (for the moment) build 3.0 kernels while the upstream "deb-pkg" makefile target _can_ demonstrates the benefits of having the DEB build code in the kernel itself. Your advice on wowway.com, in light of what I have argued above, seems somewhat outdated. My disagreement is only mild, though, and I would not steer anyone away from the procedure you describe if it is working for them; I would just give them different advice... if asked. In Debian solidarity, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e389689.30...@sbcglobal.net
Re: Just finished Squeeze XFCE install, no "Debian" menu
On 05/04/2010 03:27 PM, Curt Howland wrote: Hi. Just finished a fresh Squeeze install, xfce as the main manager. Well, I've used xfce before, along with lots of others in Debian because it's so bloody easy to have more than one. There has always been a "Debian" entry in the main xfce menu, that led to everything and everything that's installed. But this time I don't see one. If I have to add it myself, where is the "root" of the Debian generic menu tree? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489441 DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4be08649.1030...@sbcglobal.net
Re: iceweasel crashing when closing tabs
On 05/20/2010 01:03 AM, bri...@aracnet.com wrote: On Thu, 20 May 2010 04:19:22 + "RyanJB" wrote: That's odd. Mine is 3.5.9 too but I didn't notice any crashes. Does all your tab crash or just on specific websites? If you suspect javascript is the problem, try disabling it and see what happens. oh yeah, I forgot. Is this EVER going to get fixed ? Does it need to be fixed. I get BAZILLIONs of these messages flowing out from iceweasel. (firefox-bin:19665): Gdk-WARNING **: XID collision, trouble ahead http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550352 Maybe the upcoming version of libgtk will make the problem go away. Until that happens, I will be compiling my own with a homemade patch to keep the spam in .xsession-errors under control. Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf5d0e7.5040...@sbcglobal.net
Re: Trouble compiling generic kernel
On 07/26/2010 11:04 AM, Sven Joachim wrote: There's another advice I need to give: while dpkg-dev will automatically use fakeroot when necessary, make-kpkg currently does not unless you set ROOT_CMD=fakeroot in the environment. You can put this setting into ~/.kernel-pkg.conf (I have it there for ages, and forgot about it). One can also add a command line option, --rootcmd=fakeroot or one can simply run the whole 'make-kpkg' command as the argument to fakeroot: fakeroot make-kpkg [...] Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c4da6ee.8010...@sbcglobal.net
Re: IDE PCI Advice Needed
However, I would still like to know how to get the driver into the debian installer image. It seems that there should be a way for the installer to deal with this situation. Like maybe identifying hardware for which no driver is available in the install and asking the user to provide it during installation. Any thoughts? Sorry to jump into this thread so late. I have an old Pentium III machine which needed a PCI card to allow me to use newer drives larger than 137 GB. I faced almost the same situation you are facing. Luckily, I purchased a Rocket 133SB, with an onboard BIOS which allows older OSes to use the drives through the card. Windows, for example, takes a device driver after the install is complete and allows it to use UDMA speeds instead of "legacy mode." What I found in the case of Debian was that the installer CD does not include the necessary HPT302 drivers, but it _installs_ a kernel that does! I was forced to install Debian to the older hard drive attached to the IDE controller on the motherboard first; later, I was able to manually transfer Debian over to the new, bigger, faster drive. If this information is of any help to you, I can provide you with a link to the (long) post I made to this list with detailed instructions about how I carried out these steps. I'm not using a RAID configuration, however, so if that is your intent then you'll have to figure out some further details on your own (and with the help of the good folks on this list!). Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IDE PCI Advice Needed
Stan Banash wrote: Thanks for the info it is much appreciated. Dave please send the link, I would like to review the info. Although, my situation is not exactly the same as yours. In my case the Optiplex bios disables the IDE controller on the motherboard when a second one (the Rocket 133) is added. Therefore both my drive (20GB primary and 250GB secondary) are on the Rocket card. The latest install attempt (linux26) ran to the point where the disk are partitioned. At that point the installer reported that no hard disks were present and I could not go any further. This is as expected, since the CD's kernel has no support for HPT302. If you wanted to follow my solution -- though it looks like Hendrik's is far preferable -- you could pull the Rocket until Debian was installed. I'm unable to find all of the links, but I did find my original description of the problem, http://lists.debian.org/debian-user/2005/05/msg03072.html some of the discussion about moving Debian from the old hard drive to the new drive on the Rocket, http://lists.debian.org/debian-user/2005/06/msg00290.html and my suboptimal, but working, solution: http://lists.debian.org/debian-user/2005/06/msg00334.html You can trace threads to see other posts from the bottom of these messages. Hope it all works out! I know the frustration you are experiencing. I'm in a precarious situation at the moment because I removed the original hard drive entirely and have two new drive on the Rocket... and if I ever had to reinstall Debian I'd be in big trouble. All I really need to do is create my own boot CD, but I haven't taken the time to do it yet. I guess I should do that this week! ;) Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will wine|win4lin|VMWare save my XP bacon?
At the start, my ThinkPad (A31) was dual booted via grub, Windows XP on /dev/hda1, sid on the rest, 2.6.15-homemade kernel. So I added a second hard drive in the UltraBay. I then copied the XP partition to the new drive -- dd if=/dev/hda1 of=/dev/hdb1 bs=$((1*1024*1024)). I double checked: XP booted and recognized both C: and D: drives. OK, I thought, and wiped Windows off the original drive, and took it all for Debian, with / mounted on hda1. So, booting the original XP, it was able to see the new XP partition and read it. At this point I would have run CHKDSK to let it see if there were file system problems, but let's just assume it was OK At this point, BEFORE DESTROYING the working WinXP setup, you should have modified your /boot/grub/menu.lst to give you the option of booting the new WinXP partition. You needed to see if the new one worked before wiping the original. MS writes its OSes to only boot off of a C: drive. That means the WinXP partition has to be on the "first" drive. The machine I'm writing this email on has, at times, had WinXP on the second drive; to accomplish this trick you need to lie to the BIOS using the 'map' feature of GRUB. If you only have 2 IDE hard drives, you'd do it something like this: map (hd0) (hd1) map (hd1) (hd0) This trick the BIOS (and WinXP) into thinking its on drive C:. You're probably in trouble, so I don't want you to get your hopes up. But, if you alter your 'menu.lst' to point to the new WinXP partition, and if you add some 'map' lines, and if the stars are aligned properly and hell has sufficiently frozen over, then you might get lucky here. Another thing is that WinXP sometimes keeps low-level system information at the END of its partition, and it looks like you dd'd only part of the partition. That doesn't bode well, but you won't know until you try. Another choice would be to forget XP, except that it is on rare occasion (involving proprietary dial-up) handy. Yet another would be to bite the bullet, wipe the drive, repartition, reinstall that Other OS on hda, and then reinstall sid. Ugh, what a chore! WAIT!! If 'dd' worked well enough, then maybe you didn't lose all of your data, even if WinXP won't boot. If you can't get it to boot from my advice above, or from help you get from others, then don't erase that partition unless you really had nothing you wanted to save! It's possible, assuming you have a WinXP CD, to try a non-destructive reinstall from the CD. There's probably even a "rescue" feature on the CD that might getting it working. If you can't get the WinXP system booting, you might at least save any files you want to keep by mounting the partition with Linux. If you have trouble doing that, you could reinstall XP to the old location (from your CD) and recover data first... then try moving it again. It seems to me like you have more options that just "wiping" stuff! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will wine|win4lin|VMWare save my XP bacon?
Here's the story, in more detail, for the archives. I rewrote the relevant stanza of /boot/grub/menu.lst to read # This entry automatically added by the Debian installer for a non-linux OS # on /dev/hdb1, "map" lines added by hand. title Windows XP map (hd0) (hd1) map (hd1) (hd0) root(hd1,0) savedefault chainloader +1 I then rebooted into Windows XP. It went _directly_ to "Windows XP Professional Setup," without asking permission (of course), deleted a slew of files and copied a bunch more to hard disk. While this was going on, I was thinking, Let it do what it wants, since it's really on hdb, thinking its on C:. When it was done, it rebooted into grub! And my sid installation is still there! Hurrah! So I booted back into Windows, and this time was in the regular Windows XP Pro Setup, which claimed "Installing Windows" supposedly "to complete in 39 minutes." It took less than 15. Rebooted again, and found I had choices: back to the installer, or two identical lines reading "Microsoft Windows XP Professional." The first one produces a brand new installation of XP, complete with request to register it with Micro$oft. But the second line provides my whole old installation, even IBM Client Security! Half an hour of checking suggests everything still works. Whew! Is this a great list, or what?! And particularly, thanks Dave! Glad to be of some help. And, _yes_, 'debian-user' is great, even when it goes OT. (And I don't mean overtime... I mean stuff about broccoli, etc.) I'm glad it worked out for you. I don't really understand what you did: you said you changed 'menu.lst', rebooted, and found that WinXP was working. Everything after that sounded a lot like you were doing repairs using a WinXP CD, though. Is that true? I any case, it sounds like you dodged the bullet this time. (Shall we call you "Neo," or what? :) If you are getting Win XP to offer boot choices AFTER you boot to Windows with GRUB, then you may get tired of it and want to reconfigure WinXP so that it doesn't do that any more. I'm getting off topic for a Debian list, but you are a Debian user so I guess we can afford to give you some slack. You can go to Start -> Control Panel -> Performance and Maintenance -> System from there choose Advanced -> Startup and Recovery: Settings Then look for: "To edit the startup options file manually, click edit" If you do this you may be in somewhat dangerous territory. I'm not really sure what has happened with your machine -- it sounds like Windows moved your previous system to a new "folder" and installed itself into a fresh one. Normally, this file is used to select different OSes on different partitions to boot from; it is the WinXP equivalent of GRUB's 'menu.lst' file. It can also be used to setup different boot configurations on the same partition. You probably want to backup this file before you edit it. It is usually here: C:\BOOT.INI To get at it you may have to alter its file attributes using ATTRIB from the command prompt. Now, if the lines in this file under "[operating systems]" indicate different values for "rdisk()", then BOOT.INI is actually booting different versions of WinXP from different partitions. On the other hand, if the lines seem identical except for the "folder" at the very end, then you have more than one version of WinXP installed on the same partition. If that is the case, and you don't want the choice of booting to your original WinXP and a new, clean install, you can remove the line to the clean install... and you can erase the folder that contains the clean install if you boot to your original version of WinXP. A second install will just waste drive space, and it may not recognize any of your installed programs anyway. I offer this FYI, since it reminds me very much of a problem I helped a student with recently who had installed WinXP over top of a pre-existing Win2K partition and ended up with a very similar set of boot choices from XP's boot loader (NTLDR). My apologies to the rest of the 'debian-user' community who feel that offering help regarding a competing OS is inappropriate. I do not fear Microshaft and it's current near-monopoly over the OS market; indeed, I have actually begun to feel sorry for it because it's demise is as inevitable as it is appropriate. I also feel that by helping newbies to multiboot until they're ready to make a permanent switch to Debian (or some other Linux... or even joining the Hurd!) it makes people feel like their welcome to join a community instead of some sort of tribal feud between advocates of alternative bit-collections. Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Sarge on SATA
I'm new to the list and fairly new to Debian. I recently bought myself a
new PC (HP Pavilion a1320n) with a SATA drive. I know, that there is an
issue with the 2.4 kernel and I know that it is supposed to work with
the 2.6 kernel. For some reason I can't get it to work, though. As soon
as the installer tries to locate the HDD it fails with an error message.
I also tried to change the BIOS settings, as some articles recommended,
from "Normal" to "Combined" (SATA/PATA) - however my BIOS does not have
any settings I could change (concerning the SATA drive). Some other
linux distribution ("PC rescue CDs") were able to detect and display the
SATA drive.
I'm going to take a shot at this, though I'm no expert or guru.
I have a Dell Pavilion 8400 from last year, and it shipped with a
SATA150 drive. I was also not able to install Sarge until I altered
my BIOS settings from SATA/AHCI mode to UltraATA-emulation mode. It
sounds like your BIOS doesn't allow that, though I'm a bit surprised
if that's true. (No offense.)
There are two possibilities that I know of:
1) I read in different places about conflicts between CD drivers and
SATA drivers on the Sarge installation CDs. One link actually
provided instructions about temporarily removing a module until the
hard drive was partitioned, then restoring it.
The Sarge installer documentation also mentions a slightly
reminiscent problem:
SATA driver can block access to CD drive in installations
from CD. On systems having a SATA IDE controller that also
has the CD drive connected to it, you may see the installer
hanging during hardware detection for the CD drive or failing
to read the CD just afterwards. A possible reason is that the
SATA driver (ata_piix and maybe others) is blocking access to
the CD drive.
You can try to work around this by booting the installer in
expert mode and, in the "Detect and mount CD-ROM" step,
selecting only the drivers needed for CD support. These are
(ide-)generic, ide-cd and isofs.
The drivers needed to access the disk will still be loaded,
but at a later stage. By loading the CD drivers before the
SATA driver in this way, you may be able to complete the
installation. Note that CD-ROM access may still be an issue
after rebooting into the installed system.
(http://www.debian.org/releases/stable/debian-installer)
On the other hand, it's very possible that the kernel on the Sarge
installer CD simply doesn't have support for your hardware. I
actually was unable to install Sarge onto my older Pentium 3 machine
because I was using a PCI controller that would allow me to use larger
hard drives that my motherboard's controller could handle. The crazy
thing was that, even though the kernel on the CD couldn't recognize
the controller, when I installed Debian to a drive on the motherboard
controller the kernel _did_ recognize the PCI controller. I had to
move everything from the old hard drive to the new one.
2) If the Sarge CD can't do it, then you can try a recent Etch CD,
which has a newer kernel and is far more likely to recognize your
hardware. They've even got the Etch installers to work now! ;)
(For a long time, if you burned an Etch netinstall CD and tried to use
it, it just wouldn't work -- not without massive user intervention,
anyway.)
Dave W.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Sarge on SATA
Simon Meelich wrote: I guess I will give the Etch CD a shot, haven't tried this so far. Thanks for the advise. If I don't find a solution, I will go ahead and buy an IDE drive to install Debian to; I just can't believe, that I can't get it to work with SATA and this really bugs me... :-) Am I the only person who has problems installing Debian on SATA? No, not the only one. Remember that Debian 'stable' is always a little bit behind the cutting edge... intentionally. Good luck with Etch. It should work fine -- I'll be surprised if it doesn't. If you have to use a PATA drive to install Debian, then as soon as it's working add www.backports.org to your '/etc/apt/sources.list' (see the instructions at backports.org), run 'apt-get update', and then install a newer kernel. (This is all assuming that the kernel the CD installs doesn't recognize the SATA controller... which it might. The kernel _on_ the CD isn't the same as the kernel that it installs!) After that, you can migrate Debian to the SATA drives... and return the PATA drive for a refund! :) I think Etch will just work, though. DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Sarge on SATA
Simon Meelich wrote: Dave, YOU'RE THE MAN! Thanks a lot for the advise with Etch. It worked without any problems, you stopped a three day pain... :-) Very glad to see it worked! When I had to install to an old drive, then transfer to the newer ones, it was really a PITA. Be careful with Etch. Watch the 'debian-user' list for signs that it's a bad time to update stuff. As long as there's no major security breaches discovered, you might be best off leaving a working system alone as much as possible. Having said that, I think you'll be just fine. Have fun! I recommend reading some documentation. Look around in /usr/share/doc, browse the list of docs at www.tldp.org, consider installing the 'rutebook' package (if you're a newbie... though I may be being presumptuous here), and definitely read the Debian Reference and the APT-HOWTO (both in /usr/share/doc/Debian on my Sarge machine here). The reading can be long and tiresome (so take notes), but it pays off _very_ quickly. Quite a few folks have problems getting sound and printers to work with Linux, so just don't get frustrated too easily. Just today I cured myself of a bad case of idiocy after running Debian for almost a year now: I had somehow installed the BSD-style 'lpr' package, which was trying to talk to a printer on my parallel port; unfortunately, there is nothing connected to my parallel port, and I actually have a USB printer that I access through CUPS. Installing 'cupsys-bsd' a few hours ago made everything work (finally)! If you want to learn how Debian works under the hood, pick up a copy of Krafft's _The Debian System_. The most professional and readable reference on system administration -- understanding Unix file systems, handling user accounts and permissions, etc. -- that I've ever seen is Frisch's _Essential System Administration_. Like I said... have fun! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NVidia 1.0.7174 driver and backports.org kernel 2.6.15
gdm' every time I reinstalled the NVidia
module, but it would never work when I rebooted! I thought the gods
were playing a practical joke, or something
I had to work today, so I was thinking about it on and off whenever I
had a spare moment. Something that the installer was setting up was
being lost at reboot. What was it?
From the past month of research, I realized that the newer kernels
handle the /dev device nodes dynamically: they are no longer "files"
on a disk, but are recreated each time the system reboots, or whenever
a supported device is hotplugged that requires device nodes. This old
NVidia driver could not possibly know how to handle the situation
correctly, so whatever changes it made in /dev were being lost, and
nothing else on my system knew anything about it.
Here is what I know about the problem so far, and how I finally got
something to work:
1) If you use the "--extract-only" option with the NVidia installer,
as you _must_ if you're going to patch it, you will be able to find
the file that modifies '/dev', a script called 'makedevices.sh' in the
'../usr/src/nv' directory below the directory created by
"--extract-only". The important code looks like this:
if [ ! -c /dev/.devfsd ]; then
for i in 0 1 2 3 4 5 6 7; do
node="/dev/nvidia$i"
rm -f $node
mknod $node c 195 $i || error "mknod \"$node\""
chmod 0666 $node || error "chmod \"$node\""
done
node="/dev/nvidiactl"
rm -f $node
mknod $node c 195 255|| error "mknod \"$node\""
chmod 0666 $node || error "chmod \"$node\""
fi
There is code just after this which is supposed to allow 'udev' to
handle the situation properly, and this is what I hope to modify
(tomorrow... it's getting late and I'm getting tired tonight!) to
create the Right Way solution. Essentially, this script creates nodes
in /dev required by the 'nvidia' module; if they're not present when
'nvidia' gets loaded, it dies... preventing X ('gdm', in my case) from
starting.
I Googled, and found a forum somewhere with a suggestion (in 2003) to
modify a file called 'rc.sysinit', adding the lines above with the
'if'/'fi' statements removed. The idea was to manually recreate the
same /dev nodes at each reboot that the NVidia installer creates when
it runs. I thought that was worth a try!
The corresponding file on Debian seems to be '/etc/init.d/rcS', which
is listed in '/etc/inittab' as the script to run to initialize the
system. I tried placing the code from above in there, near the top of
the file, but it didn't work. I don't understand all of the low-level
issues well enough, but I guess it was too early in the boot process
for code like that to run. (Someone else care to educate me on these
matters? I would be most grateful.)
I decided to try placing the code somewhere just before 'gdm' gets
started. This way it's not too soon in the boot process, but the
nodes get created before 'gdm' tries to load the 'nvidia' module.
Instead of trying to modify things in individual '/etc/rc[2-5].d'
directories, I decided to add the code to the 'gdm' script itself:
'/etc/init.d/gdm'.
That worked! Near the top of the 'gdm' script I have placed these lines:
# 060412 Hack to create nvidia nodes in /dev/ to allow a new
# kernel 2.6.15.060411.p3 use NVidia 3D drivers
#
# This code is copied from 'usr/src/nv/makedevice.sh' from the
# NVidia installer source obtained with "--extract-only"
for i in 0 1 2 3 4 5 6 7; do
node="/dev/nvidia$i"
rm -f $node
mknod $node c 195 $i || error "mknod \"$node\""
chmod 0666 $node || error "chmod \"$node\""
done
node="/dev/nvidiactl"
rm -f $node
mknod $node c 195 255|| error "mknod \"$node\""
chmod 0666 $node || error "chmod \"$node\""
Now 'gdm' starts just fine when I reboot, and '/var/log/XFree86.0.log'
shows no errors.
Like I said, tomorrow I'm going to read up on 'udev' and see if I can
do this The Right Way. Maybe someone else can explain it to me in the
meantime? I would be grateful for that, too.
In any case, I hope this scroll may be of some usefulness for folks
out there wanting to use old NVidia drivers with new custom kernels on
Debian.
Dave Witbrodt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hardware Wiki
Is there a wiki somewhere where I can put my experiences installing Debian on my laptop, similar to the Gentoo wiki? I know of wiki.debian.org, but it doesn't seem to have an appropriate area. If your hardware isn't already listed here, you could follow the instructions: http://kmuto.jp/debian/hcl/index.cgi Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling packages for the standard distribution with -Os instead of -O2
Just out of curiosity, what is the Debian Way to change compiler settings like -Ox and -march? Can this be done with command line options when using higher level tools like 'apt-get -b source ' (with more options specified here, obviously)? Or does one download the source .deb, hack something in the build scripts, and then manually run 'dpkg-buildpackage'? Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swap and /tmp
Please correct me if I'm wrong: About 2 years ago I started reading up about Linux when I was first decided whether to try it, and which distro to use. I took about a year before I finally installed Debian last May. During that time I remember reading that some programs that write to CDs or DVDs were caching data in /tmp before burning. It seems like using tmpfs for /tmp under that kind of scenario would be a real problem. My old box would probably roll over and die, and my newer one probably would if a DVD image was being built in /tmp. That info is, admittedly, out of date... but I would want to take a serious look into such things before putting /tmp on a tmpfs! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: swap and /tmp
During that time I remember reading that some programs that write to CDs or DVDs were caching data in /tmp before burning. It seems like using tmpfs for /tmp under that kind of scenario would be a real problem. My old box would probably roll over and die, and my newer one probably would if a DVD image was being built in /tmp. That info is, admittedly, out of date... but I would want to take a serious look into such things before putting /tmp on a tmpfs! It really doesn't matter where these applications cache theire temporary data. The only importance such considerations have is in deciding how much space to allocate to your /tmp - it doesn't matter weather it is stored on a disk partition or a ramfs filesystem. I think you might be misunderstanding what ramfs does. using ramfs doesn't put any additional restrictions on the maximum size of the temp partition. You just have to add whatever space would have been used for a tmp partition to your swap partition, and you will be able to support just as many CD and DVD images. The effect of using ramfs is to allow things to run faster by removing any requirement to keep a complete filesystem image on non-volatile media (disk), and to allow greater flexibility by allowing disk space to be distributed between /tmp space and backing store for memory on demand rather than being fixed at installation time. I can see where it would work well under sane conditions. It just seems like problems would emerge if too many little files were created in /tmp, or if someone tried to burn a DVD with a program that used /tmp while they had other resource intensive programs running. Most of the time it should work just fine, so I'll have to try it out. :) It just seems like many things could go wrong that couldn't go wrong using a physical /tmp partition. I'm about to set up a web/email server, and I can see where using tmpfs for /tmp would be of great benefit in that situation, as long as /tmp and swap are sized properly. Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with 'esd' and changing users while using Gnome
Tonight I logged out from one user account and logged into another. When Gnome came up, there was no sound. I checked the volume, read some documentation, and eventually checked ~/.xsession-errors. I discovered that I was getting errors with the 'esd' sound daemon. After some Googling, I found that others (on various distributions of Linux using Gnome) have experienced the same problem: 'esd' is supposed to be killed when a user logs out, but if it isn't killed then the next user trying to log in is prevented from using sound because of permissions on a temporary 'esd' socket not being reset. Have some of you had the same problem? Is there a cure for it, or is it a randomly occurring thing that is a kind of annoyance? Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with 'esd' and changing users while using Gnome
Tonight I logged out from one user account and logged into another. When Gnome came up, there was no sound. I checked the volume, read some documentation, and eventually checked ~/.xsession-errors. I discovered that I was getting errors with the 'esd' sound daemon. After some Googling, I found that others (on various distributions of Linux using Gnome) have experienced the same problem: 'esd' is supposed to be killed when a user logs out, but if it isn't killed then the next user trying to log in is prevented from using sound because of permissions on a temporary 'esd' socket not being reset. Have some of you had the same problem? Is there a cure for it, or is it a randomly occurring thing that is a kind of annoyance? Dave W. This is a typical problem that tons of users have experienced. Esd may support releasing the sound device node after a short timeout. Check its manual pages. Alternately, if your sound card doesn't support multiple sources at once, and you're using alsa, you can set up alsa to software mix for you, allowing each user to "grab" and alsa device node, and use it with impunity. Check out the alsa web site for their asounrc documentation. http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php Hope that helps, Justin It was very helpful! Thanks, Justin. I had to work today, so I didn't make it to the esound docs yet. I didn't know about the ALSA alternative -- though my card is quite able to handle multiple sources. This is the first time I had any trouble with sound, so maybe I'll read up and see if there are any alternatives to esound which have the same (or better) functionality. DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SBC DSL Service
Debian User Leonard Chatagnier wrote: I was contacted by SBC(telephone service) about DSL service which I want. [...] If there is anyone using this service via SBC, I would certainly appreciate hearing from you. Appreciate any replys. Leonard Chatagnier I've been using SBC DSL for about a year. I did run the SBC CD on Windows, because I didn't have Debian installed yet. The CD has an automated configuration program, then a bunch of other stuff -- like a specialize IE browser and some "diagnostic" software -- which are completely unnecessary. The config process (under Windows) had some sort of glitch, and I remember it appearing to freeze... until I made one little change that caused the thing to finish installing correctly. As it turns out, all you really need is to get your user name and password registered. SBC provides a web page for you to do it, which is (in their view) only for use by technicians. You can find some detailed instructions at broadbandreports.com: http://www.broadbandreports.com/faq/amfaq/ 1.3%20Establishing%20moving%20&%20upgrading%20DSL (That's all one link.) This will get your connection working even if you don't have Windows on your machine. If you want to just use the CD they send you, you'll have to set up your machine to multiboot with Windows. Once the connection is working, Debian will be able to use it. If you already have a working Debian system, I'm not exactly sure what configuration changes you should make, but there's plenty of very knowledgeable people here who do know. (There probably a script or two that will perform an autodetection for you -- I didn't have to deal with this issue because I installed Debian with my SBC connection already working.) HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
