- Arch-general - lists.archlinux.org

Re: [arch-general] wireless driver broadcom b43 random success or failure
by message 13 Apr '16

13 Apr '16

From the wiki page: "Each configuration file is named in the style of /etc/modules-load.d/<program>.conf. Configuration files simply contain a list of kernel modules names to load, separated by newlines." Why was the file 'b43.conf' containing only: b43 incorrect? Is not 'b43' the name of the kernel module?

2 1

[arch-general] wireless driver broadcom b43 random success or failure
by message 12 Apr '16

12 Apr '16

Readers, Can anyone explain if the following 'dmesg' outputs are useful to understand why after start of X session, the wireless driver fails sometimes? The wireless driver does not start automatically and is always started manually with the command (as root): modprobe b43 Below is the dmesg output when the command above, starts successfully the wireless driver: b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0 b44 ssb1:0 eth0: Broadcom 44xx/47xx 10/100 PCI ethernet driver ... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready b43-phy0: Broadcom 4311 WLAN found (core revision 10) b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 2, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07) IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: authenticate with ... wlan0: send auth to ... (try 1/3) wlan0: authenticated wlan0: associate with ... (try 1/3) wlan0: RX AssocResp from ... (capab=0x431 status=0 aid=1) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Below when the 'modprobe b43' fails to start the wireless driver: b43-phy0: Broadcom 4311 WLAN found (core revision 10) b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8 b43-phy0 ERROR: FOUND UNSUPPORTED RADIO (Manuf 0xFFF, ID 0xFFFF, Revision 15, Version 0) b43: probe of ssb0:0 failed with error -95 Broadcom 43xx driver loaded [ Features: PNLS ] The only solution seems to be to switch the computer and start again, sometimes 3 or 4 times repeated failure occurs.

4 5

[arch-general] wireless driver broadcom b43 random success or failure
by message 12 Apr '16

12 Apr '16

Readers, Can anyone explain if the following 'dmesg' outputs are useful to understand why after start of X session, the wireless driver fails sometimes? The wireless driver does not start automatically and is always started manually with the command (as root): modprobe b43 Below is the dmesg output when the command above, starts successfully the wireless driver: b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver version 2.0 b44 ssb1:0 eth0: Broadcom 44xx/47xx 10/100 PCI ethernet driver ... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready b43-phy0: Broadcom 4311 WLAN found (core revision 10) b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 2, Version 0 Broadcom 43xx driver loaded [ Features: PNLS ] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07) IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: authenticate with ... wlan0: send auth to ... (try 1/3) wlan0: authenticated wlan0: associate with ... (try 1/3) wlan0: RX AssocResp from ... (capab=0x431 status=0 aid=1) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Below when the 'modprobe b43' fails to start the wireless driver: b43-phy0: Broadcom 4311 WLAN found (core revision 10) b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8 b43-phy0 ERROR: FOUND UNSUPPORTED RADIO (Manuf 0xFFF, ID 0xFFFF, Revision 15, Version 0) b43: probe of ssb0:0 failed with error -95 Broadcom 43xx driver loaded [ Features: PNLS ] The only solution seems to be to switch off the computer and start again, sometimes 3 or 4 times repeated failure occurs.

6 7

[arch-general] SSL/TLS still seems to be screwed up (retrieving Mail with Thunderbird)
by Elmar Stellnberger 10 Apr '16

10 Apr '16

While being connected via an insecure VPN I had once more left my email client open by accident (Thunderbird). Though access to imap.gmail.com shall be secured by SSL/TLS my gmail password was malversated within a few seconds; i.e. I got a login attempt from HongKong and had to change the password after disconnecting. Is anyone here who can explain the insecurity of SSL/TLS in its current state? Does Thunderbird support certificate pinning? Or do you think that there are still errors in the implementation of the protocol? What about libressl for Linux?

1 0

[arch-general] Emacs is missing the icons in toolbar since one of the last updates
by Manuel Reimer 10 Apr '16

10 Apr '16

Hello, is this a known bug or do only I have this issue? Since the last system update, I no longer have any icons in emacs. The toolbar is just empty. Thanks in advance. Manuel

5 5

[arch-general] Since last update (yesterday) Gnome switches me to VT1 after some time
by Manuel Reimer 10 Apr '16

10 Apr '16

Hello, I hope someone can reproduce this one and can point me to some bug report. I'm using the closed source Nvidia driver and a default Gnome installation. Since the last update, the following happens: Usually Gnome runs two X servers. One on ":0" and one on ":1". The last one is the one, I actually use when I'm logged in. GDM keeps running on :0 (VT1). So if I press Ctrl+Alt+F1, I get back to the login screen. This exactly same configuration also applies to my laptop with an Intel GPU. Here, I also have two X servers running all the time. Since yesterday's update, after some time the first X server terminates for whatever reason. In "/var/log/Xorg.0.log", I see: [ 92.389] (II) systemd-logind: got resume for 13:64 [ 92.389] (II) systemd-logind: got resume for 13:67 [ 92.389] (II) systemd-logind: got resume for 13:65 [ 92.389] (II) systemd-logind: got resume for 13:66 [ 95.021] (II) systemd-logind: got pause for 226:0 [ 95.021] (II) systemd-logind: got pause for 13:64 [ 95.021] (II) systemd-logind: got pause for 13:67 [ 95.021] (II) systemd-logind: got pause for 13:65 [ 95.021] (II) systemd-logind: got pause for 13:66 [ 405.532] (II) evdev: Sun USB Keyboard: Close [ 405.532] (II) UnloadModule: "evdev" [ 405.532] (II) systemd-logind: releasing fd for 13:65 [ 405.546] (II) evdev: USB Mouse: Close [ 405.546] (II) UnloadModule: "evdev" [ 405.546] (II) systemd-logind: releasing fd for 13:64 [ 405.567] (II) evdev: Power Button: Close [ 405.567] (II) UnloadModule: "evdev" [ 405.567] (II) systemd-logind: releasing fd for 13:66 [ 405.593] (II) evdev: Power Button: Close [ 405.593] (II) UnloadModule: "evdev" [ 405.593] (II) systemd-logind: releasing fd for 13:67 [ 405.634] (II) NVIDIA(GPU-0): Deleting GPU-0 [ 405.857] (II) Server terminated successfully (0). Closing log file. This wouldn't be a problem, as logging out restarts this X server allowing me to log in again. The problem is, that this X server termination switches the virtual terminal, so it brings me back to VT1 and I have to switch back to VT2 manually. Does anyone have any idea how to fix this? One possible solution for a (temporary) fix could be if there is any way to ask GDM somehow to immediately terminate this X server on VT1 after logging in. Thanks in advance Manuel

1 0

[arch-general] gnome-keyring collecting passwords just for midori
by Javier Vasquez 09 Apr '16

09 Apr '16

Hi, I learned some time back that one could make gnome capture midori passwords through: https://aur.archlinux.org/packages/midori-passwordmanager I tried it by then, but I didn't like because gnome-keyring was capturing all passwords. I don't use desktop environment, so I was using in my ~/.xinitrc: eval $(gnome-keyring-daemon --start --components=pkcs11,secrets) As I use ssh-agent + keychain, I just removed the ssh agent... However that was capturing every password, from firefox, thunderbird, etc. Although one could refuse to capture them, it was uncomfortable to me, so I decided NOT to use gnomekeyring just for midori. The thought I have, is that perhaps there's a way to specify gnome-keyring to only pay attention to midori passwords, and nothing else. Though I don't see that in its options through the gnome-keyring-daemon man page. If there's a way, please let me know... Thanks, -- Javier

1 0

[arch-general] hunspell-en
by Ralf Mardorf 08 Apr '16

08 Apr '16

Hi, is there a reason that hunspell-en is likely broken all the times, after there was the switch to the new version scheme? A bug against the new package is already reported: https://bugs.archlinux.org/task/48839 $ downgrade hunspell-en Available packages: 1) hunspell-en-2016.01.19-1-any.pkg.tar.xz (local) 2) hunspell-en-2016.01.19-1-any.pkg.tar.xz (remote) 3) hunspell-en-2015.05.18-4-any.pkg.tar.xz (remote) 4) hunspell-en-2015.05.18-3-any.pkg.tar.xz (remote) 5) hunspell-en-2015.05.18-2-any.pkg.tar.xz (remote) 6) hunspell-en-2015.05.18-1-any.pkg.tar.xz (remote) 7) hunspell-en-7.1-3-any.pkg.tar.xz (remote) 8) hunspell-en-7.1-2-any.pkg.tar.xz (remote) select a package by number: 7 Perhaps not all 6 versions are broken, at least the last version that I used without issues was 7.1-3. Regards, Ralf

2 2

[arch-general] automount failure usb storage
by message 05 Apr '16

05 Apr '16

Readers, USB storage media used to appear automatically on the xfce desktop, but not now. From dmesg | tail: uas: probe of 3-1:1.0 failed with error -12 Automount has seemingly failed today. The udev wiki (https://wiki.archlinux.org/index.php/Udev) doesn't make sense to a weak novice like me. Other advice please?

2 1

[arch-general] pacman upgrade confusion
by message 04 Apr '16

04 Apr '16

> Readers, > > An announcement > (https://www.archlinux.org/news/required-update-to-pacman-501-before-2016-04…) > states that users must upgrade to pacman501. > > pacman -S pacman > warning: pacman-5.0.0-1 is up to date -- reinstalling > resolving dependencies... > looking for conflicting packages... > > Packages (1) pacman-5.0.0-1 > > Firstly, I tried: > > yaourt -Syua > package-query: error while loading shared libraries: libalpm.so.9: > cannot open shared object file: No such file or directory > > Then: > > pacman -S pacman > warning: pacman-5.0.0-1 is up to date -- reinstalling > resolving dependencies... > looking for conflicting packages... > > Packages (1) pacman-5.0.0-1 > pacman --version > > .--. Pacman v5.0.0 - libalpm v10.0.0 > / _.-' .-. .-. .-. Copyright (C) 2006-2016 Pacman Development Team > \ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet > '--' > This program may be freely redistributed under > the terms of the GNU General Public License. > > What am I doing wrong, to prevent update to pacman501?

3 2