[arch-general] Unable to mount external USB HD from two of my USB ports
I've been having troubles mounting an external USB HDD to two of the three USB ports on my laptop. dmesg reports a timeout connecting to the device; plugging in other devices to the same ports works fine with no errors. I've attached the log here[1]. The drive in question is a Seagate 1.5 TB Expansion Portable Drive, model ST1500LM003-9YH148. I reformatted it upon purchase to have two partitions, a NTFS one for Windows compatibility, and an Ext4 one for Linux backups and miscellanea. Each partition is ~750GB in size. Any idea what is going on? I think the issue may be with the drive, which is virtually brand new (I bought it ~3 months ago). [1] https://gist.github.com/3916478
Re: [arch-general] Leafnode and Systemd
> Thanks for the pointers; something for another evening This bug has attached sysemd service files for leafnode. https://bugs.archlinux.org/task/24530
Re: [arch-general] [arch-dev-public] iproute2 to base
Leonid Isaev wrote:
> On 10/16/2012 08:21 PM, Gaetan Bisson wrote:
>> [2012-10-16 10:41:09 -0500] Leonid Isaev:
>>> I fully support having netcfg in base (and as a default
network backend
>>> in arch) because it is far better than the alternatives :)
I don't think
>>> that wpa_supplicant/crda belongs in base (for instance
routers don't
>>> need wpa_supplicant but may require hostapd), but iw (and
iproute2)
>>> definitely has to go there as it provides some hardware
management
>>> capabilities.
>>
>> Since routers do not need netcfg any more than they do
wpa_supplicant,
>> with your reasoning, it should not be in base either...
>>
>
> YMMV apparently, but in my experience a router needs:
> (1) Some way to stick to the (usually creepy) ISP DHCP
server, i.e. keep
> retrying to obtain IP if the DHCP server doesn't respond.
> (2) Bridging support.
>
> The former is solved with net-auto-wired (ifplugd is quite
good), while
> the latter -- with "bridge" profiles in netcfg. So without
netcfg I
> would have to write my own boot scripts.
>
>> If we stick to the definition that the base group should
contain
>> everything needed too boot up a minimal system and connect
it to the
>> network, then I do not see how you can consider
wpa_supplicant optional.
>>
>
> I understand your logic, but still think that wpa_supplicant
should be
> optional. Since there are no core images, anyone who wants
to use a
> machine as a station will install wpa_supplicant anyways
over the
> already working network...
The idea at some point [0] was to make
base-{networking,wireless-networking} groups. I dont know if
that can be considered today, but this is more or less the
idea of why i had requested for wpa_supplicant to leave base
[1] and why i have requested the same for ppp [2].
If this old concept, or a similar one is implemented
personally even though wpa_supplicant is essential for me as
well, i see no reason to have any of those in base.
On the other hand by having netcfg in the base group you
essentially provide support for both.
BTW i dont understand the reason why the base group has
anything to do with archiso, since archiso adds and will
probably be always adding packages on top of the base group
from all the other repos in order to provide additional
functionality. Argumenting that foo should be in base cause
we
want support for it in the install media is no argument at
all.
[0]: https://bugs.archlinux.org/task/12890
[1]: https://bugs.archlinux.org/task/22482
[2]: https://bugs.archlinux.org/task/22480
Re: [arch-general] [arch-dev-public] iproute2 to base
[2012-10-18 15:15:02 -0400] Leonid Isaev: > On 10/16/2012 08:21 PM, Gaetan Bisson wrote: > > > >Since routers do not need netcfg any more than they do wpa_supplicant, > >with your reasoning, it should not be in base either... > > > > YMMV apparently, but in my experience a router needs: > (1) Some way to stick to the (usually creepy) ISP DHCP server, i.e. > keep retrying to obtain IP if the DHCP server doesn't respond. > (2) Bridging support. > > The former is solved with net-auto-wired (ifplugd is quite good), > while the latter -- with "bridge" profiles in netcfg. So without > netcfg I would have to write my own boot scripts. You may solve these problems with whatever piece of software you want. On my router, I simply use iptables' FORWARD chain. My point being that there are dozens of apps that do the same thing netcfg does; however wpa_supplicant is the only one that does what it does. > I understand your logic, but still think that wpa_supplicant should > be optional. Since there are no core images, anyone who wants to use > a machine as a station will install wpa_supplicant anyways over the > already working network... And how is this not different for netcfg? I understand you have use for one but not the other, but please try to be a little objective... -- Gaetan
[arch-general] pambase and LDAP
I am trying to figure the best way to do LDAP authentication (using a customized version of nss-pam-ldapd from AUR) on my laboratory, but I am having some problems. Since Arch now have a pambase package that should be imported on every pam configuration files (instead to relly on using old *.so for which authentication module) but this is not what is happening: as far I know, KDE (and KDM) is the only package that really uses pambase configuration files. I don't think that the best way to resolve this is to put pam_ldap.so in every service that I need, so what should I do: -Import system-auth, system-login or system-local-login on every service that I need (and remove old and redundant *.so modules). -Just add pam_ldap.so on every service that I need. -- Thiago Kenji Okada PGP Key: EEC09705
Re: [arch-general] Leafnode and Systemd
On Thu, 18 Oct 2012 15:55:30 -0400 Dave Reisner wrote: [...] >Use inetd-style activation via systemd. See sshd@.service and >sshd.socket as an example. xinetd is redundant. Thanks for the pointers; something for another evening! -- -- ^^ -- Whiskers -- ~~
[arch-general] neo - german keyboard layout
hi list, i played around with neo2, an alternative kbd layout optimized for german. in my kde environment. the main concept of neo is using meta keys to shift between layers. for me, the meta4 key is not working on either side. i found some suggestions to solve this problem, but nothing worked so far. anybody out there knowing, how to fix this? and how can i enable neo in initramfs, for input of my encryption pw? thanks georg
Re: [arch-general] Leafnode and Systemd
On Thu, Oct 18, 2012 at 08:26:16PM +0100, Whiskers wrote: > On Thu, 18 Oct 2012 00:03:57 +0200 Thomas Bächler > wrote: > > >Am 17.10.2012 21:29, schrieb Whiskers: > >> Rather than install tcp-wrappers on my Arch system, I'd like to use > >> whatever the proper "server" is nowadays instead of /usr/sbin/tcpd - but > >> what is it? > > > >Why would you replace tcpd with anything? Does it serve any purpose at > >all? > > Thanks for responding. > > On a system with tcp-wrappers, tcpd is the "server" which launches > leafnode. From man leafnode: > >[...] > >The leafnode program itself is the NNTP server. It is run from >/etc/inetd.conf when someone wants to read news. The other parts of >the package, fetchnews and texpire, are responsible for fetching new >news from another server, and for deleting old news. > >[...] > >No network-level access control is supported. This is a deliberate >omission: Implementing this is a job which should not be redone for >each and every service. > >I recommend that either firewalling or tcpd be used for access control. > >[...] > > Xinetd is the 'new improved' inetd, and the xinetd setup recommended in > the Leafnode tarball's README has tcpd as the "server" and leafnode as > the "server argument", as in the /etc/xinetd.d/nntp file previously quoted. > This of course doesn't work on my Arch system, as tcp-wrappers (and thus, > tcpd) is missing. It's quite simple. Get rid of tcpd as the "server". It's just a wrapper that launches an arbitrary process which doesn't link to libwrap.so so that tcp-wrappers can be used for ACLs. It isn't a requirement -- it's a recommendation. > So I'm trying to work out how to get leafnode available on demand, without > using tcp-wrappers and tcpd, but with ufw, and with the new systemd (I've > uninstalled initscripts from my system). Use inetd-style activation via systemd. See sshd@.service and sshd.socket as an example. xinetd is redundant. d
Re: [arch-general] Leafnode and Systemd
On Thu, 18 Oct 2012 00:03:57 +0200 Thomas Bächler
wrote:
>Am 17.10.2012 21:29, schrieb Whiskers:
>> Rather than install tcp-wrappers on my Arch system, I'd like to use
>> whatever the proper "server" is nowadays instead of /usr/sbin/tcpd - but
>> what is it?
>
>Why would you replace tcpd with anything? Does it serve any purpose at
>all?
Thanks for responding.
On a system with tcp-wrappers, tcpd is the "server" which launches
leafnode. From man leafnode:
[...]
The leafnode program itself is the NNTP server. It is run from
/etc/inetd.conf when someone wants to read news. The other parts of
the package, fetchnews and texpire, are responsible for fetching new
news from another server, and for deleting old news.
[...]
No network-level access control is supported. This is a deliberate
omission: Implementing this is a job which should not be redone for
each and every service.
I recommend that either firewalling or tcpd be used for access control.
[...]
Xinetd is the 'new improved' inetd, and the xinetd setup recommended in
the Leafnode tarball's README has tcpd as the "server" and leafnode as
the "server argument", as in the /etc/xinetd.d/nntp file previously quoted.
This of course doesn't work on my Arch system, as tcp-wrappers (and thus,
tcpd) is missing.
So I'm trying to work out how to get leafnode available on demand, without
using tcp-wrappers and tcpd, but with ufw, and with the new systemd (I've
uninstalled initscripts from my system).
Changing the xinetd configuration for leafnode so that tcpd isn't
required, like this:
$ cat /etc/xinetd.d/nntp
service Leafnode
{
flags = NOLIBWRAP
per_source = 3
port = 119
socket_type = stream
protocol = tcp
user = news
server = /usr/local/sbin/leafnode
type = UNLISTED
wait = no
instances = 7
only_from = 127.0.0.1
}
still doesn't make leafnode accessible to my usenet client (slrn). Which
is strange, as I can run leafnode manually from the command line:
$ leafnode
200 Leafnode NNTP daemon, version 2.0.0.alpha20110806a at tavy.mobile.private
quit
205 Always happy to serve!
... and even then, slrn reports
Failed to initialize server
Run-Time Error
Reason:
slrn fatal error:
Failed to initialize server.
I have even created /etc/hosts.deny and /etc/hosts.allow, in case xinetd
expects to find them (although I can't find mention of that in the
documentation I've seen). Still no luck.
I'm beginning to wonder if xinetd itself isn't redundant; can systemd
alone manage access control and work as a 'super server'? I'm still
trying to get to grips with all that systemd can do - and how to make it
do it. Presumably, I'll have to invent a custom systemd 'service' for
systemd if that is the way to go.
--
-- ^^
-- Whiskers
-- ~~
Re: [arch-general] [arch-dev-public] iproute2 to base
On 10/16/2012 08:21 PM, Gaetan Bisson wrote: [2012-10-16 10:41:09 -0500] Leonid Isaev: I fully support having netcfg in base (and as a default network backend in arch) because it is far better than the alternatives :) I don't think that wpa_supplicant/crda belongs in base (for instance routers don't need wpa_supplicant but may require hostapd), but iw (and iproute2) definitely has to go there as it provides some hardware management capabilities. Since routers do not need netcfg any more than they do wpa_supplicant, with your reasoning, it should not be in base either... YMMV apparently, but in my experience a router needs: (1) Some way to stick to the (usually creepy) ISP DHCP server, i.e. keep retrying to obtain IP if the DHCP server doesn't respond. (2) Bridging support. The former is solved with net-auto-wired (ifplugd is quite good), while the latter -- with "bridge" profiles in netcfg. So without netcfg I would have to write my own boot scripts. If we stick to the definition that the base group should contain everything needed too boot up a minimal system and connect it to the network, then I do not see how you can consider wpa_supplicant optional. I understand your logic, but still think that wpa_supplicant should be optional. Since there are no core images, anyone who wants to use a machine as a station will install wpa_supplicant anyways over the already working network...
Re: [arch-general] is mesa, glproto, dri2proto not needed by intel video driver anymore?
On Thu, Oct 18, 2012 at 3:05 PM, Thanos Zygouris wrote: > Hi, > If i run 'pacman -Qdt' (search for not needed installed packages) i got: > dri2proto 2.8-1 > glproto 1.4.16-1 > mesa 9.0-1 > > If i remember right, these were intalled by xf86-video-intel, or > intel-dri in the past. > So, my question is: can i remove these packages safely? > > My video card is: > 'Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller' > and i am using intel driver, with KMS (i915). mesa's libxatracker is currently only needed for the vmware Xorg driver. So if you don't need that, they're only builddepends.
[arch-general] is mesa, glproto, dri2proto not needed by intel video driver anymore?
Hi, If i run 'pacman -Qdt' (search for not needed installed packages) i got: dri2proto 2.8-1 glproto 1.4.16-1 mesa 9.0-1 If i remember right, these were intalled by xf86-video-intel, or intel-dri in the past. So, my question is: can i remove these packages safely? My video card is: 'Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller' and i am using intel driver, with KMS (i915).
Re: [arch-general] permissions mismatch error while upgrading the system
Thank you very much! I will be informing some friends who asked the same to me :)
Re: [arch-general] permissions mismatch error while upgrading the system
Am 17.10.2012 20:42, schrieb Martín Cigorraga: > Hi! > I got this: > > ( 7/11) upgrading > nfs-utils > [--] 100% > warning: directory permissions differ on > var/lib/nfs/rpc_pipefs/ > filesystem: 555 package: 755 > > It's safe to just chmod the /var/lib/nfs/prc_pipefs directory to 755 by > hand? > Thank you! rpc_pipefs is a mount point of a virtual file system: $ findmnt /var/lib/nfs/rpc_pipefs/ TARGET SOURCE FSTYPE OPTIONS /var/lib/nfs/rpc_pipefs rpc_pipefs rpc_pipefs rw,relatime The kernel sets the permissions of the mount point the right way. Don't touch it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] permissions mismatch error while upgrading the system
On Thu, Oct 18, 2012 at 12:46:36PM +1100, Gaetan Bisson wrote: > [2012-10-17 15:42:56 -0300] Martín Cigorraga: > > warning: directory permissions differ on var/lib/nfs/rpc_pipefs/ > > filesystem: 555 package: 755 > > The difference between 555 and 755 is write permission for the owner... > So it should be completely harmless to chmod that directory to 755. > > -- > Gaetan Pretty sure the idea here is that the permissions in userland reflect what the kernel presents us with for "permissions" on the filesystem. No user will be able to write to rpc_pipefs, so the filesystem itself is 555. We should change this in the nfs-utils package so that its installed as 555. If you recall, the same thing happened with /sys being mounted as 555 as of kernel 3.4: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c56d8a73 d
