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* us
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
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 here
Tobias Powalowski wrote:
Hi guys,
while experimenting with different raid setups in kvm, i found out our raid
support is not really ideal.
The status now:
- raid hook(inlcuded in mkinitcpio package) does assemble normal raid:
but if a drive fails it will fail to boot after it.
i'm not 100%
With reference to older discussions about blacklisting methods -
modprobe supports -b (or in long form --use-blacklist) that will also
block explicit loading by standard module name. Thus you could nicely
avoid shell wrapper on fb stuff.
The switch won't block implicit dependencies though (so
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
Carotinho wrote:
Hi!
The main question is: how can I obtain the "right" behaviour from my own
compiled kernel? Is this due to some misconfiguration of the kernel at
compile-time, or is it obtained through some other kind of magic?
The real problem here is that I cannot give a name to this pro
Travis Willard wrote:
Hey guys,
I just realized that, for some squirrely reason, I am currently
"maintaining" libcap. I have no freakin' clue what libcap even is. I
just got a flag-out-of-date version asking if we should update it to
libcap2, which seems reasonable, as it's nice and shiny-new.
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 (alon
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 i
You can block frambuffer in udev, but you have to block the driver by
its modalias or other attributes (similary as if you tried to block
sound through udev).
For example, following rule would do the thing in my case, on one of my
machines (that has some old ati card):
SUBSYSTEM=="pci", ATTR{ven
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
Michal Soltys wrote:
As for your #3 idea, you can store that blacklist file in i.e.
/dev/.udev/blacklist, which you can remove later, after udev processing.
Also, rc.sysinit script you could add extra trigger pass for failed
events, i.e.
Actually, let it stay there. /dev/.udev/ is
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 nonalia
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 t
Grigorios Bouzakis wrote:
Hi, i started playing with packages in base today, and the first two
packages that come up in alphabetical order are acl and attr.
I decided to research what those packages actually do, since i doubt i
have ever used them.
The site both packages link to is http://oss.sg
17 matches
Mail list logo
