On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald wrote:
> /usr/share/doc/systemd/README.Fedora-18
>
> - A hacky workaround that allows udev to rename network interfaces into
> kernel's ethX namespace has been re-added. This is to support users who
> still
> rely on udev rules such as 70-persist
Am 11.04.2013 11:25, schrieb Andrey Borzenkov:
> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald wrote:
>> /usr/share/doc/systemd/README.Fedora-18
>>
>> - A hacky workaround that allows udev to rename network interfaces into
>> kernel's ethX namespace has been re-added. This is to support users
'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald wrote:
>> /usr/share/doc/systemd/README.Fedora-18
>>
>> - A hacky workaround that allows udev to rename network interfaces into
>> kernel's ethX namespace has been re-added
Hello,
This is a default fedore 18 machine with default kernel. Kernel came
with the F18 disto, no changes. No special things like LXC/OpenVZ. So
I guess no 3rd party mount any cgroup.
>then systemd itself will mount all the resource controllers
that are compiled into the kernel.
How ?
I don't kn
Am 11.04.2013 12:41, schrieb Colin Guthrie:
> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>> wrote:
>>> /usr/share/doc/systemd/README.Fedora-18
>>>
>>> - A hacky workaround that allows udev to rename network interf
On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald wrote:
> in real life there are THOUSANDS of setups with only one ethernet interface
> there are THOUSANDS of virtual machines with only one network interface
In these cases you can disable persistent interface naming and they
will stay at eth0.
>
From: Harald Hoyer
If the key file cannot be accessed, we can at least ask for the
password.
---
src/cryptsetup/cryptsetup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index ae4aa8d..29b0dae 100644
--- a/src/cryptsetup/cryp
From: Harald Hoyer
Also clarify rd.luks.uuid and luks.uuid in the manual.
https://bugzilla.redhat.com/show_bug.cgi?id=905683
---
man/kernel-command-line.xml | 2 ++
man/systemd-cryptsetup-generator.xml | 26 +-
src/cryptsetup/cryptsetup-generator.c | 22 +
Am 11.04.2013 13:02, schrieb Tom Gundersen:
> On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald
> wrote:
>> there are THOUSANDS of virtual machines with only two NICs and no
>> race-problems
>
> In the case where no renaming is done at all, and it JustWorks, then
> you can still disable persist
'Twas brillig, and Reindl Harald at 11/04/13 11:55 did gyre and gimble:
>
>
> Am 11.04.2013 12:41, schrieb Colin Guthrie:
>> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>>> wrote:
/usr/share/doc/systemd/READM
'Twas brillig, and Reindl Harald at 11/04/13 12:10 did gyre and gimble:
>
>
> Am 11.04.2013 13:02, schrieb Tom Gundersen:
>> On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald
>> wrote:
>>> there are THOUSANDS of virtual machines with only two NICs and no
>>> race-problems
>>
>> In the case where
Am 11.04.2013 12:55, schrieb Reindl Harald:
>
>
> Am 11.04.2013 12:41, schrieb Colin Guthrie:
>> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>>> wrote:
/usr/share/doc/systemd/README.Fedora-18
- A ha
Am 11.04.2013 13:13, schrieb Colin Guthrie:
> Any scripts that assume names are also broken by design and should
> really be written better to deal with things more gracefully, although I
> totally agree that breaking existing setups is bad
aha and WHAT should scripts calling tons of cli-command
Am 11.04.2013 13:13, schrieb Colin Guthrie:
> But regardless, unless the patch to allow renaming is carried locally in
> the distro for a long time
> (http://pkgs.fedoraproject.org/cgit/systemd.git/tree/0005-F18-Revert-udev-network-device-renaming-immediately-.patch?h=f18)
> then eventually the sup
Am 11.04.2013 13:27, schrieb Harald Hoyer:
> Just add "net.ifnames=0 biosdevname=0" to the kernel command line and you
> don't
> need any 70-persistent-net.rules. Udev will not try to rename your interfaces.
>
> $ rpm -qf /lib/udev/rename_device
> initscripts-9.45-2.fc19.x86_64
>
> kicks in an
'Twas brillig, and Harald Hoyer at 11/04/13 12:27 did gyre and gimble:
> Am 11.04.2013 12:55, schrieb Reindl Harald:
>>
>>
>> Am 11.04.2013 12:41, schrieb Colin Guthrie:
>>> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
On Thu, Apr 11, 2013 at 2:50 AM, Reindl Haral
Am 11.04.2013 13:46, schrieb Colin Guthrie:
> 'Twas brillig, and Harald Hoyer at 11/04/13 12:27 did gyre and gimble:
>> Only
>> $ rpm -qf /lib/udev/rename_device
>> initscripts-9.45-2.fc19.x86_64
>>
>> kicks in and renames interfaces according to the ifcfg-* files, if HWADDR is
>> set, and if the
On Thu, Apr 11, 2013 at 12:41 PM, Colin Guthrie wrote:
> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>> wrote:
>>> /usr/share/doc/systemd/README.Fedora-18
>>>
>>> - A hacky workaround that allows udev to rename netw
On Thu, Apr 11, 2013 at 1:46 PM, Colin Guthrie wrote:
> Should we then consider trying to push a new default name scheme into
> the kernel side such that they come up as "eth-ng0" etc. by default
> allowing any userspace stuff to rename them to "eth1" or whatever
> without so much likelihood of s
'Twas brillig, and Kay Sievers at 11/04/13 12:51 did gyre and gimble:
> On Thu, Apr 11, 2013 at 1:46 PM, Colin Guthrie wrote:
>
>> Should we then consider trying to push a new default name scheme into
>> the kernel side such that they come up as "eth-ng0" etc. by default
>> allowing any userspace
From: Harald Hoyer
When using "-p" and "-b" in combination with "-u", the output is not
what you would expect. The reason is the sd_journal_add_disjunction()
call in add_matches_for_unit() and add_matches_for_user_unit(), which
adds two ORs without taking the other conditions to every OR.
Adding
From: Harald Hoyer
Also clarify rd.luks.uuid and luks.uuid in the manual.
https://bugzilla.redhat.com/show_bug.cgi?id=905683
---
Fixed some whitespace error.
man/kernel-command-line.xml | 2 ++
man/systemd-cryptsetup-generator.xml | 26 +-
src/cryptsetup/c
On Thu, Apr 11, 2013 at 12:46 PM, Kevin Wilson wrote:
> Hello,
> This is a default fedore 18 machine with default kernel. Kernel came
> with the F18 disto, no changes. No special things like LXC/OpenVZ. So
> I guess no 3rd party mount any cgroup.
>
>>then systemd itself will mount all the resource
Thanks!
KV
On Thu, Apr 11, 2013 at 5:37 PM, Kay Sievers wrote:
> On Thu, Apr 11, 2013 at 12:46 PM, Kevin Wilson wrote:
>> Hello,
>> This is a default fedore 18 machine with default kernel. Kernel came
>> with the F18 disto, no changes. No special things like LXC/OpenVZ. So
>> I guess no 3rd part
This tool reads modules.devname from the current kernel directory and writes
the information
out in the tmpfiles format so that systemd-tmpfiles can use this to create the
required device
nodes before systemd-udevd is started on boot.
This makes sure nothing but kmod reads the private files unde
systemd-tmpfiles has had support for creation of static nodes for some time (to
replace copying nodes from /lib/udev/). Make sure these nodes are created before
udev is started.
Also, drop support for creating static nodes based on modules.devname from
systemd-udevd. This allows it to run witohut
On Thu, Apr 11, 2013 at 05:47:55PM +0200, Tom Gundersen wrote:
> This tool reads modules.devname from the current kernel directory and writes
> the information
> out in the tmpfiles format so that systemd-tmpfiles can use this to create
> the required device
> nodes before systemd-udevd is starte
On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi wrote:
> restarting it once it fails
Is "it" the socket or the service?
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedeskto
Op 11 apr. 2013, om 21:09 heeft David Strauss het
volgende geschreven:
> On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi
> wrote:
>> restarting it once it fails
>
> Is "it" the socket or the service?
socket
___
systemd-devel mailing list
systemd-devel
2013/4/11 Koen Kooi :
>> On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi
>> wrote:
>>> restarting it once it fails
>>
>> Is "it" the socket or the service?
>
> socket
I believe I experienced this with PHP-FPM when I injected the sockets
by abusing PHP-FPM's internal env var method for preserving soc
On Mon, Apr 8, 2013 at 3:45 PM, Linda Walsh wrote:
> Is it something that systemd needed to have? I.e. if it is made
> private would systemd care? If not, why would it have
> been made shared?
>
> Maybe a default in mount for root changed?
Having the default mount propagation be "shared" solves
Here is the commit with some background:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
On Thu, Apr 11, 2013 at 11:42 PM, David Strauss wrote:
> On Mon, Apr 8, 2013 at 3:45 PM, Linda Walsh wrote:
>> Is it something that systemd needed to have? I.
I posted this to another, related thread, but here's the relevant
commit and reasoning:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
On Tue, Apr 9, 2013 at 5:15 AM, Tetsuo Handa
wrote:
> Andrey Borzenkov wrote:
>> This seems to be yest another fa
It does seem like an inconsistency. I'm guessing it's just not
implemented. We don't have instance support yet for mounts, and that's
because it's hard to do in a way that preserves consistency and
flexibility. I can't think of any reason why that would be the case
for instance services + *.d overr
34 matches
Mail list logo