Re: [arch-general] Forced to run fsck manually on unattended system
On Wed, Mar 6, 2013 at 1:28 AM, Chris Down ch...@chrisdown.name wrote: If you want to avoid data loss at the cost of performance, don't do any disk write caching. If I recall correctly, you can do this with `hdparm -W 0'. And using a journaled file system, such as ext3 or ext4, should improve the situation. If you feel more comfortable with old, proved filesystems, ext3 has been ready for production systems for quite some time. Best regards. -- Rodrigo
Re: [arch-general] [wpa_actiond 1.4] slow disconnects
Am 05.03.2013 16:44, schrieb Pali Rohár: Hello, On Tuesday 05 March 2013 10:23:24 Thomas Bächler wrote: Am 04.03.2013 21:26, schrieb Leonid Isaev: Hi, With testing/wpa_actiond-1.4 I am having a minor problem when shutting down net-auto-wireless.service: 'systemctl stop net-auto-wireless.service' pauses for ~10sec before finally disconnecting. Of course, this also occurs on normal system poweroff (which is usually ~5sec). The wifi network is WPA enterprise (important entries in wpa_supplicant.conf: key_mgmt=WPA-EAP; eap=PEAP; phase1=peaplabel=0; phase2=auth=MSCHAPV2), and piece of daemon.log after the above delay has elapsed: I've seen this too, but I didn't determine yet that is was wpa_actiond's fault. There are several issues here: 1) I am unsure what exactly terminates wpa_actiond. Before my patches wpa_actiond could be terminated only by KILL/TERM signals or correct terminate event from wpa_supplicant. wpa_supplicant sending terminate event only if wpa_supplcant is stopped regulary (when wpa_supplicant is killed by KILL no terminate event is sent!). With my patches wpa_actiond is also terminated when wpa_supplicant is KILLed. 2) net-auto-wireless.service is Type=forking, but has no proper MainPID detected, so systemd doesn't know what exactly to kill. This change however seems to be related to Pali's changed, so I'm CC'ing him to see if he knows what this might be about. You can always stop wpa_actiond with KILL or TERM signals. I did not removed any code which handling stopping wpa_actiond. I only added another check if wpa_actiond should exit. So my patches should not change behaviour of stopping wpa_actiond. Problem is maybe in blackbox which starting and stoppping wpa_actiond. I'm not using that systemd and this is another reason against it. Not easy to understand and debug this problem. I tested my patches on my system without systemd and wpa_actiond working without problem. Really I cannot help you with blackbox which I not using... This may even be related to the way netcfg stops wpa_actiond (it doesn't - it only stops wpa_supplicant). One can probably debug this easily by making wpa_actiond more verbose. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [wpa_actiond 1.4] slow disconnects
Hi Thomas,
Sorry for not replying earlier...
On Tue, 05 Mar 2013 10:23:24 +0100
Thomas Bächler tho...@archlinux.org wrote:
Am 04.03.2013 21:26, schrieb Leonid Isaev:
Hi,
With testing/wpa_actiond-1.4 I am having a minor problem when shutting down
net-auto-wireless.service: 'systemctl stop net-auto-wireless.service'
pauses for ~10sec before finally disconnecting. Of course, this also
occurs on normal system poweroff (which is usually ~5sec). The wifi
network is WPA enterprise (important entries in wpa_supplicant.conf:
key_mgmt=WPA-EAP; eap=PEAP; phase1=peaplabel=0; phase2=auth=MSCHAPV2),
and piece of daemon.log after the above delay has elapsed:
I've seen this too, but I didn't determine yet that is was wpa_actiond's
fault. There are several issues here:
wpa_supplicant 2.0 + wpa_actiond 1.3 do not suffer from the above problem,
so...
OTOH, the delay seems to be related to deauthentication. If authentication is
impossible, e.g. due to wrong password (but SSID is still correct), there is
no delay on stop/restart.
1) I am unsure what exactly terminates wpa_actiond.
Does it really matter, if all wpa* processes are in the same cgroup?
2) net-auto-wireless.service is Type=forking, but has no proper MainPID
detected, so systemd doesn't know what exactly to kill.
This change however seems to be related to Pali's changed, so I'm CC'ing
him to see if he knows what this might be about.
My understanding is that netcfg is not maintaned any more, so I'll switch to
netctl to look further into this. But the bigger question which I have is why
do we even need net{cfg,ctl}? Wpa_actiond attaches to wpa_supplicant's socket,
no? So can't we make systemd own this socket and use the netcfg-wpa_actiond
only as a helper for wpa_actiond (i.e. eliminate net-auto-wireless.service
alltogether)?
--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
[arch-general] Weird issue with Google Talk/Hangout plugin
I'm having a weird issue with the Google Talk plugin (https://aur.archlinux.org/packages/google-talkplugin/) distorting all my video images - both the ones of me coming in from my camera, and the ones coming in from others across the Net. See http://www.darose.net/GoogleHangWeirdness.png for an example. Anyone have any idea what's going on here and/or how to fix? This seems to be a recent issue - i.e., probably caused by some package upgrade within the past week or so. I'm running google-talkplugin 3.14.17.0-1 with firefox 19.0-1. But I don't think the issue is caused by the plugin itself. (Or by firefox, since I see the same problem when I use Google chromium browser.) I was running an older version of the plugin - which had been working fine for weeks - when I started experiencing the issue. I upgraded to the latest version in an attempt to work around the problem, but it didn't clear it up. So as I said, I don't think the plugin itself is the cause of the problem - since 2 different versions of the plugin are experiencing the issue, and the issue popped up out of the blue after things had been working fine for quite a while. Any assistance anyone might be able to lend here would be much appreciated! Thanks, DR
[arch-general] Broadcom B43 problems
I have seen some indications that my Broadcom B43 *ought* to work with the kernel's b43 driver, but I've never managed to get it working on my own. I'd love to be able to switch away from the broadcom-wl package is possible. Using a kernel from a few days ago, 3.7.9 and the b43-firmware package from AUR I only get as far as connecting to my router (at least that's what NetworkManager says), but then I can't actually connect to any site. If I then bring down the network and then bring it back up again the connection to the router will fail (NetworkManager keeps asking for the password). Any suggestions on what might be causing this, and what I should try next? /M % lspci -nn|grep Broadcom 03:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01) Wireless network uses WPA2 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpCkGmdcAmxe.pgp Description: PGP signature
[arch-general] Cannot chroot '/bin/bash': No such file or directory
Guys, Attempting to fix the test box that updating left unable to boot, I cannot chroot to fix the system. I've booted from the install medium and done the normal mount of the existing system under /mnt: mount /dev/sda6 /mnt mount /dev/sda5 /mnt/home mount /dev/sda8 /mnt/boot mount -o bind /dev /mnt/dev mount -t proc none /mnt/proc mount -t sysfs none /mnt/sys All files appear in their proper place under /mnt. However, attempting to create the chroot fails: cd /mnt chroot /mnt /bin/bash chroot: failed to run command '/bin/bash': No such file or directory /bin/bash is in the new location /usr/bin/bash (moved from /bin/bash by the update) with with a proper symlink in /mnt/bin/bash pointing to ../usr/bin/bash This if the first time I've ever had difficulty chrooting a system. I suspect that this is caused by the last update that pulled in systemd which left the system unbootable. Anyone know what could be causing the chroot failure? I've tried explicitly pointing the chroot to ./usr/bin/bash, etc... and tried it without any executable specified. Regardless, I get the same No such file or directory. Thanks in advance for any help or link you can provide. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Cannot chroot '/bin/bash': No such file or directory
On Wed, Mar 6, 2013 at 8:32 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, Attempting to fix the test box that updating left unable to boot, I cannot chroot to fix the system. I've booted from the install medium and done the normal mount of the existing system under /mnt: mount /dev/sda6 /mnt mount /dev/sda5 /mnt/home mount /dev/sda8 /mnt/boot mount -o bind /dev /mnt/dev mount -t proc none /mnt/proc mount -t sysfs none /mnt/sys All files appear in their proper place under /mnt. However, attempting to create the chroot fails: cd /mnt chroot /mnt /bin/bash chroot: failed to run command '/bin/bash': No such file or directory /bin/bash is in the new location /usr/bin/bash (moved from /bin/bash by the update) with with a proper symlink in /mnt/bin/bash pointing to ../usr/bin/bash This if the first time I've ever had difficulty chrooting a system. I suspect that this is caused by the last update that pulled in systemd which left the system unbootable. Anyone know what could be causing the chroot failure? I've tried explicitly pointing the chroot to ./usr/bin/bash, etc... and tried it without any executable specified. Regardless, I get the same No such file or directory. Thanks in advance for any help or link you can provide. -- David C. Rankin, J.D.,P.E. I had this issue once. It was on a system that had corruption on its root drive due to power failures. The error can be very misleading; in my case the file existed and yet the chroot still failed. I ended up wiping that system, but the most likely conclusion I could come to was that some very important system .so's got corrupted. If you have busybox installed, try chrooting into busybox's sh. If that works and the bash executable really does exist despite that error, I'm afraid you may have a quite the thrashed system on your hands. -- --Zootboy Sent from some sort of computing device.
