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
> 2009/3/10 Sergey Manucharian
>
> > Hi folks,
> >
> > I wonder if anybody else is experiencing such a problem.
> > Here in USA the Daylight Saving time started from the last Sunday,
> > and my box has switched the clock properly. But then I found that
> > every time when I suspend my ThinkPad R6
Gerardo Exequiel Pozzi wrote:
> Pierre Schmitz wrote:
>
>> Does anybody know what this message in dmesg is about? Was syslog-ng
>> compiled
>> for i686?
>>
>> warning: `syslog-ng' uses 32-bit capabilities (legacy support in use)
>>
>>
>>
> Very out-of-date libcap, not only syslog-ng, a
I though arch was saving the clock state at shutdown, so the computer's
internal clock was in sync with what the OS had.
But maybe the bios has a DST hardcoded in it?
2009/3/10 Sergey Manucharian
> Hi folks,
>
> I wonder if anybody else is experiencing such a problem.
> Here in USA the Dayligh
Hi folks,
I wonder if anybody else is experiencing such a problem.
Here in USA the Daylight Saving time started from the last Sunday, and
my box has switched the clock properly. But then I found that every time
when I suspend my ThinkPad R61 and bring it back to life the clock is
switched back to
Pierre Schmitz wrote:
> Does anybody know what this message in dmesg is about? Was syslog-ng compiled
> for i686?
>
> warning: `syslog-ng' uses 32-bit capabilities (legacy support in use)
>
>
Very out-of-date libcap, not only syslog-ng, also proftpd, vsftpd,
pulseaudio, ntpd, virtualbox, etc, e
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:
Damjan Georgievski schrieb:
I tested this on a minimal ArchLinux I installed in a virtual machine.
/var/lib/misc/ was not present on that install so rc.shutdown
complained, and the random-seed file of course wasn't created.
Uh, that needs to be fixed. initscripts is in core already, so you were
21 matches
Mail list logo
