>
> > I start using testing again a couple of days ago and now on every boot i
> > get this error msg:
> >
> > localhost udevd[313]: specified group 'realtime' unknown
> >
> > realtime group does not exist in my computer
> >
> > Any idea ?
> >
> > Thanks
> >
> > Ignacio
>
> FS#26343?
>
Yes, thanks
On Fri, 2 Dec 2011 16:56:35 -0600
Ignacio Galmarino wrote:
> I start using testing again a couple of days ago and now on every boot i
> get this error msg:
>
> localhost udevd[313]: specified group 'realtime' unknown
>
> realtime group does not exist in my computer
>
> Any idea ?
>
> Thanks
>
I start using testing again a couple of days ago and now on every boot i
get this error msg:
localhost udevd[313]: specified group 'realtime' unknown
realtime group does not exist in my computer
Any idea ?
Thanks
Ignacio
On Mon, Nov 21, 2011 at 8:33 PM, Hector Martinez-Seara wrote:
> In my case I solve the problem by installing the package hplip-plugin
> from AUR. Somehow when the rules where installed by the hp-setup
> program something goes wrong.
Yeah, the upstream rules are wrong, you need the Arch supplied o
Hi,
In my case I solve the problem by installing the package hplip-plugin
from AUR. Somehow when the rules where installed by the hp-setup
program something goes wrong.
Hector
On 21 November 2011 21:12, Philipp Überbacher wrote:
> Excerpts from Tom Gundersen's message of 2011-11-20 14:13:05 +0100
Excerpts from Tom Gundersen's message of 2011-11-20 14:13:05 +0100:
> On Sun, Nov 20, 2011 at 2:10 PM, Hector Martinez-Seara
> wrote:
> > Hi Tom,
> > My system is fully updated so I guess that I have to assume that I
> > should file a bug against hplip.
>
> There are no /etc/udev/rules.d/* file
On Sun, Nov 20, 2011 at 2:10 PM, Hector Martinez-Seara wrote:
> Hi Tom,
> My system is fully updated so I guess that I have to assume that I
> should file a bug against hplip.
There are no /etc/udev/rules.d/* files in the official hplip package,
maybe they are some old stale files that you shoul
Hi Tom,
My system is fully updated so I guess that I have to assume that I
should file a bug against hplip.
Hector
On 20 November 2011 14:19, Tom Gundersen wrote:
> On Sun, Nov 20, 2011 at 12:01 PM, Hector Martinez-Seara
> wrote:
>> After yesterday update I get the following message when reboot
On Sun, Nov 20, 2011 at 12:01 PM, Hector Martinez-Seara
wrote:
> After yesterday update I get the following message when rebooting the
> computer (the computer boots fine):
>
> #
> Sun Nov 20 12:45:34 2011: :: Triggering UDev uevents [BUSY]
Hi,
After yesterday update I get the following message when rebooting the
computer (the computer boots fine):
#
Sun Nov 20 12:45:34 2011: :: Triggering UDev uevents[BUSY][DONE]
Sun Nov 20 12:45:34 2011: :: Loading User-specified Modules
Bastien Dejean wrote:
> What the... ?!
It seems that the Popcorn Hour I'm plugging my drive to is chowning and
chmoding it.
Any Popcorn Hour experts out there?
--
Bastien
Jesse Jaara a écrit :
> No those are the the user/group of the device node FILE
> /dev/sdc1 and teell who is allowed to interact with the disk.
I solved it with:
# chown -hR root:storage /media/foo
# chmod 775 /media/foo
Cheers,
--
Bastien
2011/9/10 Bastien Dejean :
> Jesse Jaara a écrit :
>
>> To put it simply the ext filesystem supports UNIX file attributes
>> and stores the owner and group of the file in the disk
>
> % ls -l /dev/sdc1
> brw-rw 1 root storage 8, 49 Sep 10 12:48 /dev/sdc1
>
> Shouldn't /media/foo have the same u
Jesse Jaara a écrit :
> To put it simply the ext filesystem supports UNIX file attributes
> and stores the owner and group of the file in the disk
% ls -l /dev/sdc1
brw-rw 1 root storage 8, 49 Sep 10 12:48 /dev/sdc1
Shouldn't /media/foo have the same user/group ?
--
Bastien
Jesse Jaara a écrit :
> To put it simply the ext filesystem supports UNIX file attributes
> and stores the owner and group of the file in the disk, unlike
> FAT does. So currently the user/group the ext3 says the file
> is owned by, doesn't exist in the current system.
All right, but I did:
# chow
To put it simply the ext filesystem supports UNIX file attributes
and stores the owner and group of the file in the disk, unlike
FAT does. So currently the user/group the ext3 says the file
is owned by, doesn't exist in the current system.
--
(\_ /) copy the bunny to your profile
(0.o ) to help h
Hi,
I'm using the first rule given here:
https://wiki.archlinux.org/index.php/Udev
When I plug a USB (fat32) stick, the permissions of the corresponding
directory under /media are fine (root:users), but when I plug an external
HD (ext3, also through USB), I get the following user:group settings:
On Thu, 20 Jan 2011 20:20:37 +1030
"Ty John (sand_man)" wrote:
> On Sun, 2011-01-16 at 19:28 -0500, Alexander Lam wrote:
> > A potential solution would be to make udev startup in parallel -
> > but this is kinda hacky because all your devices might not be ready
> > in time for login or fsck or...
On Sun, 2011-01-16 at 19:28 -0500, Alexander Lam wrote:
> A potential solution would be to make udev startup in parallel - but this is
> kinda hacky because all your devices might not be ready in time for login or
> fsck or...
> you get what I mean.
>
> On Sat, Jan 15, 2011 at 8:25 PM, Ty John (sa
A potential solution would be to make udev startup in parallel - but this is
kinda hacky because all your devices might not be ready in time for login or
fsck or...
you get what I mean.
On Sat, Jan 15, 2011 at 8:25 PM, Ty John (sand_man)
wrote:
>
> > Hi,
> >
> > I'm concerned about this line:
> >
> Hi,
>
> I'm concerned about this line:
>
> Am 10.01.2011 09:44, schrieb Ty John (sand_man):
> > ata2.00: failed command: IDENTIFY PACKET DEVICE
>
> Either your device is not behaving normally, or there is something weird
> going on. Have you the latest firmware on your drive? Is the problem
>
Hi!
In data lunedì 10 gennaio 2011 09:44:23, Ty John ha scritto:
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata2.00: failed command: IDENTIFY PACKET DEVICE
I have too random similar errors, I don't remember exactly, but they sure
looks like yours. In my case I solved by
Hi,
I'm concerned about this line:
Am 10.01.2011 09:44, schrieb Ty John (sand_man):
> ata2.00: failed command: IDENTIFY PACKET DEVICE
Either your device is not behaving normally, or there is something weird
going on. Have you the latest firmware on your drive? Is the problem
gone, when you disat
Hi guys,
I have a brand new computer and every time it boots it stalls for a
while at "starting udev". Maybe about 10-15 seconds. Then when it gets
to the part "Waiting for udev events to be processed" it then stalls
for another 30 seconds or so.
When I boot from the Arch install disk I don't get
Am 09.06.2010 16:45, schrieb Juan Diego Tascón:
> modprobe --resolve-alias usb:v0AC8p305Bd0100dcFFdsc00dp00icFFiscFFipFF
>
> it shows nothing.
This works for me on 2.6.34-ARCH. Maybe something went wrong during
depmod. See if the problem persists if you run 'depmod' as root.
signature.asc
Desc
Am 09.06.2010 16:45, schrieb Juan Diego Tascón:
> modinfo gspca_zc3xx
>
> and I got this line among a lot more:
>
> alias: usb:v0AC8p305Bd*dc*dsc*dp*ic*isc*ip*
>
> which obviously matches with mine:
>
> usb:v0AC8p305Bd0100dcFFdsc00dp00icFFiscFFipFF
>
> however when I run
>
> modprobe
On Wed, Jun 9, 2010 at 11:18 PM, Thomas Bächler wrote:
> Am 09.06.2010 15:11, schrieb Juan Diego Tascón:
>>> In the above case, you would run:
>>> modprobe --resolve-alias usb:v0AC8p305Bd0100dcFFdsc00dp00icFFiscFFipFF
>>
>> I ran that and it didn't return anything, are these ids stored inside
>> t
Am 09.06.2010 15:11, schrieb Juan Diego Tascón:
>> In the above case, you would run:
>> modprobe --resolve-alias usb:v0AC8p305Bd0100dcFFdsc00dp00icFFiscFFipFF
>
> I ran that and it didn't return anything, are these ids stored inside
> the modules (*.ko)?
Yes, visible with modinfo.
signature.as
On Tue, Jun 8, 2010 at 7:16 PM, Alexander Duscheleit wrote:
> On Tue, 8 Jun 2010 18:55:33 +0900
> Juan Diego Tascón wrote:
>
>> On Tue, Jun 8, 2010 at 3:55 PM, Jan de Groot
>> wrote:
>> > On Tue, 2010-06-08 at 15:49 +0900, Juan Diego Tascón wrote:
>> >> Actually it is installed, it is called gsp
On Wed, Jun 9, 2010 at 4:17 PM, Thomas Bächler wrote:
> Am 09.06.2010 02:38, schrieb Matthew Monaco:
>> On 06/08/2010 02:41 AM, Jan de Groot wrote:
>>> On Tue, 2010-06-08 at 15:16 +0900, Juan Diego Tascón wrote:
Good day,
I'm getting an error every time I plug-in my webcam as a resu
Am 09.06.2010 02:38, schrieb Matthew Monaco:
> On 06/08/2010 02:41 AM, Jan de Groot wrote:
>> On Tue, 2010-06-08 at 15:16 +0900, Juan Diego Tascón wrote:
>>> Good day,
>>>
>>> I'm getting an error every time I plug-in my webcam as a result the
>>> corresponding module is not being loaded automatica
On 06/08/2010 02:41 AM, Jan de Groot wrote:
On Tue, 2010-06-08 at 15:16 +0900, Juan Diego Tascón wrote:
Good day,
I'm getting an error every time I plug-in my webcam as a result the
corresponding module is not being loaded automatically so I have to
load it by myself. Any one knows a way to fix
2010/6/8 Juan Diego Tascón :
> On Tue, Jun 8, 2010 at 3:41 PM, Jan de Groot wrote:
>> On Tue, 2010-06-08 at 15:16 +0900, Juan Diego Tascón wrote:
>>> Good day,
>>>
>>> I'm getting an error every time I plug-in my webcam as a result the
>>> corresponding module is not being loaded automatically so
On Tue, 8 Jun 2010 18:55:33 +0900
Juan Diego Tascón wrote:
> On Tue, Jun 8, 2010 at 3:55 PM, Jan de Groot
> wrote:
> > On Tue, 2010-06-08 at 15:49 +0900, Juan Diego Tascón wrote:
> >> Actually it is installed, it is called gspca_zc3xx, if I load it
> >> the webcam works, the thing is it is not b
On Tue, Jun 8, 2010 at 3:55 PM, Jan de Groot wrote:
> On Tue, 2010-06-08 at 15:49 +0900, Juan Diego Tascón wrote:
>> Actually it is installed, it is called gspca_zc3xx, if I load it the
>> webcam works, the thing is it is not being loaded automatically
>>
>> > All modules have device aliases for t
On Tue, 2010-06-08 at 15:49 +0900, Juan Diego Tascón wrote:
> Actually it is installed, it is called gspca_zc3xx, if I load it the
> webcam works, the thing is it is not being loaded automatically
>
> > All modules have device aliases for the devices it supports. Udev just
> > tries to load a modu
On Tue, Jun 8, 2010 at 3:41 PM, Jan de Groot wrote:
> On Tue, 2010-06-08 at 15:16 +0900, Juan Diego Tascón wrote:
>> Good day,
>>
>> I'm getting an error every time I plug-in my webcam as a result the
>> corresponding module is not being loaded automatically so I have to
>> load it by myself. Any
On Tue, 2010-06-08 at 15:16 +0900, Juan Diego Tascón wrote:
> Good day,
>
> I'm getting an error every time I plug-in my webcam as a result the
> corresponding module is not being loaded automatically so I have to
> load it by myself. Any one knows a way to fix this?
>
> This is the error:
>
> l
Good day,
I'm getting an error every time I plug-in my webcam as a result the
corresponding module is not being loaded automatically so I have to
load it by myself. Any one knows a way to fix this?
This is the error:
load-modules.sh: 'usb:v0AC8p305Bd0100dcFFdsc00dp00icFFiscFFipFF' is
not a valid
On Thu, 2010-02-11 at 12:50 +0100, Thomas Bächler wrote:
> Am 11.02.2010 11:56, schrieb Karolina Lindqvist:
> >> Your custom kernel is misconfigured, the most likely candidate being:
> >>
> >> $ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz
> >> # CONFIG_SYSFS_DEPRECATED_V2 is not set
> >>
> >> If
Am 11.02.2010 11:56, schrieb Karolina Lindqvist:
>> Your custom kernel is misconfigured, the most likely candidate being:
>>
>> $ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz
>> # CONFIG_SYSFS_DEPRECATED_V2 is not set
>>
>> If this option is set to yes, udev will fail to create devices properly.
>
Wednesday 10 February 2010 skrev Thomas Bächler:
> Your custom kernel is misconfigured, the most likely candidate being:
>
> $ zgrep CONFIG_SYSFS_DEPRECATED /proc/config.gz
> # CONFIG_SYSFS_DEPRECATED_V2 is not set
>
> If this option is set to yes, udev will fail to create devices properly.
> I
Am 10.02.2010 16:00, schrieb karolina.lindqv...@kramnet.se:
> I updated my system, and then on reboot it could not find the disk /dev/sda
> anymore. A pity, since it hold the boot and root file systems. I have a
> custom
> kernel, for various reasons, but now I could not get my custom kernel, of
Thursday 28 January 2010 skrev Hussam Al-Tayeb:
> I updated to udev, cryptsetup and device mapper from testing the
> installed kernel 2.6.32.6 and rebooted.
Something similar, or the same thing, happened to me.
I updated my system, and then on reboot it could not find the disk /dev/sda
anymore.
On Thu, 2010-01-28 at 18:25 +0100, Thomas Bächler wrote:
> Am 28.01.2010 18:00, schrieb Hussam Al-Tayeb:
> > I updated to udev, cryptsetup and device mapper from testing the
> > installed kernel 2.6.32.6 and rebooted.
> > now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab
> > mentions /
Am 28.01.2010 18:00, schrieb Hussam Al-Tayeb:
> I updated to udev, cryptsetup and device mapper from testing the
> installed kernel 2.6.32.6 and rebooted.
> now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab
> mentions /dev/mapper/root
> /dev/mapper/home and /dev/dm-1 exist
> The compu
I updated to udev, cryptsetup and device mapper from testing the
installed kernel 2.6.32.6 and rebooted.
now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab
mentions /dev/mapper/root
/dev/mapper/home and /dev/dm-1 exist
The computer boots till the fsck part then stops because there is
n
Hi
I'm coming from an ubuntu background where this line in the udev.rule
file worked.
SUBSYSTEMS=="usb", ATTR{idVendor}=="0fd1", ATTR{idProduct}=="1000",
ATTR{bConfigurationValue}=="1",RUN+="/bin/bash -c 'echo 3 >
/sys/bus/usb/devices/%b/bConfigurationValue'"
However this does not work in Arch
Hi
I'm coming from an ubuntu background where this line in the udev.rule
file worked.
SUBSYSTEMS=="usb", ATTR{idVendor}=="0fd1", ATTR{idProduct}=="1000",
ATTR{bConfigurationValue}=="1",RUN+="/bin/bash -c 'echo 3 >
/sys/bus/usb/devices/%b/bConfigurationValue'"
However this does not work in Arch
It seems that devicekit will replace some functions of hal, while udev
replaces some other parts. But I don't know much further details
either. Maybe a roadmap would make all these stuff clear~
Regards
2009/12/2 Ng Oon-Ee :
> On Wed, 2009-12-02 at 03:09 +0100, vlad wrote:
>> Why is hal dead?
>> Mo
On Wed, 2009-12-02 at 03:09 +0100, vlad wrote:
> Why is hal dead?
> More information on this and on "libudev"?
>
> Vlad
I'd like to know more about this as well. The articles I've found online
seem more marketing than details orientated (udev will cook your lunch
while paying your income tax stuf
On Wednesday 21 October 2009 01:02:15 pm Dario wrote:
> The udev daemon was possessed:D
>
rotflmao :p
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
In data mercoledì 21 ottobre 2009 15:08:43, David Houston ha scritto:
> Rebooted today and the problem is gone?!?!
The udev daemon was possessed:D
ciao!
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
Rebooted today and the problem is gone?!?!
Dave
-
r...@crankyadmin.net
cra...@archlinux.us
On Tue, Oct 20, 2009 at 9:56 AM, David Houston wrote:
> Hi all,
>
> Over the last day or so, udev has been sending my system load though the
> roof?!? Nothing has changed on the system. I ha
Hi all,
Over the last day or so, udev has been sending my system load though the
roof?!? Nothing has changed on the system. I have included a screencap of
htop for your viewing pleasure. Anybody got any idea why udev is freaking
out? It is now loagging my system.
Oh yeah, problem presists after a
Aaron Griffin wrote:
> Actually, that's not the same. I have a suspicion suse's udev is far
> older, but the dir we're looking at should be /lib/udev/rules.d vs
> /etc/udev/rules.d
>
Ahah!, Your right Aaron. I missed the /lib/udev/'rules.d'. I know it has been
that way for a while, at least sinc
On Thu, Apr 23, 2009 at 11:22 AM, David C. Rankin
wrote:
> Tobias Powalowski wrote:
>> Am Mittwoch 22 April 2009 schrieb Damjan Georgievski:
>>> What is the policy for Udev rules in ArchLinux?
>>>
>>> There are 2 places where udev rules can be placed, /lib/udev/rules.d/
>>> and /etc/udev/rules.d/.
Tobias Powalowski wrote:
> Am Mittwoch 22 April 2009 schrieb Damjan Georgievski:
>> What is the policy for Udev rules in ArchLinux?
>>
>> There are 2 places where udev rules can be placed, /lib/udev/rules.d/
>> and /etc/udev/rules.d/.
>> Now, I think the /lib/ directory should be only for the rules
Aaron Griffin wrote:
> On Wed, Apr 22, 2009 at 9:19 AM, Tobias Powalowski wrote:
>
>> Am Mittwoch 22 April 2009 schrieb Damjan Georgievski:
>>
>>> What is the policy for Udev rules in ArchLinux?
>>>
>>> There are 2 places where udev rules can be placed, /lib/udev/rules.d/
>>> and /etc/udev
On Wed, Apr 22, 2009 at 9:19 AM, Tobias Powalowski wrote:
> Am Mittwoch 22 April 2009 schrieb Damjan Georgievski:
>> What is the policy for Udev rules in ArchLinux?
>>
>> There are 2 places where udev rules can be placed, /lib/udev/rules.d/
>> and /etc/udev/rules.d/.
>> Now, I think the /lib/ dire
Am Mittwoch 22 April 2009 schrieb Damjan Georgievski:
> What is the policy for Udev rules in ArchLinux?
>
> There are 2 places where udev rules can be placed, /lib/udev/rules.d/
> and /etc/udev/rules.d/.
> Now, I think the /lib/ directory should be only for the rules coming
> from upstream udev, an
What is the policy for Udev rules in ArchLinux?
There are 2 places where udev rules can be placed, /lib/udev/rules.d/
and /etc/udev/rules.d/.
Now, I think the /lib/ directory should be only for the rules coming
from upstream udev, and the /etc/ directory is for rules coming from
ArchLinux packages
On Dienstag, 10. März 2009 22:20 Thomas Bächler wrote:
> I have root:disk in /lib/udev/devices/loop/ and in /dev/loop/.
What a silly error of mine, i look only for the links and not inside of the
loop directory ... sorry.
> I am thinking about creating only /dev/loop/0 and /dev/loop0, as that is
Attila schrieb:
These devices are simply copied in rc.sysinit line 23:
/bin/cp -a /lib/udev/devices/* /dev/
udev rules are not applied until the module is loaded and a uevent for
creating the device is issued, then udev reads the rule(s) and acts
accordingly.
The funny thing what i recognized t
On Dienstag, 10. März 2009 21:06 Thomas Bächler wrote:
First, thank you very much for the excellent informations.
> The permissions of /dev/net/tun do not matter at all. If you access the
> device, you will only be able to use those interfaces that you own.
Yes, that is what i now understand bet
Attila schrieb:
If the default group of some of these devices should be changed (looks
like tun should be in the network group by default), please file a bug
report
Oh, i don't know if tun should have this permissions or if the file mask 666
is needed from another application. Until udev-139 th
On Dienstag, 10. März 2009 19:43 Jan Spakula wrote:
> This reminds of a problem Dusty had and discussed on forums:
> http://bbs.archlinux.org/viewtopic.php?id=60060
> Result: the device node was created before the rule was applied.
Thanks for the information. So i can stop searching in which star
On Dienstag, 10. März 2009 20:05 Gerardo Exequiel Pozzi wrote:
> The tun dev is statically created, and the perms are adjusted in
> /lib/udev/rules.d/50-udev-default.rules then if you need to adjust these
> perms make a file >50 in /etc/udev/rules.d/ like this:
Oh, i forgot to post the whole line
On Dienstag, 10. März 2009 19:49 Aaron Griffin wrote:
> If the default group of some of these devices should be changed (looks
> like tun should be in the network group by default), please file a bug
> report
Oh, i don't know if tun should have this permissions or if the file mask 666
is needed f
Allan McRae schrieb:
Files are removed then the new one extracted, so you should end up with
the package permissions. Shared directories are more interesting...
(you will get a warning about permission differences).
Can this be overridden with NoUpgrade or NoExtract? I would guess so.
sign
Thomas Bächler wrote:
Aaron Griffin schrieb:
tun and a few other devices (loopX) are created statically in
/lib/udev/devices/ and then placed on top of /dev/ when udev starts
up. You can modify the initial permissions of these devices there
How does pacman handle this on updates? Does it prefe
Aaron Griffin schrieb:
tun and a few other devices (loopX) are created statically in
/lib/udev/devices/ and then placed on top of /dev/ when udev starts
up. You can modify the initial permissions of these devices there
How does pacman handle this on updates? Does it prefer the mode of the
on-d
Attila wrote:
> Hi,
>
> i use a script to prepare a bridged network for a kvm session and therefore i
> have this line in /etc/udev/rules.d/01-attila.rules:
>
> KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network"
>
> After upgrading udev my file permissions of the new persistent /dev/net/tun
On Tue, Mar 10, 2009 at 1:45 PM, Aaron Griffin wrote:
> On Tue, Mar 10, 2009 at 12:51 PM, Attila wrote:
>> Hi,
>>
>> i use a script to prepare a bridged network for a kvm session and therefore i
>> have this line in /etc/udev/rules.d/01-attila.rules:
>>
>> KERNEL=="tun", NAME="net/%k", MODE="0660
On Tue, Mar 10, 2009 at 12:51 PM, Attila wrote:
> Hi,
>
> i use a script to prepare a bridged network for a kvm session and therefore i
> have this line in /etc/udev/rules.d/01-attila.rules:
>
> KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network"
>
> After upgrading udev my file permissions
Excerpts from Attila's message of Di Mär 10 18:51:15 +0100 2009:
> Hi,
>
> i use a script to prepare a bridged network for a kvm session and therefore i
> have this line in /etc/udev/rules.d/01-attila.rules:
>
> KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network"
>
> After upgrading udev
Hi,
i use a script to prepare a bridged network for a kvm session and therefore i
have this line in /etc/udev/rules.d/01-attila.rules:
KERNEL=="tun", NAME="net/%k", MODE="0660", GROUP="network"
After upgrading udev my file permissions of the new persistent /dev/net/tun
looks so after booting up:
On Wed, Aug 27, 2008 at 2:30 AM, Thomas Bächler <[EMAIL PROTECTED]> wrote:
> Aaron Griffin schrieb:
>>
>> On Tue, Aug 26, 2008 at 3:35 PM, Amanai <[EMAIL PROTECTED]> wrote:
>>>
>>> On Tue, 26 Aug 2008 13:27:32 -0700, Xavier <[EMAIL PROTECTED]> wrote:
>>>
On Tue, Aug 26, 2008 at 6:46 PM, Amanai
On Wed, Aug 27, 2008 at 3:30 PM, Thomas Bächler <[EMAIL PROTECTED]> wrote:
> Aaron Griffin schrieb:
>>
>> On Tue, Aug 26, 2008 at 3:35 PM, Amanai <[EMAIL PROTECTED]> wrote:
>>>
>>> On Tue, 26 Aug 2008 13:27:32 -0700, Xavier <[EMAIL PROTECTED]> wrote:
>>>
On Tue, Aug 26, 2008 at 6:46 PM, Amanai
Aaron Griffin schrieb:
On Tue, Aug 26, 2008 at 3:35 PM, Amanai <[EMAIL PROTECTED]> wrote:
On Tue, 26 Aug 2008 13:27:32 -0700, Xavier <[EMAIL PROTECTED]> wrote:
On Tue, Aug 26, 2008 at 6:46 PM, Amanai <[EMAIL PROTECTED]> wrote:
Is there no maintaince on udev anymore?
This is my fault. I grab
On Tue, Aug 26, 2008 at 3:35 PM, Amanai <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Aug 2008 13:27:32 -0700, Xavier <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Aug 26, 2008 at 6:46 PM, Amanai <[EMAIL PROTECTED]> wrote:
>>>
>>> Is there no maintaince on udev anymore?
>>>
>>
>> Could you be even more obscure
There was a recent news story about udev and how they want people to just
use the vanilla rules rather than go off naming all their devices in their
own way.
http://www.computerworld.com.au/index.php/id;605162254;fp;4194304;fpid;1
C
On Tue, Aug 26, 2008 at 10:49 PM, Roman Kyrylych
<[EMAIL PROTECTED]> wrote:
>
> I wouldn't say there are *exciting* changes
> (these are rare for this type of software)
> but here are the latest changes
> v125 - http://lwn.net/Articles/291028/
> v126 - http://lwn.net/Articles/292596/
>
> I think ud
2008/8/26 Xavier <[EMAIL PROTECTED]>:
> On Tue, Aug 26, 2008 at 10:35 PM, Amanai <[EMAIL PROTECTED]> wrote:
>>
>> I was just wondering, it is outdated and I didn't see any udev release
>> updates anymore. That's all.
>>
>> There is no problem with the latest version, it works.
>
> Cool, so what is
On Tue, Aug 26, 2008 at 10:35 PM, Amanai <[EMAIL PROTECTED]> wrote:
>
> I was just wondering, it is outdated and I didn't see any udev release
> updates anymore. That's all.
>
> There is no problem with the latest version, it works.
Cool, so what is so exciting in the latest version?
hamra
(Disclaimer: I did little to no research prior to posting this. HA-HA.)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amanai
> Sent: 26. august 2008 22:35
> To: General Discusson about Arch Linux
> Subject: Re: [arch-genera
On Tue, 26 Aug 2008 13:27:32 -0700, Xavier <[EMAIL PROTECTED]> wrote:
On Tue, Aug 26, 2008 at 6:46 PM, Amanai <[EMAIL PROTECTED]> wrote:
Is there no maintaince on udev anymore?
Could you be even more obscure?
Are you simply referring to the fact that udev 119 is outdated?
Did you at least t
On Tue, Aug 26, 2008 at 6:46 PM, Amanai <[EMAIL PROTECTED]> wrote:
> Is there no maintaince on udev anymore?
>
Could you be even more obscure?
Are you simply referring to the fact that udev 119 is outdated?
Did you at least try the latest version on your system and can confirm it works?
And what
Is there no maintaince on udev anymore?
Am Donnerstag, 13. März 2008 schrieb Neil Darlow:
> Hi,
>
> Is it safe to delete /etc/udev/rules.d/udev.rules.pacsave following the
> update?
>
> Regards,
> Neil Darlow
yes all shoould be covered by the new rules files,
if you have concerns or breakage keep it as backup.
greetings
tpowa
--
Tobi
Hi,
Is it safe to delete /etc/udev/rules.d/udev.rules.pacsave following the
update?
Regards,
Neil Darlow
91 matches
Mail list logo
