On 2018-09-10 00:13, Eli Schwartz via arch-general wrote:
>
> It is definitely not useless! It's historically been disabled because it
> did not have any good way to enable support, but keep it turned off by
> default. And having it turned on by default came with mandatory
> slowdowns for *all*
On 2012-08-15 17:11, Thomas Bächler wrote:
So, with initscripts, we mount all the API file systems manually. When
you put them in fstab as well, things fail. But when you want special
options for those file systems, you won't get them.
This very short systemd snippet showed that systemd is
On 11-08-24 08:49, Vitor Garcia wrote:
Good morning.
I have been trying to my Dell LTO-120 SCSI Tape Drive on Arch without
success.
I have tried to run $ modprobe st, but still, I have no /dev/st0 and
neither /dev/nst0. dmesg | grep -i tape shows nothing too.
Is there anything I'm missing
Hello
It's pretty minor thing actually - still, since linux-atm is in core,
iproute can benefit a bit from it, as atm qdisc requires it.
So - linux-atm could be added as dependency to iproute2.
Cheers
Thomas Bächler wrote:
The point is, everyone needs it mounted. Your system will be completely
useless without devpts (as it is without the lo interface).
However, I know your opinion on these issues. Are there any rational
reasons not to hardcode devpts?
I'm 100% with Thomas for it
Aaron Griffin wrote:
On Sun, Mar 9, 2008 at 3:05 AM, Michal Soltys [EMAIL PROTECTED] wrote:
ENV{MODALIAS}==modaliases #1, OPTION=ignore_device
ENV{MODALIAS}==modaliases #2, OPTION=ignore_device
This is way more complex than you think it is. Let me explain. A
typical module exposes it's
Tobias Powalowski wrote:
Hi
version bump please signoff both arches
also users can signoff, no dev seems to use xfs.
greetings
tpowa
Tested on x86_64 and i686 arches of mine. Seems to be working fine,
although I didn't do any extensive tests.
cheers
Xavier wrote:
What if you blacklist a module after booting, then plug in some hardware?
http://www.archlinux.org/pipermail/arch-dev-public/2008-February/004941.html
The previous udev package still looks like the most acceptable way.
Ahh, yes, you're right. There would have to be some script
Aaron Griffin wrote:
Idea #2:
$ mv /etc/udev/rules.d/00-load-blacklist.rules
/etc/udev/rules.d/00-load-blacklist.rules.disabled
in /etc/rc.sysinit, add . /lib/udev/mod-blacklist.sh and export
BLACKLSIT MOD_AUTOLOAD right before the udevd --daemon call
comment out the echo lines in the
Aaron Griffin wrote:
If I modprobe blah, it doesn't know which to do. So, blacklisting
bar tells modprobe ONLY to ignore the aliases exposed by bar. I can
still modprobe bar by a non-alias name, and I can still load bar as a
dependent module.
Well, from udev perspective, modprobe by nonalias
10 matches
Mail list logo
