passwordless ssh root logins stopped working after testing dist-upgrade
I dist-upgraded yesterday and ssh root logins started requiring a password. I also tweaked some other stuff and installed calibre and miro to check them out and they came with a boatload of dependencies so maybe there's something lurking there. Regular user ssh logins work just fine. I decided that it would be a good time to update my keys and redid everything very carefully from scratch. VERY CAREFULLY checked .ssh and authorized_keys permissions, etc. No change. This affects both user->r...@localhost ssh logins and to remote hosts. It smells like an ssh-agent problem, but then why would regular user ssh logins continue to work? Tia for any clues. I won't be surprised if I did something dumb... I've got a stock /etc/ssh/sshd_config and very long time modified ssh_config: r...@feyerabend> diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes -- 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/4bbb7983.2010...@pinyon.org
Re: passwordless ssh root logins stopped working after testing dist-upgrade
tr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug3: Wrote 24 bytes for a total of 848 debug2: dh_gen_key: priv key bits set: 138/256 debug2: bits set: 498/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: Wrote 144 bytes for a total of 992 debug3: check_host_in_hostfile: filename /home/rcarter/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'localhost' is known and matches the RSA host key. debug1: Found key in /home/rcarter/.ssh/known_hosts:1 debug2: bits set: 533/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: Wrote 16 bytes for a total of 1008 debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug3: Wrote 48 bytes for a total of 1056 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/rcarter/.ssh/id_rsa (0x7f58126f2ba0) debug2: key: /home/rcarter/.ssh/identity ((nil)) debug2: key: /home/rcarter/.ssh/id_dsa ((nil)) debug3: Wrote 64 bytes for a total of 1120 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/rcarter/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug3: Wrote 368 bytes for a total of 1488 debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/rcarter/.ssh/identity debug3: no such identity: /home/rcarter/.ssh/identity debug1: Trying private key: /home/rcarter/.ssh/id_dsa debug3: no such identity: /home/rcarter/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password r...@localhost's password: Ryan Manikowski ]] Devision Media Services LLC [[ www.devision.us r...@devision.us | 716.771.2282 On 4/6/2010 4:06 PM, d.sastre.med...@gmail.com wrote: On Tue, Apr 06, 2010 at 03:24:04PM -0400, Tony Nelson wrote: On 10-04-06 14:12:19, Russell L. Carter wrote: r...@feyerabend> diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any "PermitRootLogin without-password" line in your diff. Hello, That would disable password login for root, but does not enable per-se pubkey auth (AFAIK). man sshd_config explain this: PermitRootLogin, PubkeyAuthentication and AuthorizedKeysFile entries. Regards. -- 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/4bbb9b91.6050...@pinyon.org
Re: passwordless ssh root logins stopped working after testing dist-upgrade
Ryan Manikowski wrote: On 4/6/2010 4:37 PM, Russell L. Carter wrote: What you're trying to do here is login to the 'root' account using your non-root account to initiate the ssh connection. It is reading the 'id_rsa.pub' pubkey file from /home//.ssh/ and this is why it is failing. The non-root account on the remote side (in this case, your localhost) does not have access to ANY files in /root/ so it will never work. Ryan Manikowski Ok, if that is the correct explanation, why does ssh to another regular user account work? Why does ssh root@ just work? I just performed the following steps: On my main system I have two user accounts, 'rcarter' and 'sardine'. I remove the .ssh directories from 'rcarter', 'sardine', and 'root'. I create a new rsa key for rcarter (creates ~rcarter/.ssh) and then ssh-copy-id -i the new key to sard...@localhost and r...@localhost, which creates a new .ssh directory with authorized_keys for each. Then I ssh-add the new key to the agent as rcarter. 1. $ ssh sard...@localhost logs in w/o password 2. $ ssh r...@localhost asks for password This is reproducible on two 'testing' systems that have worked flawlessly for at least two years each, but were both dist-upgraded yesterday, and they now exhibit this same behavior. HOWEVER! I ssh-copy-id the new key created by rcarter to root on two systems that I haven't dist-upgraded in several weeks and then ssh root@ works fine, as it always has. I diffed the ssh_config and sshd_configs and the only difference were comments. So the problem would seem to be in sshd. transcript: (I removed root and sardine's .ssh dirs before) rcar...@feyerabend> pwd /home/rcarter/.ssh rcar...@feyerabend> cd .. rcar...@feyerabend> mv .ssh dot.ssh rcar...@feyerabend> ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/rcarter/.ssh/id_rsa): Created directory '/home/rcarter/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rcarter/.ssh/id_rsa. Your public key has been saved in /home/rcarter/.ssh/id_rsa.pub. The key fingerprint is: 54:06:d2:08:a4:6d:26:9e:e0:0f:01:1a:1f:67:ff:91 rcar...@feyerabend The key's randomart image is: +--[ RSA 2048]+ |o ..=..o..o | |oo * + | |o.+ + . E| |.o.= o . | | oo S| | o | | . | | | | | +-+ rcar...@feyerabend> ssh-copy-id -i sard...@localhost sard...@localhost's password: Now try logging into the machine, with "ssh 'sard...@localhost'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. rcar...@feyerabend> ssh-copy-id -i r...@localhost r...@localhost's password: Now try logging into the machine, with "ssh 'r...@localhost'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. rcar...@feyerabend> slogin sard...@localhost Enter passphrase for key '/home/rcarter/.ssh/id_rsa': rcar...@feyerabend> ssh-add Enter passphrase for /home/rcarter/.ssh/id_rsa: Identity added: /home/rcarter/.ssh/id_rsa (/home/rcarter/.ssh/id_rsa) rcar...@feyerabend> slogin sard...@localhost Linux feyerabend 2.6.32-3-amd64 #1 SMP Wed Feb 24 18:07:42 UTC 2010 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Apr 6 16:36:06 2010 from localhost sard...@feyerabend> exit logout Connection to localhost closed. rcar...@feyerabend> slogin r...@localhost r...@localhost's password: rcar...@feyerabend> ]] Devision Media Services LLC [[ www.devision.us r...@devision.us | 716.771.2282 Ryan Manikowski ]] Devision Media Services LLC [[ www.devision.us r...@devision.us | 716.771.2282 On 4/6/2010 4:06 PM, d.sastre.med...@gmail.com wrote: On Tue, Apr 06, 2010 at 03:24:04PM -0400, Tony Nelson wrote: On 10-04-06 14:12:19, Russell L. Carter wrote: r...@feyerabend> diff -u ssh_config ssh_config.dpkg-dist --- ssh_config 2010-04-05 21:14:26.172871668 -0700 +++ ssh_config.dpkg-dist2010-01-04 09:05:12.0 -0700 @@ -17,8 +17,8 @@ # ssh_config(5) man page. Host * -ForwardAgent yes -ForwardX11 yes +# ForwardAgent no +# ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes I don't see any "PermitRootLogin without-password" line in your diff. Hello, That would disable password logi
isc-dhcp-server not receiving DHCPDISCOVER
Hi,
After wearing out the google I'm going to foist my problem onto you
good folk.
I've got an internal net with several dual-homed jessie boxen. I
would like to get isc-dhcp-server up so I can configure my new UniFi
toy. The server has two statically configured interfaces, eth0 and
eth1.
The server's dhcpd.conf contains:
ddns-update-style none;
log-facility local7;
option domain-name "xx.pinyon.org";
option domain-name-servers 10.0.10.5, 10.0.10.7;
option routers 10.0.10.5;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 10.0.11.0 netmask 255.255.255.0 {}
subnet 10.0.10.0 netmask 255.255.255.0 {
pool { range 10.0.10.50 10.0.10.100; }
}
and I've set INTERFACES="eth0 eth1" in /etc/default/isc-dhcp-server.
isc-dhcp-server starts fine. I then listen for DHCP packets on the
10.0.10.0 net with
$ dhcpdump -i eth0
On the test (jessie) client I have ifdown'd eth0 and execute
$ dhclient -v eth0
(I can bring up static eth0 on the client and ping the server fine)
The problem is that no DHCP packet is received by the eth0 interface
on the server. As a first test I've ifdown'd the eth1 interface on
the server and tried running a dhclient and I DO see the DHCPDISCOVER
packets.
Neither the server nor the client is running a firewall. iptables is
not even installed. For kicks I enabled /proc/sys/net/ipv4/ip_forward
but this had no effect. I've got a smart switch in the middle but I
checked and everything looks fine.
It looks to me that the client UDP broadcast is blocked from reaching
the server, but what could cause that?
Any ideas much appreciated.
Russell
--
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/52a0f8c6.6010...@pinyon.org
Re: isc-dhcp-server not receiving DHCPDISCOVER
Greetings Bob,
On 12/05/2013 04:27 PM, Bob Proulx wrote:
> Russell L. Carter wrote:
>> I've got an internal net with several dual-homed jessie boxen.
>
> I see that you have 10.0.10.0/24 on one and 10.0.11.0/24 on the other. Is
> that correct? And you only want dhcpd to serve DHCP requests on the
> 10.0.10.0/24 network?
Correct.
[...]
>> subnet 10.0.11.0 netmask 255.255.255.0 {}
>
> Don't serve the 10.0.11.0/24 network. Which interface is which just for
> the discussion?
eth0
>> subnet 10.0.10.0 netmask 255.255.255.0 { pool { range 10.0.10.50
>> 10.0.10.100; } }
>
> Looks okay.
>
> Personally I always prefer to have the routers option configured in the
> subnet section. Because different subnets will have different routers and
> that makes it obvious and easy to set that way. I realize you only have
> the one and so the global definition should be fine. This is just looking
> to the future.
Right.
>> and I've set INTERFACES="eth0 eth1" in /etc/default/isc-dhcp-server.
>
> If you don't want dhcp to server DHCP requests to the 10.0.11.0/24 subnet
> then why have the interface listed? (Or if some other configuration is
> happening please say because the only thing that I can think of that makes
> sense is that you have one on one and one on the other but have disabled
> one of them.
>
>> isc-dhcp-server starts fine.
>
> You might want to verify:
>
> # netstat -na | grep :67 udp0 0 0.0.0.0:670.0.0.0:*
>
> # netstat -a | grep :bootps udp0 0 *:bootps *:*
Yup, I got that.
> Somewhat of a misfeature but the isc dhcpd (along with dnsmasq too) listens
> to all interfaces and simply ignores traffic not in the provided interface
> list. It would be better if it bound itself only to the interface IP
> address. Because binding to the wildcard address makes it impossible to
> run multiple daemons on the same machine. Which is often a collision when
> using VMs and dnsmasq for example.
>
>> I then listen for DHCP packets on the 10.0.10.0 net with
>>
>> $ dhcpdump -i eth0
>
> Looks good. I am sure you are also looking with tcpdump too? Just in case
> the packets are being seen but not as dhcp traffic for some reason?
>
>> On the test (jessie) client I have ifdown'd eth0 and execute
>>
>> $ dhclient -v eth0
>
> I am probably confused here but I always thought that the interface needed
> to be UP before you could run dhclient on it. And I always thought it
> needed root permission. Try both.
Ok, I need to do some experimenting here. I've broken out a long
patch cable to bypass the switch and am steeling myself for the
tcpdump learning experience. However, that's probably a big net plus
because I discovered that the stock wireshark is hanging for me after
a basic capture, even with all lookups turned off. grrr. Well I need
to diversify my tools evidently, even simplify.
Thanks Bob for the tips, the stuff below will keep me busy tomorrow
morning. I'll report back what I find.
Russell
> # ifconfig eth0 up # dhclient -v eth0
>
> But I worry about where DBDIR/dhclient.leases is defined to be by default?
> I don't know if you need to set it. This is the usual place on Debian for
> it.
>
> # dhclient -v -lf /var/lib/dhcp/dhclient.eth0.leases eth0
>
> Also you probably want to try the /etc/network/interfaces config and seeing
> if it is happier if it uses all of the defaults. I would start here. It
> is much easier than remembering all of the details manually.
>
> # ifdown eth0 ...edit /etc/network/interfaces...set up... iface eth0 inet
> dhcp ...save file... # ifup eth0
>
> Note that if the interface is up and you rearrange the file then ifdown
> won't match the up. They will be out of sync. This might leave a dhclient
> running in the background for example. You may have to clean things up.
> So normally you need to bring the interface down before making big changes
> to the file and then bringing it up afterward. But you are aware of the
> state such as whether dhclient is already running or not then you can
> carefully do it with it up too.
>
>> (I can bring up static eth0 on the client and ping the server fine)
>
> Good.
>
>> The problem is that no DHCP packet is received by the eth0 interface on
>> the server. As a first test I've ifdown'd the eth1 interface on the
>> server and tried running a dhclient and I DO see the DHCPDISCOVER
>> packets.
>
> On the client listen to the interfaces with tcpdump. Are the packets
> leaving it? Here are some possibly useful hints.
>
> # tcpdump -lni any # tcpdump -lni any not arp # tcpd
Re: isc-dhcp-server not receiving DHCPDISCOVER
On 12/05/2013 06:04 PM, Bob Proulx wrote: > Russell L. Carter wrote: >> Ok, I need to do some experimenting here. I've broken out a long patch >> cable to bypass the switch > > I would really be surprised if the switch has broken down. Not impossible > of course. But what are the odds? I think it very unlikely. If I were to > guess I would guess it more likely that packets are being routed to the > wrong place. I think that is many times more likely. > >> and am steeling myself for the tcpdump learning experience. > > You will be surprised how easy it is! Just run it. Control-C out of it to > stop it. > So the awesome foodie in-laws dropped in for a couple of days, and I'm the cook. But I shooed them off this morning and finally got a chance to look at this again. I reconfigured my net to get the DHCP conversation on the least used net, patched the laptop directly to the server, and on the server ran $ tcpdump -lenx -i eth1 -s 1500 port bootps or port bootpc On the laptop I generally use wicd, and I know that works, so to simplify things I just told wicd to connect using DHCP. And it worked! I'd not have such a shiny head today if I had done this months ago, when I first noticed the weirdness. I just used the DD-WRT AP DHCP server so that I could maximize my procrastination metrics. So then the problem was to figure what was awry with the switch, a D-Link DGS-1224T. I thought I had sometime in the distant past lobotomized it but it turns out no, I didn't get it done completely. In particular, IGMP snooping was enabled. I downloaded the switch's manual (thanks D-Link!) and here is what it said: "With Internet Group Management Protocol (IGMP) snooping, the Web-Smart Switch can make intelligent multicast forwarding decisions by examining the contents of each frame’s Layer 2 MAC header. IGMP snooping can help reduce cluttered traffic on the LAN. With IGMP snooping enabled globally, the Web-Smart Switch will forward multicast traffic only to connections that have group members attached." But there were no "group members" defined. Oops. Disabled, applied, power off/on, voilà. Thanks Bob! (I used this tutorial for tcpdump: http://www.danielmiessler.com/study/tcpdump/ I guess I'm a believer now.) > Good luck! > > Bob > -- 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/52a3c18e.1060...@pinyon.org
cyapa kernel module equivalent in 4.1.0-2-amd64
Hi, I am tracking testing, currently my kernel version is 4.1.0-2-amd64. I have a nifty ACER c720 working almost perfectly, except for the trackpad, which dmidecode thinks is: Handle 0x0007, DMI type 41, 11 bytes Onboard Device Reference Designation: trackpad Type: Other Status: Enabled Type Instance: 37 Bus Address: 0001:67:00.0 There are quite a few references on the web that this device is working on linux, albeit for earlier kernel versions. Those references say that one should arrange to load the 'cyapa' module. The current kernel's modules include only a module 'cyapatp'. This does not detect the c720 trackpad. Where should I go to figure out what to do? Thanks, Russell
audacity startup fails stretch amd64
Hi, I am trying to launch audacity on a stretch amd64 system, and the following happens: 1. I get a popup with text "Audacity could not find a place to store temporary files. Please enter an appropriate directory in the preferences dialog." Click ok, then: 2. An error popup appears stating: "AudioIO.cpp(2363): assert "false" failed in getPlayDevIndex()." A backtrace is available but doesn't reveal anything obvious to me. Click continue, then: 3. An error popup appears stating: "AudioIO.cpp(2416): assert "false" failed in getRecordDevIndex()." Continue then segfaults. The googleman doesn't provide any clues. Ideas? Many thanks, Russell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557b79d3.5030...@pinyon.org
Re: audacity startup fails stretch amd64
Hi! On 06/12/15 19:29, Ric Moore wrote: On 06/12/2015 08:31 PM, Russell L. Carter wrote: Hi, I am trying to launch audacity on a stretch amd64 system, and the following happens: 1. I get a popup with text "Audacity could not find a place to store temporary files. Please enter an appropriate directory in the preferences dialog." Click ok, then: 2. An error popup appears stating: "AudioIO.cpp(2363): assert "false" failed in getPlayDevIndex()." A backtrace is available but doesn't reveal anything obvious to me. Click continue, then: 3. An error popup appears stating: "AudioIO.cpp(2416): assert "false" failed in getRecordDevIndex()." Continue then segfaults. The googleman doesn't provide any clues. Ideas? You made me go and look. Audacity launches just fine running stretch amd64. Are you joined to the audio group? Ric This is an agressively cut down system w/o gnome, kde, etc. Just wdm and fvwm. I have pulse installed and it is running. So I am missing an early dependency somewhere. I wonder what that could be? Thanks, Russell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557bb45e.2060...@pinyon.org
Re: audacity startup fails stretch amd64
On 06/13/15 01:30, Lisi Reisz wrote: On Saturday 13 June 2015 05:41:02 Russell L. Carter wrote: Hi! On 06/12/15 19:29, Ric Moore wrote: On 06/12/2015 08:31 PM, Russell L. Carter wrote: Hi, I am trying to launch audacity on a stretch amd64 system, and the following happens: 1. I get a popup with text "Audacity could not find a place to store temporary files. Please enter an appropriate directory in the preferences dialog." Click ok, then: 2. An error popup appears stating: "AudioIO.cpp(2363): assert "false" failed in getPlayDevIndex()." A backtrace is available but doesn't reveal anything obvious to me. Click continue, then: 3. An error popup appears stating: "AudioIO.cpp(2416): assert "false" failed in getRecordDevIndex()." Continue then segfaults. The googleman doesn't provide any clues. Ideas? You made me go and look. Audacity launches just fine running stretch amd64. Are you joined to the audio group? Ric This is an agressively cut down system w/o gnome, kde, etc. Just wdm and fvwm. I have pulse installed and it is running. So I am missing an early dependency somewhere. I wonder what that could be? As a start, have you run #aptitude show audacity to see what the initial situation is? No problems, apparently: rcarter@sturio> aptitude show audacity Package: audacity State: installed Automatically installed: no Version: 2.0.6-2 Priority: optional Section: sound Maintainer: Debian Multimedia Maintainers Architecture: amd64 Uncompressed Size: 9,997 k Depends: audacity-data (= 2.0.6-2), libasound2 (>= 1.0.16), libavcodec56 (>= 6:11~beta1) | libavcodec-extra-56 (>= 6:11), libavformat56 (>= 6:11~beta1), libavutil54 (>= 6:11~beta1), libc6 (>= 2.15), libexpat1 (>= 2.0.1), libflac++6 (>= 1.3.0), libflac8 (>= 1.3.0), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= 2.12.0), libid3tag0 (>= 0.15.1b), libmad0 (>= 0.15.1b-3), libmp3lame0, libogg0 (>= 1.0rc3), libportaudio2 (>= 19+svn20101113-2~), libportsmf0, libsbsms10, libsndfile1 (>= 1.0.20), libsoundtouch0 (>= 1.8.0), libsoxr0 (>= 0.1.0), libstdc++6 (>= 4.9), libtwolame0, libvamp-hostsdk3, libvorbis0a (>= 1.1.2), libvorbisenc2 (>= 1.1.2), libvorbisfile3 (>= 1.1.2), libwxbase3.0-0 (>= 3.0.2), libwxgtk3.0-0 (>= 3.0.2) Suggests: ladspa-plugin Description: fast, cross-platform audio editor Audacity is a multi-track audio editor for Linux/Unix, MacOS and Windows. It is designed for easy recording, playing and editing of digital audio. Audacity features digital effects and spectrum analysis tools. Editing is very fast and provides unlimited undo/redo. Supported file formats include Ogg Vorbis, MP2, MP3, WAV, AIFF, and AU. Homepage: http://audacity.sourceforge.net/ Tags: field::arts, interface::x11, role::program, scope::application, sound::mixer, sound::recorder, uitoolkit::wxwidgets, use::editing, use::learning, works-with::audio, x11::application Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557c4dcf.30...@pinyon.org
Re: audacity startup fails stretch amd64
On 06/13/15 10:36, Sven Arvidsson wrote: On Fri, 2015-06-12 at 17:31 -0700, Russell L. Carter wrote: Hi, I am trying to launch audacity on a stretch amd64 system, and the following happens: 1. I get a popup with text "Audacity could not find a place to store temporary files. Please enter an appropriate directory in the preferences dialog." Click ok, then: 2. An error popup appears stating: "AudioIO.cpp(2363): assert "false" failed in getPlayDevIndex()." A backtrace is available but doesn't reveal anything obvious to me. Click continue, then: 3. An error popup appears stating: "AudioIO.cpp(2416): assert "false" failed in getRecordDevIndex()." Continue then segfaults. Check grep -i Temp ~/.audacity-data/audacity.cfg And then check the permissions on that directory. Bingo! I had changed the uid for my account a while back and didn't think to have a look at /var/tmp. Now at least the situation is documented so that it can be found by google and friends. Thanks Sven! Russell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557c7332.5090...@pinyon.org
debian zfs spl dkms build fails
This has been happening for over 2 weeks now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877694 It has such cheerful effects as: root@knuth> zpool status The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. The symptom displays via several ways like this: -- Deleting module version: 0.6.5.11 completely from the DKMS tree. -- Done. Unpacking zfs-dkms (0.6.5.11-1) over (0.6.5.11-1) ... Setting up zfs-dkms (0.6.5.11-1) ... Loading new zfs-0.6.5.11 DKMS files... Building for 4.13.0-1-amd64 Building initial module for 4.13.0-1-amd64 configure: error: *** Please make sure the kmod spl devel package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 4.13.0-1-amd64 (x86_64) Consult /var/lib/dkms/zfs/0.6.5.11/build/make.log for more information. So what are we supposed to do? The system is up, network accessible, and I'm pulling a current in time backup. Is there a linux distro that isn't broken for zfsonlinux distro kernel updates? Otherwise a complete reinstall back to the dumb world of ext4, as I need a metal 8 core box for comparative testing. Thanks, Russell
Re: debian zfs spl dkms build fails
Greetings. Your reply is completely nonresponsive to the zfs kernel upgrade situation as it is today on debian. Why did you bother? It's weird. I don't actually care very much. I'm going to go back to dumb extfs if required. I'm just fishing for some sanity here. Thanks, Russell On 10/25/17 21:18, David Christensen wrote: On 10/25/17 19:42, Russell L. Carter wrote: This has been happening for over 2 weeks now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877694 It has such cheerful effects as: root@knuth> zpool status The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. The symptom displays via several ways like this: -- Deleting module version: 0.6.5.11 completely from the DKMS tree. -- Done. Unpacking zfs-dkms (0.6.5.11-1) over (0.6.5.11-1) ... Setting up zfs-dkms (0.6.5.11-1) ... Loading new zfs-0.6.5.11 DKMS files... Building for 4.13.0-1-amd64 Building initial module for 4.13.0-1-amd64 configure: error: *** Please make sure the kmod spl devel package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 4.13.0-1-amd64 (x86_64) Consult /var/lib/dkms/zfs/0.6.5.11/build/make.log for more information. So what are we supposed to do? The system is up, network accessible, and I'm pulling a current in time backup. Is there a linux distro that isn't broken for zfsonlinux distro kernel updates? Otherwise a complete reinstall back to the dumb world of ext4, as I need a metal 8 core box for comparative testing. If you want to debug ZOL and/or Linux, then build from source. If you want to use ZOL on Debian, use a supported Debian version and supported ZOL binary packages: https://github.com/zfsonlinux/zfs/wiki/Debian Installation For Debian Stretch, ZFS packages are included in contrib repository. For Debian Jessie, ZFS packages are provided by backports. Install kernel headers: # apt install linux-headers-$(uname -r) Install zfs packages: # apt-get install zfs-dkms If you want to boot from ZFS, you'll need zfs-initramfs package too: # apt-get install zfs-initramfs David
Re: debian zfs spl dkms build fails
On 10/25/17 22:19, David Christensen wrote: On 10/25/17 21:23, Russell L. Carter wrote: Greetings. Your reply is completely nonresponsive to the zfs kernel upgrade situation as it is today on debian. Why did you bother? It's weird. I don't actually care very much. I'm going to go back to dumb extfs if required. I'm just fishing for some sanity here. Please don't top post. I bothered because the last time I tried ZOL (Debian 6?), the only option was to download the source from LLNL and build it. Now there are official Debian binary packages available. Thank you for providing the stimulus for me to discover that fact. :-) It appears that you are attempting to build the "testing" version of ZFS: https://packages.debian.org/buster/zfs-dkms Yet, you expect the reliability of "stable". Make sure you understand the three releases of Debian: https://www.debian.org/releases/ If you want stability, run "stable". If you have the skills and interest to help fix bugs, then run "testing" or "unstable". I've been running debian 'testing' for 18 years now. I've been running zfs on other OS's for 5 years now, some quite large. Those other OSs include some I've been running for over 20 years. It should be inferred that I've watched a lot of technology get integrated over that time. Note that my complaint here is that the upgrade process that I've done literally 1000s of times over that 18 years is now allowed to not only break the *upgrade* process through broken kernel modules, it has the added benefit of breaking *existing* working configurations. That's quite a packaging accomplishment, for 2017. I take your commentary as confirmation on what I suspected. Ideology somehow has broken the technology integration process. Oh well. Out. And out of using debian for a real OS. But for 'testing' hey, it's just great. I've got my full backup and now I'm going to make this a stupid box. Russell David
3w-9xxx performance bug in kernel 3.1.0-amd64
Hi, I've got a testing amd64 system with two 3Ware 9500S controllers and performance with the newest kernel is dramatically slower than with 2.6.32-5-amd64. Also response to tw_cli and 3dm2 is glacial. Possibly an IRQ issue? Anyway my question is what list is best to ask about this problem. Or should I just go ahead and file a bug report (my first)? Bonnie++ output appended. Thanks, Russell ** Linux berlin 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011 x86_64 GNU/Linux rcarter@berlin> /usr/sbin/bonnie++ -d /d1/tmp Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP berlin 16G 376 98 84523 15 36035 6 1808 97 223527 20 206.4 1 Latency 21484us 230ms 354ms 19199us 65485us 824ms Version 1.96 --Sequential Create-- Random Create berlin -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 20902 61 + +++ 25927 54 25286 62 + +++ 28831 57 Latency 296us 663us1672us 177us 30us 52us 1.96,1.96,berlin,1,1322808950,16G,,376,98,84523,15,36035,6,1808,97,223527,20,206.4,1,16,20902,61,+,+++,25927,54,25286,62,+,+++,28831,57,21484us,230ms,354ms,19199us,65485us,824ms,296us,663us,1672us,177us,30us,52us rcarter@berlin> ** Linux berlin 3.1.0-1-amd64 #1 SMP Mon Nov 14 08:02:25 UTC 2011 x86_64 rcarter@berlin> /usr/sbin/bonnie++ -d /d1/tmp Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP berlin 16G 495 89 27134 4 1422 0 1443 58 3251 0 77.9 0 Latency 15666us 923ms1610ms 96817us 459ms1200ms Version 1.96 --Sequential Create-- Random Create berlin -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 9623 19 + +++ 19726 33 14990 29 + +++ 19520 26 Latency 40757us 587us1405us 416us 16us 966us 1.96,1.96,berlin,1,1322795929,16G,,495,89,27134,4,1422,0,1443,58,3251,0,77.9,0,16,9623,19,+,+++,19726,33,14990,29,+,+++,19520,26,15666us,923ms,1610ms,96817us,459ms,1200ms,40757us,587us,1405us,416us,16us,966us rcarter@berlin> -- 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/4ed8f3ec.5010...@pinyon.org
NVIDIA cards stopped working with recent testing updates
Hi, I have a system with a fixed hardware config over the last two years that I have kept current with testing through that time. Yesterday's update/dist-upgrade/reboot results in a blank screen when launching X. I swapped out the GTX285 for a GT520 and got identical results. I tried a different PCI-E slot with the same results. I switched to the nouveau drivers and get nearly the same behavior, except for a blinking cursor in the upper left corner of the screen. In each case, I can't switch to text consoles via Ctl+Alt+F1...F6. If I remove all the graphics drivers I get a successful reboot to text console prompt. I also downloaded an older known working nvidia distribution from nvidia and built and installed that, with identical results to the current dkms package. All of these diagnostics were performed with the current 2.6.38-2-amd64 kernel. I then repeated the nvidia driver installation with a stable 2.6.32-5-amd64 kernel and got the same results (GTSR). I uninstalled all my kvm adn verde modules and GTSR. I swapped monitors and GTSR. Took a shower and GTSR. I'd be very happy to hear about any potential solutions to this situation. Thanks, Russell -- 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/4dcef2c7.8080...@pinyon.org
Re: NVIDIA cards stopped working with recent testing updates
On 05/14/2011 04:56 PM, Stephen Powell wrote: > On Sat, 14 May 2011 17:23:19 -0400 (EDT), Russell L. Carter wrote: >> >> I have a system with a fixed hardware config over the last two >> years that I have kept current with testing through that time. >> Yesterday's update/dist-upgrade/reboot results in a blank >> screen when launching X. >> ... > > You aren't using interlaced video modes, are you? Interlaced > video modes don't seem to work at all with any KMS-based > driver. That's why I use nv. (The proprietary nvidia driver > for my chipset no longer works with recent X servers.) > I had to download the source for nv and compile it myself, though, > since nv has been removed from the distribution and the old > binary version doesn't work with the new X server. > I don't believe so, I run the GTX285 normally at 1920x1200 on a benq LCD. I just bought the GT520 today, it's a just released GPU, so nothing legacy here. Per the apt-listchanges notes I tried $ echo "/usr/lib/libc/memcpy-preload.so" > /etc/ld.so.preload and reboot but no joy. Thanks, Russell -- 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/4dcf1c98.3030...@pinyon.org
Re: NVIDIA cards stopped working with recent testing updates
Hi Curt, On 05/14/2011 07:00 PM, Curt Howland wrote: > I've found that I have to re-install the binary Nvidia driver often > after updates, when the X system gets updated, due to changes to > simlinks. > > If you're using the Nvidia binary driver, try reinstalling it. I did that. I reinstalled (apt-get install) after deinstalling (apt-get autoremove --purge) for each step that I listed in my original message. And then, for good measure, I downloaded an older (1 yo) nvidia release from their website and built it myself and then installed that. And then I reinstalled a 2.6.32-5 kernel and repeated all the install/uninstall steps. This took a bit of time... Thanks, Russell > > Curt- > > -- 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/4dcf3c20.8030...@pinyon.org
[some progress] Re: NVIDIA cards stopped working with recent testing updates
First, thanks much to the people on the other side of the globe who see a new day before me. I have dug deeper and can now get more specific about the nvidia blank screen problem. (For the record, I have a fixed hardware config that I've tracked debian-testing on for two years, and also tracking nvidia drivers. I used to just download them from nvidia.com but for the past few months I've been using dkms, which has worked beautifully.) Thanks to tv.debian for reminding me that nouveau might be blacklisted. It turns out that it was, in the file /etc/modprobe.d/nvidia-installer-disable-nouveau.conf I had the nouveau packages installed: root@feyerabend:/etc/modprobe.d# dpkg -l | grep nouveau ii libdrm-nouveau1a2.4.24-2 Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1 X.Org X server -- Nouveau display driver (experimental) so when I rm'd the blacklist file the gdm3 greeter popped up and X is up and running. This proves the hardware is working (or at least not completely broken). I don't have the ability to make a choice between nvidia vs. nouveau, I make a living with high performance numerical algorithms, including GPU programming, so my only choice is between Linux and Windows. Ok? I would be a very unhappy man on Windows, so I'll forge on. So next I install the current nvidia dkms packages. I've removed everything that's normal output: root@feyerabend:~# apt-get autoremove --purge xserver-xorg-video-nouveau libdrm-nouveau1a since the nouveau module is still loaded I reboot, and return to a console prompt with no X. Next I'll install the nvidia packages. Note that the modprobe blows up. After the apt-get install output I'll append the traceback the showed up in /var/log/messages. (The recent memcpy/memmove issue is orthogonal to kernel modules, right?) root@feyerabend:~# apt-get install nvidia-kernel-dkms nvidia-glx nvidia-kernel-270.41.06 nvidia-settings Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'nvidia-kernel-dkms' instead of 'nvidia-kernel-270.41.06' The following NEW packages will be installed: nvidia-glx nvidia-kernel-dkms nvidia-settings 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/12.8 MB of archives. After this operation, 41.2 MB of additional disk space will be used. Selecting previously deselected package nvidia-kernel-dkms. (Reading database ... 204047 files and directories currently installed.) Unpacking nvidia-kernel-dkms (from .../nvidia-kernel-dkms_270.41.06-1_amd64.deb) ... Selecting previously deselected package nvidia-glx. Unpacking nvidia-glx (from .../nvidia-glx_270.41.06-1_amd64.deb) ... Selecting previously deselected package nvidia-settings. Unpacking nvidia-settings (from .../nvidia-settings_195.36.24-1_amd64.deb) ... Processing triggers for man-db ... Processing triggers for menu ... Setting up nvidia-kernel-dkms (270.41.06-1) ... Loading new nvidia-270.41.06 DKMS files... First Installation: checking all kernels... Building only for 2.6.38-2-amd64 Building initial module for 2.6.38-2-amd64 Done. nvidia.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/2.6.38-2-amd64/updates/dkms/ depmod... Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226221] Oops: [#1] SMP Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226223] last sysfs file: /sys/bus/acpi/drivers/NVIDIA ACPI Video Driver/uevent Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226406] Stack: Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226416] Call Trace: Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226841] Code: 00 ba 00 00 00 00 be 3c 00 00 00 41 ff 55 20 48 89 c3 b9 01 00 00 00 ba 00 00 00 00 be 15 00 00 00 4c 89 ef 41 ff 55 20 49 89 c6 <48> 8b 05 f7 6a c6 00 48 89 45 10 8b 05 f5 6a c6 00 89 45 18 0f Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226980] CR2: a129b076 Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226221] Oops: [#1] SMP Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226223] last sysfs file: /sys/bus/acpi/drivers/NVIDIA ACPI Video Driver/uevent Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226406] Stack: Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226416] Call Trace: Message from syslogd@feyerabend at May 15 11:35:38 ... kernel:[ 177.226841] Code: 00 ba 00 00 00 00 be 3c 00 00 00 41 ff 55 20 48 89 c3 b9 01 00 00 00 ba 00 00 00 00 be 15 00 00 00 4c 89 ef 41 ff 55 20 49 89 c6 <48> 8b 05 f7 6a c6 00 48 89 45 10 8b 05 f5 6a c6 00 89 45 18 0f Message from syslogd@feyerabend at May 15 11:35:38 ..
Re: [some progress] Re: NVIDIA cards stopped working with recent testing updates
I left out the step of replacing Driver="nouveau" with Driver="nvidia" in /etc/X11/xorg.conf, sorry. On 05/15/2011 11:52 AM, Russell L. Carter wrote: > > First, thanks much to the people on the other side of the globe who > see a new day before me. I have dug deeper and can now get more specific > about the nvidia blank screen problem. (For the record, I have a > fixed hardware config that I've tracked debian-testing on for two > years, and also tracking nvidia drivers. I used to just download > them from nvidia.com but for the past few months I've been using > dkms, which has worked beautifully.) > > Thanks to tv.debian for reminding me that nouveau might be > blacklisted. It turns out that it was, in the file > > /etc/modprobe.d/nvidia-installer-disable-nouveau.conf > > I had the nouveau packages installed: > > root@feyerabend:/etc/modprobe.d# dpkg -l | grep nouveau > ii libdrm-nouveau1a2.4.24-2 > Userspace > interface to nouveau-specific kernel DRM services -- runtime > ii xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1 X.Org X > server -- Nouveau display driver (experimental) > > so when I rm'd the blacklist file the gdm3 greeter popped up and X is > up and running. This proves the hardware is working (or at least not > completely broken). > > I don't have the ability to make a choice between nvidia vs. nouveau, I > make a living with high performance numerical algorithms, including GPU > programming, so my only choice is between Linux and Windows. Ok? > I would be a very unhappy man on Windows, so I'll forge on. > > So next I install the current nvidia dkms packages. I've removed > everything that's normal output: > > root@feyerabend:~# apt-get autoremove --purge xserver-xorg-video-nouveau > libdrm-nouveau1a > > since the nouveau module is still loaded I reboot, and return to a > console prompt with no X. Next I'll install the nvidia packages. > Note that the modprobe blows up. After the apt-get install output > I'll append the traceback the showed up in /var/log/messages. > > (The recent memcpy/memmove issue is orthogonal to kernel modules, > right?) > > root@feyerabend:~# apt-get install nvidia-kernel-dkms nvidia-glx > nvidia-kernel-270.41.06 nvidia-settings > Reading package lists... Done > Building dependency tree > Reading state information... Done > Note, selecting 'nvidia-kernel-dkms' instead of 'nvidia-kernel-270.41.06' > The following NEW packages will be installed: > nvidia-glx nvidia-kernel-dkms nvidia-settings > 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B/12.8 MB of archives. > After this operation, 41.2 MB of additional disk space will be used. > Selecting previously deselected package nvidia-kernel-dkms. > (Reading database ... 204047 files and directories currently installed.) > Unpacking nvidia-kernel-dkms (from > .../nvidia-kernel-dkms_270.41.06-1_amd64.deb) ... > Selecting previously deselected package nvidia-glx. > Unpacking nvidia-glx (from .../nvidia-glx_270.41.06-1_amd64.deb) ... > Selecting previously deselected package nvidia-settings. > Unpacking nvidia-settings (from .../nvidia-settings_195.36.24-1_amd64.deb) ... > Processing triggers for man-db ... > Processing triggers for menu ... > Setting up nvidia-kernel-dkms (270.41.06-1) ... > Loading new nvidia-270.41.06 DKMS files... > First Installation: checking all kernels... > Building only for 2.6.38-2-amd64 > Building initial module for 2.6.38-2-amd64 > Done. > > nvidia.ko: > Running module version sanity check. > - Original module >- No original module exists within this kernel > - Installation >- Installing to /lib/modules/2.6.38-2-amd64/updates/dkms/ > > depmod... > Message from syslogd@feyerabend at May 15 11:35:38 ... > kernel:[ 177.226221] Oops: [#1] SMP > > Message from syslogd@feyerabend at May 15 11:35:38 ... > kernel:[ 177.226223] last sysfs file: /sys/bus/acpi/drivers/NVIDIA ACPI > Video > Driver/uevent > > Message from syslogd@feyerabend at May 15 11:35:38 ... > kernel:[ 177.226406] Stack: > > Message from syslogd@feyerabend at May 15 11:35:38 ... > kernel:[ 177.226416] Call Trace: > > Message from syslogd@feyerabend at May 15 11:35:38 ... > kernel:[ 177.226841] Code: 00 ba 00 00 00 00 be 3c 00 00 00 41 ff 55 20 48 > 89 > c3 b9 01 00 00 00 ba 00 00 00 00 be 15 00 00 00 4c 89 ef 41 ff 55 20 49 89 c6 > <48> 8b 05 f7 6a c6 00 48 89 45 10 8b 05 f5 6a c6 00 89 45 18 0f > > Message from syslogd@feyerabend at May 15 11:35:38 ... > kernel:[ 177.226980] CR2:
Re: [some progress] Re: NVIDIA cards stopped working with recent testing updates
On 05/15/2011 12:17 PM, Andrei Popescu wrote: > On Du, 15 mai 11, 11:56:18, Russell L. Carter wrote: >> I left out the step of replacing Driver="nouveau" with Driver="nvidia" >> in /etc/X11/xorg.conf, sorry. > > Does this mean that everything is ok now? Ah, sorry, no, I left out the step of switching from nouveau to nvidia in xorg.conf from my description, I did do it correctly when I switched. (I was hoping not to derail the focus, but I guess I did anyway). So current status is the current testing nvidia-kernel-dkms breaks at the depmod step. Thanks, Russell > > Regards, > Andrei -- 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/4dd03278.3000...@pinyon.org
Re: [some progress] Re: NVIDIA cards stopped working with recent testing updates
On 05/16/2011 01:57 PM, tv.deb...@googlemail.com wrote: >> 15/05/2011 20:52, Russell L. Carter wrote: >> [...] >> > > Do you have the logs from the upgrade right before the crash, what > packages got upgraded ? > In between your different trials you cleaned up thoroughly ? I am > thinking Nvidia .run here. Not now... I reinstalled from scratch and after spending a few hours learning the ins and outs of the udev bug (fix by rm -f /run, hmm) I have a brand spanking new installation running nvidia-kernel-dkms successfully. I didn't know about "Nvidia .run", I will certainly look closer at this possibility if I have problems in the future. > I see new nvidia packages entered Sid, one is "nvidia-installer-cleanup" > which may find some residual components of a previous install, it's > worth a shot if you are still stuck with this problem. Thanks for the info, I appreciate the help. Regards, Russell -- 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/4dd19f3b.8060...@pinyon.org
recent iceweasel desktop switching problem
Hi Folks, First, I'm not sure I have the diagnosis right so if my description is wrong I would appreciate tips on how to improve it. I'm on testing (wheezy) and I'm using fvwm, as I always have for the last 20 years (not sure I should admit that). Comparing 5 browsers: stock testing: iceweasel 3.5.19-3 squeeze backports: iceweasel release squeeze backports: iceweasel beta squeeze backports: iceweasel alpha stock testing: chromium 12.0.742.112~r90304-1 The problem is that when using the squeeze backports iceweasel versions, when I click on a URL with mouse-2, it switches me to the fvwm desktop directly below the active desktop, instead of opening a new tab with the URL. both stock testing iceweasel and chromium work fine, as they always have. First, am I asking the right question? Is this possibly a change in X mouse bindings? If it is the right question, how do I teach the squeeze backports iceweasel versions to do the right thing on mouse 2 on a URL (open a new tab with the URL contents). Thanks, Russell -- 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/4e381008.5060...@pinyon.org
Re: recent iceweasel desktop switching problem
On 08/02/2011 07:56 AM, Russell L. Carter wrote: > Hi Folks, [...] > The problem is that when using the squeeze backports iceweasel versions, > when I click on a URL with mouse-2, it switches me to the fvwm desktop > directly below the active desktop, instead of opening a new tab with > the URL. both stock testing iceweasel and chromium work fine, as they > always have. [...] Hmm, after dist-upgrading from last night's update, which brought down a new set of nvidia packages, the problem is gone. So it seems to have been an X related issue. > Thanks, > Russell > > -- 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/4e382236.3070...@pinyon.org
