Re: Help w Claws mail (pop) I don't want to download my entire yahoo message box!
On Sun, 17 Feb 2013 17:21:02 -0700 B G wrote: > I am trying to set up claws mail to access my yahoo email account > using pop. I would only like to download messages from the last day > or so. My yahoo account has emails going back 7 or so years. Is there > a way to tell Claws mail client to only download the last 100 > messages? Right now it is grabbing the first of more than 19000 > messages. > > Details- Debian Wheezy XFCE desktop with claws-mail package. > > Thanks in advance. > > It's nothing to do with Claws or Debian. This is what POP3 is designed to do, to transfer the entire mailbox content to the local workstation. If you want to leave mail on the server, use IMAP for access instead, I'm sure Yahoo offers that and I know Claws does it. -- Joe -- 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/20130218083916.6f7e3...@jretrading.com
Recent hypervisor update on Debian Wheezy breaks domU networking
Hi, Firstly I apologise for the cross-post, however I don't expect to get as quick a response from the package maintainers as I do from the Debian community, and this issue affects a service that I've got scheduled to go live at midnight this evening. :( A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to version 4.1.3-8 on Debian Wheezy has caused all vm's on this host to not receive their arp replies anymore and as such they cannot reach their gateways and are now isolated from the network. There was a more recent update as well (4.1.4-2) which I have now since applied however this particular issue persists. The arp replies are received by the host and passed all the way up to the bridge (br200) being used by Xen, however they are not seen on the vif (vif2.0) created for the particular vm. If I statically add the arp entry to the vm all starts working, ie: vm is no longer isolated and is now connected to the world, but we all know that this is not an ideal workaround. This was working perfectly before this update. :( 1) Please let me know if I should roll-back this particular xen update, kernel and all, and what those steps may be, or if this is a known issue with a particular workaround that I can apply. 2) Would moving to openvswitch be another possible workaround? My config:- Bonded ethernet connected to trunks on Cisco 3750 stack with connection as follows:- eth0 --> bond0 eth1 --> bond0 --> br200 --> vif2.0 /etc/network/interfaces:- iface bond0 inet manual slaves eth0 eth1 bond_mode 5 bond-miimon 100 bond-downdelay 200 bond-updelay 200 auto br200 iface br200 inet static address 172.31.1.66 gateway 172.31.1.65 netmask 255.255.255.240 bridge_ports bond0 bridge_maxwait 0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off root@scjhb01:/home/gavin# brctl show bridge name bridge id STP enabled interfaces br200 8000.d4bed9f309a1 no bond0 vif2.0 root@scjhb01:/home/gavin# tcpdump -i bond0 'arp' tcpdump: WARNING: bond0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes 11:26:00.287489 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:00.287524 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:00.287669 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui Unknown), length 46 11:26:01.303484 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:01.303518 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:01.303674 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui Unknown), length 46 11:26:02.303484 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:02.303518 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:02.303579 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui Unknown), length 46 root@scjhb01:/home/gavin# tcpdump -i br200 'arp' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br200, link-type EN10MB (Ethernet), capture size 65535 bytes 11:26:15.367489 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:15.367514 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:15.367580 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui Unknown), length 46 11:26:16.383476 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:16.383511 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:16.383592 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui Unknown), length 46 11:26:17.383486 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:17.383520 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:17.383616 ARP, Reply 172.31.1.49 is-at 00:09:0f:09:21:0e (oui Unknown), length 46 root@scjhb01:/home/gavin# tcpdump -i vif2.0 'arp' tcpdump: WARNING: vif2.0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vif2.0, link-type EN10MB (Ethernet), capture size 65535 bytes 11:26:31.463481 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:31.463521 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:32.463480 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:32.463521 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:33.463477 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:33.463515 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:34.479482 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:34.479523 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 11:26:35.479478 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 28 11:26:35.479515 ARP, Request who-has 172.31.1.49 tell 172.31.1.50, length 46 Thanks and Regards. Gavin
Re: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On Mon, 2013-02-18 at 12:04 +0200, Gavin wrote: > Firstly I apologise for the cross-post, I've added xen-users since you also bounced this there. > however I don't expect to get as quick a response from the package > maintainers as I do from the Debian community, and this issue affects > a service that I've got scheduled to go live at midnight this > evening. :( > > > A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to > version 4.1.3-8 on Debian Wheezy has caused all vm's on this host to > not receive their arp replies anymore and as such they cannot reach > their gateways and are now isolated from the network. > > > There was a more recent update as well (4.1.4-2) which I have now > since applied however this particular issue persists. Networking level stuff is all done by the dom0 (or driver domain) kernel rather than the hypervisor so it is far more likely that a kernel level change rather than a hypervisor change would be responsible. What kernel version are you running? Did it also change? > The arp replies are received by the host and passed all the way up to > the bridge (br200) being used by Xen, however they are not seen on the > vif (vif2.0) created for the particular vm. Do you have any firewall or ebfilter entries which might have either been discarded or reintroduced by the reboot? (i.e. a manual settings modification which wasn't propagated to the startup scripts). Or perhaps sysctl tweaks? > 1) Please let me know if I should roll-back this particular xen > update, kernel and all, and what those steps may be, or if this is a > known issue with a particular workaround that I can apply. I'd certainly be tempted to try the older kernel, assuming that was also upgraded. It may even still be installed and in your grub menu already. > 2) Would moving to openvswitch be another possible workaround? Without knowing what the underlying issue is it is hard to predict whether it will also affect ovs. > My config:- Looks correct to me. Ian. -- 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/1361184601.31407.144.ca...@zakaz.uk.xensource.com
Re: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On 18 February 2013 12:50, Ian Campbell wrote: > On Mon, 2013-02-18 at 12:04 +0200, Gavin wrote: > > > > Firstly I apologise for the cross-post, > > I've added xen-users since you also bounced this there. > Thanks. :-/ Thanks too for your quick reply. > > > however I don't expect to get as quick a response from the package > > maintainers as I do from the Debian community, and this issue affects > > a service that I've got scheduled to go live at midnight this > > evening. :( > > > > > > A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to > > version 4.1.3-8 on Debian Wheezy has caused all vm's on this host to > > not receive their arp replies anymore and as such they cannot reach > > their gateways and are now isolated from the network. > > > > > > There was a more recent update as well (4.1.4-2) which I have now > > since applied however this particular issue persists. > > Networking level stuff is all done by the dom0 (or driver domain) kernel > rather than the hypervisor so it is far more likely that a kernel level > change rather than a hypervisor change would be responsible. What kernel > version are you running? Did it also change? > This makes sense, although when I did the apt-get upgrade, there was no kernel update, however there may have been packages/drivers that required a kernel mod. Here is the apt history which details what was upgraded when this broke:- Upgrade: dnsmasq-base:amd64 (2.62-3, 2.62-3+deb7u1), tasksel-data:amd64 (3.14, 3.14+nmu1), xen-hypervisor-4.1-amd64:amd64 (4.1.3-7, 4.1.3-8), xen-utils-common:amd64 (4.1.3-7, 4.1.3-8), perl:amd64 (5.14.2-16, 5.14.2-17), firmware-linux-free:amd64 (3.1, 3.2), perl-base:amd64 (5.14.2-16, 5.14.2-17), xen-utils-4.1:amd64 (4.1.3-7, 4.1.3-8), libgnutls26:amd64 (2.12.20-2, 2.12.20-4), perl-modules:amd64 (5.14.2-16, 5.14.2-17), psmisc:amd64 (22.19-1, 22.19-1+deb7u1), python2.6:amd64 (2.6.8-0.2, 2.6.8-1.1), libxenstore3.0:amd64 (4.1.3-7, 4.1.3-8), python2.6-minimal:amd64 (2.6.8-0.2, 2.6.8-1.1), coreutils:amd64 (8.13-3.4, 8.13-3.5), libvirt0:amd64 (0.9.12-5, 0.9.12-6), libcurl3:amd64 (7.26.0-1, 7.26.0-1+wheezy1), manpages:amd64 (3.42-1, 3.44-1), tasksel:amd64 (3.14, 3.14+nmu1), libperl5.14:amd64 (5.14.2-16, 5.14.2-17), libsystemd-login0:amd64 (44-7, 44-8), libxen-4.1:amd64 (4.1.3-7, 4.1.3-8), libcurl3-gnutls:amd64 (7.26.0-1, 7.26.0-1+wheezy1), host:amd64 (9.8.4.dfsg.P1-1, 9.8.4.dfsg.P1-4), libvirt-bin:amd64 (0.9.12-5, 0.9.12-6), rinse:amd64 (2.0-1, 2.0.1-1), ca-certificates:amd64 (20120623, 20130119), xenstore-utils:amd64 (4.1.3-7, 4.1.3-8) The kernel I am using is: 3.2.0-2-amd64, also tried 3.2.0-4-amd64 on another host with no success. Would the upgrade above of xen-hypervisor-4.1-amd64 on this Debian system not cause the Dom0 kernel to be changed in any way ?? > > The arp replies are received by the host and passed all the way up to > > the bridge (br200) being used by Xen, however they are not seen on the > > vif (vif2.0) created for the particular vm. > > Do you have any firewall or ebfilter entries which might have either > been discarded or reintroduced by the reboot? (i.e. a manual settings > modification which wasn't propagated to the startup scripts). Or perhaps > sysctl tweaks? > Nope, not using iptables/ebtables, this was working 100% until the apt upgrade above. After this broke I did try and add the following to /etc/sysctl.conf but it made no difference:- net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 It did add iptables rules but made no difference to this issue. > > > 1) Please let me know if I should roll-back this particular xen > > update, kernel and all, and what those steps may be, or if this is a > > known issue with a particular workaround that I can apply. > > I'd certainly be tempted to try the older kernel, assuming that was also > upgraded. It may even still be installed and in your grub menu already. > The problem is now we are using grub2 and it appears that on boot grub loads a Linux menu, then the Xen Menu with configs in /etc/grub.d/ so I'm battling to figure out how to do this. I also do not have physical access to this host at the moment so need to set the boot order 'correctly' prior to a reboot. > > > 2) Would moving to openvswitch be another possible workaround? > > Without knowing what the underlying issue is it is hard to predict > whether it will also affect ovs. > Agreed. > > > My config:- > > Looks correct to me. > > Ian. > Thanks Ian.
Seeking advise on changing names of target in dm-crypt
Hi list, Recently I've added a couple of disks to a system. All these disks are encrypted using dm-crypt with the Luks extensions. The result is working just fine, but now I have the old target names the installer defined and the new ones I added. Normally no biggie, but the names the installer added have become confusing in the new setup, because the order of the disks has changed. This means I now have targets named like sdb1_crypt etc. that are no longer related to sdb at all. I am thinking of changing the names of the targets in crypttab and fstab. Are there other files I need to adjust? Any pitfalls I need to be aware of? I am thinking especially of the target that contains /. Thanks in advance for any advise! Grx HdV -- 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/51221728.9030...@gmail.com
Re: SSD Optimization in Wheezy
On Sun, Feb 17, 2013 at 04:08:58PM +, Hormatzhan Yiltiz wrote: >D >ear fellas, Fellas and Dames, please. If you wish to just address those on this list who identify as male, you should probably be aware that you may miss out on some sage advice. >Two issues here indicated from [1]wiki.debian.org/SSDOptimization. >One is about ramlog, another about asd. >1. I had 8G RAM x64 Debian testing on 120G SSD, and wanted to do some SSD >optimization, and I came across [2]http://www.tremende.com/ramlog/ from >Debian Recommendation [3]http://wiki.debian.org/SSDoptimization. >After >Downloading > [4]http://www.tremende.com/ramlog/download/ramlog_2.0.0_all.deb and >installing it according to the steps >in [5]http://www.tremende.com/ramlog/, I came up with a failed system >after the step 3: reboot! >It says the file system fails to blah-blah, and the ttyX can only get >access to a read-only file system. So I cannot even uninstall ramlog, >though I do not know whether simply uninstallation could help. >Please help me! I would much appreciate! I had crucial database in >the Linux box. Thanks! >Bu the way, it might be better to mark these issues in the wiki pages. As you can probably tell from the URL you downloaded that package from, that's not debian software. You'd probably be better talking to the software's author directly. >2. Why there is no anything-sync-daemon, goanysync or profile-sync-daemon >in Debian, even in Sid, when it is a recommended software in the Debian >wikipage!? Probably for the same reason that ramlog isn't in Debian. :) signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On 18 February 2013 13:40, Gavin wrote: > On 18 February 2013 12:50, Ian Campbell wrote: > >> >> Networking level stuff is all done by the dom0 (or driver domain) kernel >> rather than the hypervisor so it is far more likely that a kernel level >> change rather than a hypervisor change would be responsible. What kernel >> version are you running? Did it also change? >> > > This makes sense, although when I did the apt-get upgrade, there was no > kernel update, however there may have been packages/drivers that required a > kernel mod. > > Here is the apt history which details what was upgraded when this broke:- > > Upgrade: xen-hypervisor-4.1-amd64:amd64 (4.1.3-7, 4.1.3-8) > > The kernel I am using is: 3.2.0-2-amd64, also tried 3.2.0-4-amd64 on > another host with no success. > > Would the upgrade above of xen-hypervisor-4.1-amd64 on this Debian system > not cause the Dom0 kernel to be changed in any way ?? > >> >> > 1) Please let me know if I should roll-back this particular xen >> > update, kernel and all, and what those steps may be, or if this is a >> > known issue with a particular workaround that I can apply. >> >> I'd certainly be tempted to try the older kernel, assuming that was also >> upgraded. It may even still be installed and in your grub menu already. >> > > The problem is now we are using grub2 and it appears that on boot grub > loads a Linux menu, then the Xen Menu with configs in /etc/grub.d/ so I'm > battling to figure out how to do this. > > I also do not have physical access to this host at the moment so need to > set the boot order 'correctly' prior to a reboot. > I managed to get iDRAC console access and on further inspection it appears that grub first boots xen-4.1-amd64.gz and then the Linux kernel. When I updated the Xen Hypervisor does it not also upgrade the xen-4.1-amd64.gz file ?? Are there any better ways to trace where this arp reply is being lost apart from just tcpdump ? None of the log files are reporting back any errors and my googling just does not seem to return any useful results.
[1/2OT] bcm4331
Hi, A quick question, does the latest kernel support the bcm4331 wireless card? or does it still need compat-wireless and etc. Thanks with best 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/512235cb.6070...@gmail.com
Re: [1/2OT] bcm4331
On Monday 18,February,2013 10:08 PM, lina wrote: > Hi, > > A quick question, does the latest kernel support the bcm4331 wireless > card? or does it still need compat-wireless and etc. > > Thanks with best regards, > > Sorry, I planed to send to the linux-wirel...@vger.kernel.org. But, seems, default, I have this list, in my mind. Thanks, -- 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/51223760.2080...@gmail.com
Re: [1/2OT] bcm4331
Le Lun 18 février 2013 15:08, lina a écrit : > Hi, > > > A quick question, does the latest kernel support the bcm4331 wireless > card? or does it still need compat-wireless and etc. > > Thanks with best regards, I am not sure about what you are calling compat-wireless. My netbook have a wl card from that family, and run perfectly with current stable (last time I ran stable is at least 1 year ago, thought). The only issue is, that this firmware is in non-free. -- 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/983dcb9c79868db3ff81b6871ffe661f.squir...@www.sud-ouest.org
Re: [1/2OT] bcm4331
On Mon, Feb 18, 2013 at 10:08:11PM +0800, lina wrote: > Hi, > > A quick question, does the latest kernel support the bcm4331 wireless > card? or does it still need compat-wireless and etc. I don't know the answer to your question, but it'll help other people if you clarify what you mean by "the latest kernel". Do you mean: * The kernel currently in stable (2.6.32-5) * The kernel currently slated to be released in wheezy (3.2.0-4) * The latest kernel currently in sid (3.2.0-4) * The latest kernel currently in experimental (3.7-trunk) * The latest upstream/vanilla kernel (3.8-rc7) signature.asc Description: Digital signature
Re: [1/2OT] bcm4331
On Monday 18,February,2013 10:19 PM, Darac Marjal wrote: > On Mon, Feb 18, 2013 at 10:08:11PM +0800, lina wrote: >> Hi, >> >> A quick question, does the latest kernel support the bcm4331 >> wireless card? or does it still need compat-wireless and etc. > > I don't know the answer to your question, but it'll help other > people if you clarify what you mean by "the latest kernel". Do you > mean: > > * The kernel currently in stable (2.6.32-5) * The kernel currently > slated to be released in wheezy (3.2.0-4) * The latest kernel > currently in sid (3.2.0-4) * The latest kernel currently in > experimental (3.7-trunk) * The latest upstream/vanilla kernel > (3.8-rc7) > Currently I have downloaded the 3.7.9 from kernel.org. -- 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/5122392f.7020...@gmail.com
Re: [1/2OT] bcm4331
On Monday 18,February,2013 10:17 PM, "Morel Bérenger" wrote: > Le Lun 18 février 2013 15:08, lina a écrit : >> Hi, >> >> >> A quick question, does the latest kernel support the bcm4331 wireless >> card? or does it still need compat-wireless and etc. >> >> Thanks with best regards, > > I am not sure about what you are calling compat-wireless. My netbook have > a wl card from that family, and run perfectly with current stable (last > time I ran stable is at least 1 year ago, thought). > The only issue is, that this firmware is in non-free. > > The kernel I used is 3.3.5. which doesn't support the bcm4331. -- 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/51223968@gmail.com
Re: [1/2OT] bcm4331
On Monday 18,February,2013 10:17 PM, "Morel Bérenger" wrote: > Le Lun 18 février 2013 15:08, lina a écrit : >> Hi, >> >> >> A quick question, does the latest kernel support the bcm4331 wireless >> card? or does it still need compat-wireless and etc. >> >> Thanks with best regards, > > I am not sure about what you are calling compat-wireless. http://linuxwireless.org/en/users/Download/stable/ seems they are continuing releasing. I am quite confused, actually. > -- 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/51223ab4.8050...@gmail.com
Re: [Xen-users] [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On Mon, 2013-02-18 at 13:51 +, Gavin wrote: > I managed to get iDRAC console access and on further inspection it > appears that grub first boots xen-4.1-amd64.gz and then the Linux > kernel. Correct. > When I updated the Xen Hypervisor does it not also upgrade the > xen-4.1-amd64.gz file ?? Yes. Unless the version number changes in which case you get a new file in addition to the older version, but that doesn't apply here. > Are there any better ways to trace where this arp reply is being lost > apart from just tcpdump ? tcpdump is what I would use. > If the kenrel hasn't changed and you are 100% sure the network configuration before and after the reboot is the same then so am I. All I can suggest is to reinstall the previous version of Xen. Ian. -- Ian Campbell Current Noise: Karma To Burn - Thirty Five America, how can I write a holy litany in your silly mood? -- Allen Ginsberg -- 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/1361197937.32047.13.ca...@zakaz.uk.xensource.com
[wheezy] ntfs-3g leaves .fuse_hidden000XYZ files
I noticed that files I (thought I) deleted from ntfs3g-mounted partitions sometimes (not always) still appeared when booting under Windows7 (under names like .fuse_hidden000nnn) This does not happen under squeeze (nor ubuntu 12.04 for that matter) The relevant entries in fstab look like the following (not sure how they got generated initially) /dev/sda1 /windows/C ntfs-3g auto,users,noexec,uid=1000,gid=users,dmask=002,fmask=113,relatime 0 0 -- 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/kftebd$deb$1...@ger.gmane.org
Re: [1/2OT] bcm4331
I found something interesting. │ Symbol: B43_BCMA_EXTRA [=y] │ │ Type : boolean │ │ Prompt: Hardware support that overlaps with the brcmsmac driver │ │ Defined at drivers/net/wireless/b43/Kconfig:34 │ │ Depends on: NETDEVICES [=y] && WLAN [=y] && B43_BCMA [=y] │ │ Location: │ │ -> Device Drivers │ │ -> Network device support (NETDEVICES [=y]) │ │ -> Wireless LAN (WLAN [=y]) │ │ -> Broadcom 43xx wireless support (mac80211 stack) (B43 [=m]) │ │ (8) -> Support for BCMA bus (B43_BCMA [=y]) -- 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/51223f0a.8020...@gmail.com
Re: [1/2OT] bcm4331
Le Lun 18 février 2013 15:23, lina a écrit : > On Monday 18,February,2013 10:17 PM, "Morel Bérenger" wrote: > >> Le Lun 18 février 2013 15:08, lina a écrit : >> >>> Hi, >>> >>> >>> >>> A quick question, does the latest kernel support the bcm4331 wireless >>> card? or does it still need compat-wireless and etc. >>> >>> Thanks with best regards, >>> >> >> I am not sure about what you are calling compat-wireless. My netbook >> have a wl card from that family, and run perfectly with current stable >> (last >> time I ran stable is at least 1 year ago, thought). The only issue is, >> that this firmware is in non-free. >> >> > > The kernel I used is 3.3.5. which doesn't support the bcm4331. Sorry, I've read bcm4313, and not bcm4331... So, my phrase about my card working is completely out-thread. But is not that card supported by this: http://packages.debian.org/squeeze/firmware-brcm80211 ? Description speaks about bcm43xx, so I guess your should works? Or is it what you name a compat-wireless? You can also check b43 (on the web) and I think there is another one, but I can not remember the name. -- 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/f691d9408417a714a25e03720520ff22.squir...@www.sud-ouest.org
Mic on lenovo T530
On my Lenovo T530, I get sound, but I cannot succeed in using mic. In Audacity gain for Mic is greyed out (but I can select default or HDA Intel input device). I use wheezy, alsa on KDE, and in KMIX everything is on with a non null volume. If someone succeeded in getting mic working, I am interested in the solution. -- 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/51224c91.7050...@rail.eu.org
Re: Mic on lenovo T530
Le 18/02/2013 16:45, Erwan David a écrit : On my Lenovo T530, I get sound, but I cannot succeed in using mic. In Audacity gain for Mic is greyed out (but I can select default or HDA Intel input device). I use wheezy, alsa on KDE, and in KMIX everything is on with a non null volume. If someone succeeded in getting mic working, I am interested in the solution. Sorry, but it now works... (after a logout and reboot) -- 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/5122532c.5020...@rail.eu.org
[SOLVED] Re: [Xen-users] [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On 18 February 2013 16:32, Ian Campbell wrote: > On Mon, 2013-02-18 at 13:51 +, Gavin wrote: > > > > > If the kernel hasn't changed and you are 100% sure the network > configuration before and after the reboot is the same then so am I. > > All I can suggest is to reinstall the previous version of Xen. > Thanks very much for all your assistance Ian, the problem was with the network. We introduced a second switch into the stack and it seems like it was our bond interface to the switch that caused this particular issue. We were using bond mode 5 since that works for us elsewhere and did not think that this could be the problem since we were seeing the arp-replies reach the host bridge interface. As per Xen recommendations I tried mode 7 but that too did not work. Once configured to use bond mode 1 (active-backup) this all started working again. Apologies for the run-around, the false accusations and also the cross-posting, have a few hours before going live with this platform and was under a fair amount of pressure. All good now!! :) Regards, Gavin > >
Re: upgrading to wheezy - multiseat stops working
Sergey Spiridonov wrote: Hi Debian I try to upgrade my working multi-seat installation to wheezy. I have nvidia graphic cards. In squeeze I used gdm. It was working OK. I had following entries in gdm.conf: 8<->8 [servers] 0=Standard0 1=Standard1 [server-Standard0] name=Standard server command=/usr/bin/X -novtswitch -sharevts vt8 -isolateDevice PCI:2:0:0 -layout seat0 flexible=false [server-Standard1] name=Standard server command=/usr/bin/X -novtswitch -sharevts vt8 -isolateDevice PCI:3:0:0 -layout seat1 flexible=false 8<->8 Nothing special... Wheezy does not have gdm. There is gdm3, but Google tells that it does not support multi-seat. So, I took lightdm. Here is first lightdm.conf (copy-paste from gdm): 8<->8 [LightDM] minimum-display-number=0 minimum-vt=7 xserver-allow-tcp=false [SeatDefaults] xserver-command=/usr/bin/X xserver-allow-tcp=false greeter-session=lightdm-greeter session-wrapper=/etc/X11/Xsession [Seat:0] command=/usr/bin/X -novtswitch -sharevts vt8 -isolateDevice PCI:2:0:0 xserver-layout=seat0 [Seat:1] command=/usr/bin/X -novtswitch -sharevts vt8 -isolateDevice PCI:3:0:0 xserver-layout=seat1 8<->8 This does not work. I reduced X command as much as possible. When I look at ps output, I can see that isolateDevice is filtered by lightdm. Also lightdm adds his own options to X, so reduced command line looks like the following: [Seat:0] command=/usr/bin/X xserver-layout=seat1 [Seat:1] command=/usr/bin/X -sharevts xserver-layout=seat0 After reboot I get login screen on one of the seat. Seat0 alternate with seat1. First time I get seat1 next time seat0, then again seat1 and so on. Another display always stays black. If I get seat1 running, I get both X server in process list: $ ps a| grep X 3494 tty7 Ss+0:00 /usr/bin/X :0 -layout seat1 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch 3496 tty8 Ss+0:13 /usr/bin/X :1 -layout seat0 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch If I get seat0 running, I get only one X server. Another just exits or sometimes crashes. I do not see errors or something unusual in log files. Interesting is that sharevts option is always filtered by lightdm and is not passed to X server, as well as isolateDevice option. I am attaching config files, but there is nothing special there. xorg.conf is working in squeeze. Log files do not show any error. What I tried: 1. Switched order of seats in lightdm - no effect 2. Added Option "ProbeAllGpus" "FALSE" to all nvidia sections - no effect I did not file bug report yet. Glad to see someone is still trying multiseat! AFAIK the problem is the loss of gdm. It is still in sid, have you tried running with that? Another possibility, have you tried running without a DM but just with startx? Like: startx -- :0 -layout X1 -dpi 110 -isolateDevice PCI:1:0:0 startx -- :1 -layout X0 -dpi 110 -isolateDevice PCI:0:8:0 -sharevts Hugo -- 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/kfu0tk$a0o$1...@ger.gmane.org
Re: disk labels mismatch
Hi! This problem has been solved but since some points might be of general interest even to Debian developers here is a report on the issue. To summarize: There are 3 disks on the machine sda, sdb, sdc. Debian Sid is installed on sda. sdb is _not_ mounted but contained an older installation of Debian Squeeze. The problem was that grub "saw" that old installation on sdb although sdb was _not_ mounted. For example, I deleted grub.cfg and updated grub and all old installations from sdb would reapear. Equally so during booting. At the beginning I thought that was the problem of the MBR at sdb but Bob Proulx and Igor Cicimov helped in excluding that option. Then I reformated sdb and, of course, the installations were no more. I would say that this is something that should be changed. Grub simply should not read unmounted disks. Best, Mladen. -- 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/20130218214247.gb29...@grad.hr
Re: disk labels mismatch
On Mon, 18 Feb 2013 22:42:48 +0100, pavicic wrote: updated grub So you updated grub automatically, not manually ;)? I always write my grub.cfg or menu.lst myself, doing this I can chose the entries, the way I need them. It might be impossible, but at least it would be much, much work, to set up this automatic update thingy, to fit to my needs. Regards, Ralf PS: Take a look at your mail client, perhaps it does support "reply to list only" by the preferences, many users are nor aware of this option. -- 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/op.wsp662z3qhadp0@freebsd
Re: disk labels mismatch
Hi, Dňa Mon, 18 Feb 2013 22:42:48 +0100 pavicic napísal: > The problem was that grub "saw" that old installation > on sdb although sdb was _not_ mounted. For example, > I deleted grub.cfg and updated grub and all old > installations from sdb would reapear. Equally so > during booting. IMHO os-prober is checking all MBR and not only MBR on mounted devices... You can consider to fill the bugreport about this. i have uninstalled os-prober for a long time :-) regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: disk labels mismatch
On Tue, Feb 19, 2013 at 12:50:52AM +0100, Ralf Mardorf wrote: > On Mon, 18 Feb 2013 22:42:48 +0100, pavicic wrote: > >updated grub > > So you updated grub automatically, not manually ;)? > > I always write my grub.cfg or menu.lst myself, doing this I can Eeee!, that's probably asking for trouble!¹ Not good advice!! > chose the entries, the way I need them. It might be impossible, but > at least it would be much, much work, to set up this automatic > update thingy, to fit to my needs. All configuration should be done under '/etc/grub.d/' and of course there is '/etc/default/grub' ¹ Scripts can run update-grub overwriting your settings, and besides, grub.cfg can't be wriiten to in the normal way unless you mess with the permissions. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- 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/20130219013015.GE29171@tal
