Re: [systemd-devel] systemd-networkd bridge with DHCP working
systemd-networkd bridge dhcp OK https://bugzilla.redhat.com/attachment.cgi?id=877526 poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] README: Correct EFI requirements
systemd does not need or use CONFIG_EFI_VARS anywhere, this should be CONFIG_EFIVAR_FS instead. --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index ace13cf..b0bf5e8 100644 --- a/README +++ b/README @@ -80,7 +80,7 @@ REQUIREMENTS: CONFIG_SCHED_DEBUG For UEFI systems: - CONFIG_EFI_VARS + CONFIG_EFIVAR_FS CONFIG_EFI_PARTITION Note that kernel auditing is broken when used with systemd's -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Fri, Mar 21, 2014 at 9:47 PM, Henrik /KaarPoSoft wrote: > THANK YOU VERY MUCH! > > Yes, it works now for me. > > Logs attached. Awesome, thank's for testing! > I was busy with something else, so only watched the list and git with half > an eye. > However, I find it disturbing that DHCP is attempted first on the "wrong" > MAC, only to be killed and restarted on the "right" MAC. > Is this really the best way of solving this ??? Well, I couldn't come up with anything better at the moment. But suggestions welcome of course. What we should keep in mind here though is that we never know when all the device that should be enslaved by a bridge have appeared, so we never know when the bridge has received its final mac address. Moreover, if devices are removed from the bridge, the mac address may change again, so we anyway need to be able to handle this case. What we could do is to force the mac address when creating the bridge to one we invent ourselves, which (if I read the kernel code correctly) should then become permanent. However, we still need to deal with the address changing if the bridge was not created by us. And if people are actually relying on the kernel's logic of using one of the slave macs as the bridge mac that would obviously break... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On 03/21/2014 07:03 PM, Tom Gundersen wrote: On Tue, Mar 18, 2014 at 10:38 AM, Henrik /KaarPoSoft wrote: On 03/18/2014 10:10 AM, Tom Gundersen wrote: On Tue, Mar 18, 2014 at 10:00 AM, Henrik /KaarPoSoft wrote: On 03/18/2014 09:18 AM, Henrik /KaarPoSoft wrote: On 03/17/2014 10:32 PM, Tom Gundersen wrote: On Mon, Mar 17, 2014 at 10:21 PM, Henrik /KaarPoSoft wrote: Hi Tom, Thanks for your feedback... I was briefly looking through git commits after 211 without finding anything related. But then again I did not look into too much detail. Do you know which commit would solve this? Ah, this was not obvious at all. This was almost certainly fixed as a side-effect of refactoring the rtnl_message_read_*() code, so if you pull in 9842de0d93d and the commits it relies on that should do it (I haven't verified that that's the culprit, but it seems likely from looking at it). Cheers, Tom Tom, As far as I can see, 9842de0d93d was already included in 211. I have rebuild my systemd from the head of git 4dd5da7f. And the problem remains )))-: /Henrik As a quick hack, I tried this: cat > /etc/systemd/network/42-br0.link< Yeah, that's not going to fly. Could you attach the full debug output of a failing run? To get it, you probably want to stop systemd-networkd, "ip link del" the bridge, and start networkd from the commandline: # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd I think I understand what's going on, but I'd like to have it verified before changing anything. Cheers, Tom I guess running from the commandline should not be necessary since I have [Service] Environment=SYSTEMD_LOG_LEVEL=debug in /etc/systemd/system/systemd-networkd.service.d/debug.conf Hi Henrik, Thanks for the bug report. Could you try again with current git to see if the problem is now solved for you? Cheers, Tom Tom, THANK YOU VERY MUCH! Yes, it works now for me. Logs attached. I was busy with something else, so only watched the list and git with half an eye. However, I find it disturbing that DHCP is attempted first on the "wrong" MAC, only to be killed and restarted on the "right" MAC. Is this really the best way of solving this ??? /Henrik systemd GIT b5db00e52ee2e20578839e4e4488f7b9af9abc38 journalctl -b _SYSTEMD_UNIT=systemd-networkd.service|cat Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: timestamp of '/etc/systemd/network' changed Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: timestamp of '/run/systemd/network' changed Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: br0: creating netdev Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: eno1: found matching network '/etc/systemd/network/44-en.network' Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: eno1: requesting link status Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: eno1: enslaving by 'br0' Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: eno1: link (with ifindex 2) added Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: enp11s0: found matching network '/etc/systemd/network/50-dhcp.network' Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: enp11s0: requesting link status Mar 21 21:38:27 komplett-21 systemd-networkd[2682]: enp11s0: bringing link up Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: enp11s0: link (with ifindex 3) added Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: found matching network '/etc/systemd/network/46-br0.network' Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: requesting link status Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: bringing link up Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: link (with ifindex 5) added Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: lo: link (with ifindex 1) added Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: sit0: link (with ifindex 4) added Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: link already exists, ignoring Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: netdev ready Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: enslaving link 'eno1' Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: MAC address: 1e:ac:96:2e:3d:25 Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: br0: link status updated: -> 0x1002 Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: eno1: MAC address: 10:bf:48:d7:68:e1 Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: eno1: link status updated: -> 0x1002 Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: enp11s0: MAC address: 10:bf:48:d7:64:aa Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: enp11s0: link status updated: -> 0x1002 Mar 21 21:38:28 komplett-21 systemd-networkd[2682]: Got message type=method_return se
Re: [systemd-devel] [PATCH] V3 sd-ipv4ll: generate predictable addresses
On Fri, Mar 21, 2014 at 7:23 PM, Umut Tezduyar Lindskog
wrote:
> ---
> TODO |1 -
> src/libsystemd-network/sd-ipv4ll.c | 93
> +++-
> src/network/networkd-link.c| 12 +
> src/network/networkd.h |1 +
> src/shared/net-util.c | 37 ++
> src/shared/net-util.h |2 +
> src/shared/siphash24.h |2 +
> src/systemd/sd-ipv4ll.h|1 +
> src/udev/net/link-config.c | 27 +--
> 9 files changed, 127 insertions(+), 49 deletions(-)
>
> diff --git a/TODO b/TODO
> index 50d67f7..b894e23 100644
> --- a/TODO
> +++ b/TODO
> @@ -660,7 +660,6 @@ Features:
> - add reduced [Link] support to .network files
> - add IPv4LL tests (inspire by DHCP)
> - add Scope= parsing option for [Network]
> - - change LL address generation and make it predictable like get_mac()
> (link-config.c)
> - have smooth transition from LL to routable address, without
> disconnecting clients.
>
> * sd-network:
> diff --git a/src/libsystemd-network/sd-ipv4ll.c
> b/src/libsystemd-network/sd-ipv4ll.c
> index 689dce9..155c315 100644
> --- a/src/libsystemd-network/sd-ipv4ll.c
> +++ b/src/libsystemd-network/sd-ipv4ll.c
> @@ -24,6 +24,7 @@
> #include
>
> #include "util.h"
> +#include "siphash24.h"
> #include "list.h"
>
> #include "ipv4ll-internal.h"
> @@ -76,6 +77,8 @@ struct sd_ipv4ll {
> usec_t defend_window;
> int next_wakeup_valid;
> be32_t address;
> +struct random_data *random_data;
> +char *random_data_state;
> /* External */
> be32_t claimed_address;
> struct ether_addr mac_addr;
> @@ -128,30 +131,27 @@ static int ipv4ll_stop(sd_ipv4ll *ll, int event) {
> return 0;
> }
>
> -static be32_t ipv4ll_pick_address(sd_ipv4ll *ll) {
> +static int ipv4ll_pick_address(sd_ipv4ll *ll, be32_t *address) {
> be32_t addr;
> +int r;
> +int32_t random;
>
> assert(ll);
> +assert(address);
> +assert(ll->random_data);
>
> -if (ll->address) {
> -do {
> -uint32_t r = random_u32() & 0x;
> -addr = htonl(IPV4LL_NETWORK | r);
> -} while (addr == ll->address ||
> -(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
> -(ntohl(addr) & 0xFF00) == 0x ||
> -(ntohl(addr) & 0xFF00) == 0xFF00);
> -} else {
> -uint32_t a = 1;
> -int i;
> -
> -for (i = 0; i < ETH_ALEN; i++)
> -a += ll->mac_addr.ether_addr_octet[i]*i;
> -a = (a % 0xFE00) + 0x0100;
> -addr = htonl(IPV4LL_NETWORK | (uint32_t) a);
> -}
> +do {
> +r = random_r(ll->random_data, &random);
> +if (r < 0)
> +return r;
> +addr = htonl((random & 0x) | IPV4LL_NETWORK);
> +} while (addr == ll->address ||
> +(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
> +(ntohl(addr) & 0xFF00) == 0x ||
> +(ntohl(addr) & 0xFF00) == 0xFF00);
>
> -return addr;
> +*address = addr;
> +return 0;
> }
>
> static int ipv4ll_timer(sd_event_source *s, uint64_t usec, void *userdata) {
> @@ -304,7 +304,9 @@ static void ipv4ll_run_state_machine(sd_ipv4ll *ll,
> IPv4LLTrigger trigger, void
> ll->claimed_address = 0;
>
> /* Pick a new address */
> -ll->address = ipv4ll_pick_address(ll);
> +r = ipv4ll_pick_address(ll, &ll->address);
> +if (r < 0)
> +goto out;
> ll->conflict++;
> ll->defend_window = 0;
> ipv4ll_set_state(ll, IPV4LL_STATE_WAITING_PROBE, 1);
> @@ -433,6 +435,36 @@ int sd_ipv4ll_get_address(sd_ipv4ll *ll, struct in_addr
> *address){
> return 0;
> }
>
> +int sd_ipv4ll_set_address_seed (sd_ipv4ll *ll, uint64_t entropy) {
> +int r;
> +
> +assert_return(ll, -EINVAL);
> +
> +free(ll->random_data);
> +free(ll->random_data_state);
> +
> +ll->random_data = new0(struct random_data, 1);
> +ll->random_data_state = new0(char, 128);
> +
> +if (!ll->random_data || !ll->random_data_state) {
> +r = -ENOMEM;
> +goto error;
> +}
> +
> +r = initstate_r((unsigned int)entropy, ll->random_data_state, 128,
> ll->random_data);
> +if (r < 0)
> +goto error;
> +
> +error:
> +if (r < 0){
> +free(ll->random_data);
> +free(ll->random_data_state);
> +ll-
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 07:14:00PM +0100, Kay Sievers wrote: > On Fri, Mar 21, 2014 at 6:24 PM, Thomas Weißschuh wrote: >> On Fri, Mar 21, 2014 at 06:04:24PM +0100, Kay Sievers wrote: >>>On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh wrote: On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: > On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: > > While trying to use the discovereable partitions stuff I ran into the > > following: > > > > Running systemd-efi-boot-generator on my machine results in: > > "Failed to read ESP partition UUID: Input/output error" > > The cause for this is that, the efi variable LoaderDevicePartUUID which > > is > > supposed to hold an UUID only contains the literal string "ESP", which > > can't be > > parsed by systemd. > > What does this say on your box? > $ cat > /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f > > Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) >>> >>> Your setup uses the *type* UUID for the EFI system partition as the >>> *object* UUID of the partition? >>> >>> If that's the case, this cannot really work, object UUIDs need to be >>> unique, created from randomness, not pre-defined. >> >> This did also seem wrong to me. So it is definitevely a broken system and no >> configuration error on my part? > > Whatever tool created the EFI system partition in the GPT table did it wrong. > > That the well-known UUIDs are translated to a string is a gnuefi lib > stupidity. You would need to change the GPT entry to have a random > object UUID, then all should work on gummiboot + systemd side. Turned out the misbehaving tool was I myself. When reading the DiscoverablePartition spec I mixed up the different types of GUIDs. (Nearly) everything is working now. Thanks a lot! > But be careful, if you have Windows installed, it might (I don't know) > have trouble when the UUID is changed. No problem here. Regards, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: dhcp: create explicit host route to gateway
On Fri, Mar 21, 2014 at 7:34 PM, Umut Tezduyar Lindskog wrote: > Hi, > > Do we also need to drop the route within dhcp_lease_lost()? Indeed, good catch. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Fri, Mar 21, 2014 at 7:02 PM, Tom Gundersen wrote:
> On Fri, Mar 21, 2014 at 9:57 AM, Patrik Flykt
> wrote:
>> On Thu, 2014-03-20 at 20:29 +0100, Tom Gundersen wrote:
>>> My proposal is:
>>>
>>> Whenever the MAC address changes under us networkd calls
>>> sd_{dhcp_client,ipv4ll}_set_mac(), and it is the libs' responsibility
>>> to then do the right thing.
>>>
>>> Currently the libs don't support this and will fail with EBUSY, so I
>>> suggest we change that into letting them restart themselves
>>> internally, and send out notifications that the lease has been lost
>>> (so networkd will drop the addresses correctly, if it has any
>>> assigned).
>>>
>>> Umut, Patrik, what do you think?
>>
>> Yes, let's fix the library to take care of a changing MAC address.
>
> I now made this change in git for both libraries.
Thanks for making the change.
>
> It seems to me that the kernel could behave better when enslaving
> devices to a bridge (i.e., bring down the bridge before changing its
> mac address, rather than first changing the mac address and then bring
> the bridge down/up), but this should be fairly robust from our side,
> regardless of what the kernel does.
>
> Cheers,
>
> Tom
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A potentially cross platform solution forprocess containment in init applications
On Fri, Mar 21, 2014 at 02:00:47PM +0800, Rong wrote: > > Also, all big Linux distributions have already switched or have > > announced that they'll switch to systemd. That's more than we ever could > > ask for, and there's nothing else for us to win. > > Indeed, systemd is taking over most major linux distributions, but > this doesn't change the fact that cgroups remains a controversial api, > and may go through major api update in the future. I think FUSE > approach is cleaner, even without talking about cross platform > compatibility. Great, I suggest you try it out and see how it works. Patches are always gladly accepted. > > I can only encourage the other Unixes to come up with their own service > > management solutions, that make use of their specific feature set in the > > best possible way, so that we get some serious competition in place > > again. > > Is there any plan for standardization on configuration file format, so > other implementations of init in linux/bsd/whatever could coexist > using the same set of conf file for daemons? I suggest you work with the different BSDs on fixing up their differences in this area first, it would be a nice thing to have. good luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: dhcp: create explicit host route to gateway
Hi, Do we also need to drop the route within dhcp_lease_lost()? Thanks On Fri, Mar 21, 2014 at 7:23 PM, Tom Gundersen wrote: > On Thu, Mar 20, 2014 at 7:53 PM, Brandon Philips wrote: >> This is a better approach that was suggested by Mike and ack'd by Tom. >> >> Some DHCP servers gives you a netmask of 255.255.255.255 so the gateway is >> not >> routable. Other DHCP client implementations look through the existing routes >> to >> figure out if they should add an explicit host route. See below for a link. >> >> However, it makes sense to just create the route explicitly whether it is >> needed or not since it is explicit, makes the dhcp route entries independent >> of >> other entries and saves us from knowing the state of the kernel tables. >> >> After patch route table on a machine with a network (common case): >> >> default via 10.0.2.2 dev ens3 >> 10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15 >> 10.0.2.2 dev ens3 scope link >> >> After patch route table on a machine without a network (this case): >> >> default via 10.240.0.1 dev ens4v1 >> 10.240.0.1 dev ens4v1 scope link >> >> The code from dhcpcd that works around this issue is on line 637. >> https://android.googlesource.com/platform/external/dhcpcd/+/master/configure.c > > Applied. Thanks a lot for doing this work! > > Cheers, > > Tom > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: dhcp: create host route if dhcp subnet is 255.255.255.255
On Thu, Mar 20, 2014 at 1:16 AM, Brandon Philips wrote: > Some DHCP servers gives you a netmask of 255.255.255.255 so gateway is > not routable. Make a host route instead. > > This fixes the issue but the implementation is very specific. It would > probably be better to check the route table first. What do you think? > > The code from dhcpcd that works around this issue is on line 637. > https://android.googlesource.com/platform/external/dhcpcd/+/master/configure.c This patch was superseded by a follow up. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: dhcp: create explicit host route to gateway
On Thu, Mar 20, 2014 at 7:53 PM, Brandon Philips wrote: > This is a better approach that was suggested by Mike and ack'd by Tom. > > Some DHCP servers gives you a netmask of 255.255.255.255 so the gateway is not > routable. Other DHCP client implementations look through the existing routes > to > figure out if they should add an explicit host route. See below for a link. > > However, it makes sense to just create the route explicitly whether it is > needed or not since it is explicit, makes the dhcp route entries independent > of > other entries and saves us from knowing the state of the kernel tables. > > After patch route table on a machine with a network (common case): > > default via 10.0.2.2 dev ens3 > 10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15 > 10.0.2.2 dev ens3 scope link > > After patch route table on a machine without a network (this case): > > default via 10.240.0.1 dev ens4v1 > 10.240.0.1 dev ens4v1 scope link > > The code from dhcpcd that works around this issue is on line 637. > https://android.googlesource.com/platform/external/dhcpcd/+/master/configure.c Applied. Thanks a lot for doing this work! Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] V3 sd-ipv4ll: generate predictable addresses
---
TODO |1 -
src/libsystemd-network/sd-ipv4ll.c | 93 +++-
src/network/networkd-link.c| 12 +
src/network/networkd.h |1 +
src/shared/net-util.c | 37 ++
src/shared/net-util.h |2 +
src/shared/siphash24.h |2 +
src/systemd/sd-ipv4ll.h|1 +
src/udev/net/link-config.c | 27 +--
9 files changed, 127 insertions(+), 49 deletions(-)
diff --git a/TODO b/TODO
index 50d67f7..b894e23 100644
--- a/TODO
+++ b/TODO
@@ -660,7 +660,6 @@ Features:
- add reduced [Link] support to .network files
- add IPv4LL tests (inspire by DHCP)
- add Scope= parsing option for [Network]
- - change LL address generation and make it predictable like get_mac()
(link-config.c)
- have smooth transition from LL to routable address, without disconnecting
clients.
* sd-network:
diff --git a/src/libsystemd-network/sd-ipv4ll.c
b/src/libsystemd-network/sd-ipv4ll.c
index 689dce9..155c315 100644
--- a/src/libsystemd-network/sd-ipv4ll.c
+++ b/src/libsystemd-network/sd-ipv4ll.c
@@ -24,6 +24,7 @@
#include
#include "util.h"
+#include "siphash24.h"
#include "list.h"
#include "ipv4ll-internal.h"
@@ -76,6 +77,8 @@ struct sd_ipv4ll {
usec_t defend_window;
int next_wakeup_valid;
be32_t address;
+struct random_data *random_data;
+char *random_data_state;
/* External */
be32_t claimed_address;
struct ether_addr mac_addr;
@@ -128,30 +131,27 @@ static int ipv4ll_stop(sd_ipv4ll *ll, int event) {
return 0;
}
-static be32_t ipv4ll_pick_address(sd_ipv4ll *ll) {
+static int ipv4ll_pick_address(sd_ipv4ll *ll, be32_t *address) {
be32_t addr;
+int r;
+int32_t random;
assert(ll);
+assert(address);
+assert(ll->random_data);
-if (ll->address) {
-do {
-uint32_t r = random_u32() & 0x;
-addr = htonl(IPV4LL_NETWORK | r);
-} while (addr == ll->address ||
-(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
-(ntohl(addr) & 0xFF00) == 0x ||
-(ntohl(addr) & 0xFF00) == 0xFF00);
-} else {
-uint32_t a = 1;
-int i;
-
-for (i = 0; i < ETH_ALEN; i++)
-a += ll->mac_addr.ether_addr_octet[i]*i;
-a = (a % 0xFE00) + 0x0100;
-addr = htonl(IPV4LL_NETWORK | (uint32_t) a);
-}
+do {
+r = random_r(ll->random_data, &random);
+if (r < 0)
+return r;
+addr = htonl((random & 0x) | IPV4LL_NETWORK);
+} while (addr == ll->address ||
+(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
+(ntohl(addr) & 0xFF00) == 0x ||
+(ntohl(addr) & 0xFF00) == 0xFF00);
-return addr;
+*address = addr;
+return 0;
}
static int ipv4ll_timer(sd_event_source *s, uint64_t usec, void *userdata) {
@@ -304,7 +304,9 @@ static void ipv4ll_run_state_machine(sd_ipv4ll *ll,
IPv4LLTrigger trigger, void
ll->claimed_address = 0;
/* Pick a new address */
-ll->address = ipv4ll_pick_address(ll);
+r = ipv4ll_pick_address(ll, &ll->address);
+if (r < 0)
+goto out;
ll->conflict++;
ll->defend_window = 0;
ipv4ll_set_state(ll, IPV4LL_STATE_WAITING_PROBE, 1);
@@ -433,6 +435,36 @@ int sd_ipv4ll_get_address(sd_ipv4ll *ll, struct in_addr
*address){
return 0;
}
+int sd_ipv4ll_set_address_seed (sd_ipv4ll *ll, uint64_t entropy) {
+int r;
+
+assert_return(ll, -EINVAL);
+
+free(ll->random_data);
+free(ll->random_data_state);
+
+ll->random_data = new0(struct random_data, 1);
+ll->random_data_state = new0(char, 128);
+
+if (!ll->random_data || !ll->random_data_state) {
+r = -ENOMEM;
+goto error;
+}
+
+r = initstate_r((unsigned int)entropy, ll->random_data_state, 128,
ll->random_data);
+if (r < 0)
+goto error;
+
+error:
+if (r < 0){
+free(ll->random_data);
+free(ll->random_data_state);
+ll->random_data = NULL;
+ll->random_data_state = NULL;
+}
+return r;
+}
+
int sd_ipv4ll_start (sd_ipv4ll *ll) {
int r;
@@ -451,8 +483,23 @@ int sd_ipv4ll_start (sd_ipv4ll *ll) {
ll->defend_window = 0;
ll->claimed_address = 0;
-if (ll->address == 0)
-
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 6:24 PM, Thomas Weißschuh wrote: > On Fri, Mar 21, 2014 at 06:04:24PM +0100, Kay Sievers wrote: >>On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh wrote: >>> On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: > While trying to use the discovereable partitions stuff I ran into the > following: > > Running systemd-efi-boot-generator on my machine results in: > "Failed to read ESP partition UUID: Input/output error" > The cause for this is that, the efi variable LoaderDevicePartUUID which > is > supposed to hold an UUID only contains the literal string "ESP", which > can't be > parsed by systemd. What does this say on your box? $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) >>> >>> $ cat >>> /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f >>> Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) >> >> Your setup uses the *type* UUID for the EFI system partition as the >> *object* UUID of the partition? >> >> If that's the case, this cannot really work, object UUIDs need to be >> unique, created from randomness, not pre-defined. > > This did also seem wrong to me. So it is definitevely a broken system and no > configuration error on my part? Whatever tool created the EFI system partition in the GPT table did it wrong. That the well-known UUIDs are translated to a string is a gnuefi lib stupidity. You would need to change the GPT entry to have a random object UUID, then all should work on gummiboot + systemd side. But be careful, if you have Windows installed, it might (I don't know) have trouble when the UUID is changed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, 21.03.14 17:24, Thomas Weißschuh (tho...@t-8ch.de) wrote: > On Fri, Mar 21, 2014 at 06:04:24PM +0100, Kay Sievers wrote: > >On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh wrote: > >> On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: > >>> On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: > >>> > While trying to use the discovereable partitions stuff I ran into the > >>> > following: > >>> > > >>> > Running systemd-efi-boot-generator on my machine results in: > >>> > "Failed to read ESP partition UUID: Input/output error" > >>> > The cause for this is that, the efi variable LoaderDevicePartUUID which > >>> > is > >>> > supposed to hold an UUID only contains the literal string "ESP", which > >>> > can't be > >>> > parsed by systemd. > >>> > >>> What does this say on your box? > >>> $ cat > >>> /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f > >>> > >>> Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) > >> > >> $ cat > >> /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f > >> Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) > > > > Your setup uses the *type* UUID for the EFI system partition as the > > *object* UUID of the partition? > > > > If that's the case, this cannot really work, object UUIDs need to be > > unique, created from randomness, not pre-defined. > > This did also seem wrong to me. So it is definitevely a broken system and no > configuration error on my part? Depends. How did the ESP get set up? Did you do that manually, or did the hw vendor do that? Some installer? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Tue, Mar 18, 2014 at 10:38 AM, Henrik /KaarPoSoft wrote: > On 03/18/2014 10:10 AM, Tom Gundersen wrote: >> >> On Tue, Mar 18, 2014 at 10:00 AM, Henrik /KaarPoSoft >> wrote: >>> >>> On 03/18/2014 09:18 AM, Henrik /KaarPoSoft wrote: On 03/17/2014 10:32 PM, Tom Gundersen wrote: > > > On Mon, Mar 17, 2014 at 10:21 PM, Henrik /KaarPoSoft > wrote: >> >> >> Hi Tom, >> >> Thanks for your feedback... >> >> I was briefly looking through git commits after 211 without finding >> anything >> related. But then again I did not look into too much detail. >> >> Do you know which commit would solve this? > > > > Ah, this was not obvious at all. This was almost certainly fixed as a > side-effect of refactoring the rtnl_message_read_*() code, so if you > pull in 9842de0d93d and the commits it relies on that should do it (I > haven't verified that that's the culprit, but it seems likely from > looking at it). > > Cheers, > > Tom > Tom, As far as I can see, 9842de0d93d was already included in 211. I have rebuild my systemd from the head of git 4dd5da7f. And the problem remains )))-: /Henrik >>> >>> >>> >>> As a quick hack, I tried this: >>> >>> cat > /etc/systemd/network/42-br0.link<>> [Match] >>> Type=bridge >>> [Link] >>> MACAddress=10:bf:48:d7:68:e1 >>> EOF >>> >>> And now I get an IP address by DHCP, and I have connectivity. >>> >>> But hard-coding the MAC is hardly a viable long-term solution... >> >> >> Yeah, that's not going to fly. >> >> Could you attach the full debug output of a failing run? To get it, >> you probably want to stop systemd-networkd, "ip link del" the bridge, >> and start networkd from the commandline: >> >> # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd >> >> I think I understand what's going on, but I'd like to have it verified >> before changing anything. >> >> Cheers, >> >> Tom >> > > I guess running from the commandline should not be necessary since I have > [Service] > Environment=SYSTEMD_LOG_LEVEL=debug > in > /etc/systemd/system/systemd-networkd.service.d/debug.conf Hi Henrik, Thanks for the bug report. Could you try again with current git to see if the problem is now solved for you? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Fri, Mar 21, 2014 at 9:57 AM, Patrik Flykt
wrote:
> On Thu, 2014-03-20 at 20:29 +0100, Tom Gundersen wrote:
>> My proposal is:
>>
>> Whenever the MAC address changes under us networkd calls
>> sd_{dhcp_client,ipv4ll}_set_mac(), and it is the libs' responsibility
>> to then do the right thing.
>>
>> Currently the libs don't support this and will fail with EBUSY, so I
>> suggest we change that into letting them restart themselves
>> internally, and send out notifications that the lease has been lost
>> (so networkd will drop the addresses correctly, if it has any
>> assigned).
>>
>> Umut, Patrik, what do you think?
>
> Yes, let's fix the library to take care of a changing MAC address.
I now made this change in git for both libraries.
It seems to me that the kernel could behave better when enslaving
devices to a bridge (i.e., bring down the bridge before changing its
mac address, rather than first changing the mac address and then bring
the bridge down/up), but this should be fairly robust from our side,
regardless of what the kernel does.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 06:04:24PM +0100, Kay Sievers wrote: >On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh wrote: >> On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: >>> On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: >>> > While trying to use the discovereable partitions stuff I ran into the >>> > following: >>> > >>> > Running systemd-efi-boot-generator on my machine results in: >>> > "Failed to read ESP partition UUID: Input/output error" >>> > The cause for this is that, the efi variable LoaderDevicePartUUID which is >>> > supposed to hold an UUID only contains the literal string "ESP", which >>> > can't be >>> > parsed by systemd. >>> >>> What does this say on your box? >>> $ cat >>> /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f >>> >>> Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) >> >> $ cat >> /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f >> Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) > > Your setup uses the *type* UUID for the EFI system partition as the > *object* UUID of the partition? > > If that's the case, this cannot really work, object UUIDs need to be > unique, created from randomness, not pre-defined. This did also seem wrong to me. So it is definitevely a broken system and no configuration error on my part? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 5:55 PM, Thomas Weißschuh wrote: > On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: >> On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: >> > While trying to use the discovereable partitions stuff I ran into the >> > following: >> > >> > Running systemd-efi-boot-generator on my machine results in: >> > "Failed to read ESP partition UUID: Input/output error" >> > The cause for this is that, the efi variable LoaderDevicePartUUID which is >> > supposed to hold an UUID only contains the literal string "ESP", which >> > can't be >> > parsed by systemd. >> >> What does this say on your box? >> $ cat >> /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f >> >> Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) > > $ cat > /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f > Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) Your setup uses the *type* UUID for the EFI system partition as the *object* UUID of the partition? If that's the case, this cannot really work, object UUIDs need to be unique, created from randomness, not pre-defined. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
Hi, On Fri, Mar 21, 2014 at 05:43:48PM +0100, Kay Sievers wrote: > On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: > > While trying to use the discovereable partitions stuff I ran into the > > following: > > > > Running systemd-efi-boot-generator on my machine results in: > > "Failed to read ESP partition UUID: Input/output error" > > The cause for this is that, the efi variable LoaderDevicePartUUID which is > > supposed to hold an UUID only contains the literal string "ESP", which > > can't be > > parsed by systemd. > > What does this say on your box? > $ cat > /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f > > Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F/2)/?/HD(Part1,SigESP) In UTF16 with the leading 4 flagbytes. Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Partition discovery broken, invalid UUID in efi variable
On Fri, Mar 21, 2014 at 8:28 AM, Thomas Weißschuh wrote: > While trying to use the discovereable partitions stuff I ran into the > following: > > Running systemd-efi-boot-generator on my machine results in: > "Failed to read ESP partition UUID: Input/output error" > The cause for this is that, the efi variable LoaderDevicePartUUID which is > supposed to hold an UUID only contains the literal string "ESP", which can't > be > parsed by systemd. What does this say on your box? $ cat /sys/firmware/efi/efivars/LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f Acpi(PNP0A03,0)/Pci(1F|2)/?/HD(Part1,Sig12AF-0666--EA27-D619) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] service: add support for reboot argument when triggered by StartLimitAction=
When rebooting with systemctl, an optional argument can be passed to the
reboot system call. This makes it possible the specify the argument in a
service file and use it when the service triggers a restart.
This is useful to distinguish between manual reboots and reboots caused by
failing services.
---
man/systemd.service.xml | 13 +
src/core/dbus-service.c | 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/service.c| 23 ++-
src/core/service.h| 1 +
5 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 5b3afb8..a2a1b6b 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -1017,6 +1017,19 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
none.
+
+RebootArgument=
+Configure the optional
+argument for the
+
reboot2
+system call if
+StartLimitAction=
+is a reboot action. This works just
+like the optional argument to
+systemctl reboot
+command.
+
+
Check
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index 0451790..45bfecf 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -50,6 +50,7 @@ const sd_bus_vtable bus_service_vtable[] = {
SD_BUS_PROPERTY("StartLimitInterval", "t", bus_property_get_usec,
offsetof(Service, start_limit.interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("StartLimitBurst", "u", bus_property_get_unsigned,
offsetof(Service, start_limit.burst), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("StartLimitAction", "s",
property_get_start_limit_action, offsetof(Service, start_limit_action),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("RebootArgument", "s", NULL, offsetof(Service,
reboot_arg), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("PermissionsStartOnly", "b", bus_property_get_bool,
offsetof(Service, permissions_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RootDirectoryStartOnly", "b", bus_property_get_bool,
offsetof(Service, root_directory_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RemainAfterExit", "b", bus_property_get_bool,
offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 55fd3da..defd66e 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -183,6 +183,7 @@ Service.WatchdogSec, config_parse_sec,
0,
Service.StartLimitInterval, config_parse_sec, 0,
offsetof(Service, start_limit.interval)
Service.StartLimitBurst, config_parse_unsigned, 0,
offsetof(Service, start_limit.burst)
Service.StartLimitAction,config_parse_start_limit_action,0,
offsetof(Service, start_limit_action)
+Service.RebootArgument, config_parse_string,0,
offsetof(Service, reboot_arg)
Service.Type,config_parse_service_type, 0,
offsetof(Service, type)
Service.Restart, config_parse_service_restart, 0,
offsetof(Service, restart)
Service.PermissionsStartOnly,config_parse_bool, 0,
offsetof(Service, permissions_start_only)
diff --git a/src/core/service.c b/src/core/service.c
index 78a2e06..9026dc5 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include "manager.h"
#include "unit.h"
@@ -2369,6 +2371,18 @@ static int service_start_limit_test(Service *s) {
if (ratelimit_test(&s->start_limit))
return 0;
+if ((s->start_limit_action == SERVICE_START_LIMIT_REBOOT ||
+ s->start_limit_action == SERVICE_START_LIMIT_REBOOT_FORCE) &&
s->reboot_arg) {
+int r;
+
+r = write_string_file(REBOOT_PARAM_FILE, s->reboot_arg);
+if (r < 0) {
+log_error("Failed to write reboot param to "
+ REBOOT_PARAM_FILE": %s", strerror(-r));
+return r;
+}
+}
+
switch (s->start_limit_action) {
case SERVICE_START_LIMIT_NONE:
@@ -2404,
Re: [systemd-devel] writing a systemd unit for nbd devices
On Fri, Mar 21, 2014 at 4:05 PM, Wouter Verhelst wrote: > > First, let me explain how NBD works. > > The client side of the NBD protocol is implemented partially in > user space, and partially in kernel space. The user space part handles > connecting and the initial protocol negotiation; but once that has been > done, nbd-client calls the NBD_DO_IT ioctl() on an open /dev/nbdX file, > which hands the socket file descriptor to the kernel and which does not > return until the device is disconnected (with "nbd-client -d", or > because the link to the server died). As such, the nbd-client process > needs to continue running while the device is connected. > > In addition, nbd-client needs to fork() and open() the /dev/nbdX device > to support partitioned NBD devices (due to a deadlock issue, that can't > be done from the initial NBD_DO_IT ioctl handling, so it is done in the > first open() instead). > But the parent nbd-client remains around, right? > For supporting root-on-NBD in conjunction with systemd, I've already > added a -systemd-mark option to nbd-client so it will make argv[0][0] > read as '@' (I think that method is slightly ugly, but that's a > discussion for another time). In Debian, I've already supported > root-on-NBD for quite a while with an initramfs script and some code in > the init script of nbd-client which adds the PID for the root NBD device > to the list of PIDs that shouldn't be killed; I understand that dracut > (and hence Fedora as well) have similar support (though I'm not sure how > well it all works). > > For non-root NBD devices, however, the situation would be slightly more > complex. This is supported in Debian by the package's init script; > AFAIK, though, no other distribution has support for that in its init > scripts (or upstart/systemd configuration, yada yada). > > Currently, in Debian, the situation is that there is a configuration > file, /etc/nbd-client, which is sourced in the init script, and which > contains bash arrays with configuration. The init script then loops over > those bash arrays and runs the appropriate nbd-client command to connect > the device. Any actual mounting (etc) of the device, then, is left to > other init scripts. It expects that filesystems on NBD devices have the > "_netdev" option in its fstab entry listed, so that it will be mounted > by the "mountnfs" rather than "mountall" init script. > > As can be expected, this took several iterations to get right in all > corner cases. It seems to be working fine now, however. > > When converting this to systemd unit files, from skimming over the > documentation, I guess I'll need something along the lines of the > following: > > - I will need to create dev-nbd@.device unit files. These unit files would > connect the device when needed. How do you determine when it is needed? >From your description I'd suggest as first step generator that mostly does the same as already done by iitscript - create generator that reads /etc/nbd-client and creates service (not device) file for every NBD device. It could be a link to common template, or separate unit - it does not really matter. - this service will simply start nbd-client as you describe above. Those services will be of Type=simple; and they probably should be After=network.target and definitely Before=remote-fs-pre.target for _netdev to work. > - It may be a good idea to move the configuration from a sourced shell > script snipped to "something else". I do want to retain some backwards > compatibility, but it's okay if that's just a program interpreting the > shell script snippet and outputting something more modern. > Generator allows you to retain existing configuration. And at the very beginning generator can be just a shell script (especially if it does not need to do more than just "ln -s"). But I suspect you will need at least pass information about NBD server and I presume it may be different for each device, right? > I do foresee some problems, though, and I'd like to see if these are > indeed problems or whether I just need to read more documentation. I > haven't found an easy answer in the documentation that I've read, but > then maybe I haven't been looking very well. > > NBD device nodes are a bit special in that due to the way NBD devices > are connected, the device must exist at all times, even before it is > connected; I suspect (though have not actually tried) that systemd will > only try to "start" a .device unit file if the device node itself is not > there yet. For NBD, the difference between a connected device and a > not-connected one can be spotted in the apparent size of the block > device (the BLKGETSIZE64 ioctl will return 0 for a not-connected device) > and in the presence (or lack thereof) of a file /sys/block/nbdX/pid (if > it exists, it contains the PID of the nbd-client process handling the > connection; if it does not, the device is not connected), not by the > presence (or lack thereof) of the device no
Re: [systemd-devel] writing a systemd unit for nbd devices
On Fri, 21.03.14 13:05, Wouter Verhelst (wou...@debian.org) wrote:
Heya,
> The client side of the NBD protocol is implemented partially in
> user space, and partially in kernel space. The user space part handles
> connecting and the initial protocol negotiation; but once that has been
> done, nbd-client calls the NBD_DO_IT ioctl() on an open /dev/nbdX file,
> which hands the socket file descriptor to the kernel and which does not
> return until the device is disconnected (with "nbd-client -d", or
> because the link to the server died). As such, the nbd-client process
> needs to continue running while the device is connected.
The client should probably live in a service file nbd-client@.service,
that would be instantiated once for each configured nbd device.
> In addition, nbd-client needs to fork() and open() the /dev/nbdX device
> to support partitioned NBD devices (due to a deadlock issue, that can't
> be done from the initial NBD_DO_IT ioctl handling, so it is done in the
> first open() instead).
I don't follow here?
> For supporting root-on-NBD in conjunction with systemd, I've already
> added a -systemd-mark option to nbd-client so it will make argv[0][0]
> read as '@' (I think that method is slightly ugly, but that's a
> discussion for another time). In Debian, I've already supported
> root-on-NBD for quite a while with an initramfs script and some code in
> the init script of nbd-client which adds the PID for the root NBD device
> to the list of PIDs that shouldn't be killed; I understand that dracut
> (and hence Fedora as well) have similar support (though I'm not sure how
> well it all works).
Sounds good!
> Currently, in Debian, the situation is that there is a configuration
> file, /etc/nbd-client, which is sourced in the init script, and which
> contains bash arrays with configuration. The init script then loops over
> those bash arrays and runs the appropriate nbd-client command to connect
> the device. Any actual mounting (etc) of the device, then, is left to
> other init scripts. It expects that filesystems on NBD devices have the
> "_netdev" option in its fstab entry listed, so that it will be mounted
> by the "mountnfs" rather than "mountall" init script.
This sounds as if you want to convert this configuration file into
systemd units from a "generator" dynamically, so that it becomes nicely
integerated into the systemd dependency tree. That's how we handle
/etc/fstab and /etc/crypttab for example, where fstab-generator and
cryptsetup-generator create individual *.mount and cryptsetup@*.service
instances from the data in those files.
See the cryptsetup-generator and fstab-generator sources for inspiration. Also:
http://www.freedesktop.org/wiki/Software/systemd/Generators/
> - I will need to create dev-nbd@.device unit files. These unit files would
> connect the device when needed.
.device units are mostly configured in udev rules. Also, there's are no
instantiated device units.
> - It may be a good idea to move the configuration from a sourced shell
> script snipped to "something else". I do want to retain some backwards
> compatibility, but it's okay if that's just a program interpreting the
> shell script snippet and outputting something more modern.
Yeah, it sounds much better to maybe have /etc/nbdtab or so, which takes
inspiration fom /etc/fstab and /etc/crypttab, and then is converted
dynamically into systemd units with a generator (as suggested above)?
> NBD device nodes are a bit special in that due to the way NBD devices
> are connected, the device must exist at all times, even before it is
> connected; I suspect (though have not actually tried) that systemd will
> only try to "start" a .device unit file if the device node itself is not
> there yet. For NBD, the difference between a connected device and a
> not-connected one can be spotted in the apparent size of the block
> device (the BLKGETSIZE64 ioctl will return 0 for a not-connected device)
> and in the presence (or lack thereof) of a file /sys/block/nbdX/pid (if
> it exists, it contains the PID of the nbd-client process handling the
> connection; if it does not, the device is not connected), not by the
> presence (or lack thereof) of the device node itself.
OK, this looks like it is similar to the situation with loop devices,
which also exist unattached first, and only after some setup become
attached to an actual file.
systemd only exposes udev devices as .device units if they have the
"systemd" tag in udev (all block devices actually get this tag set, so
there's nothing to do here), and if they have the SYSTEMD_READY=0
property not set (or in other words, have either SYSTEMD_READY unset, or
SYSTEMD_READY=1).
Now, currently 99-systemd.rules actually contains this rule:
# Ignore nbd devices in the "add" event, with "change" the nbd is ready
ACTION=="add", SUBSYSTEM=="block", KERNEL=="nbd*", ENV{SYSTEMD_READY}="0"
This sets SYSTEMD_READY=0 for the initial "add" event, and then expects
a
[systemd-devel] writing a systemd unit for nbd devices
Hi, So, now that it looks like Debian is going to support systemd in the future, I've been looking into writing systemd units for NBD, of which I maintain the userspace both upstream and in Debian. The user space consists of two bits that matter as far as bootup is concerned: the client, and the server. For the server side, that's just a standard daemon with no particularly weird requirements. I haven't written the unit yet, but I don't expect any problems there. For the client, the situation is... slightly different, and I'd like some advise on how to best move forward. First, let me explain how NBD works. The client side of the NBD protocol is implemented partially in user space, and partially in kernel space. The user space part handles connecting and the initial protocol negotiation; but once that has been done, nbd-client calls the NBD_DO_IT ioctl() on an open /dev/nbdX file, which hands the socket file descriptor to the kernel and which does not return until the device is disconnected (with "nbd-client -d", or because the link to the server died). As such, the nbd-client process needs to continue running while the device is connected. In addition, nbd-client needs to fork() and open() the /dev/nbdX device to support partitioned NBD devices (due to a deadlock issue, that can't be done from the initial NBD_DO_IT ioctl handling, so it is done in the first open() instead). For supporting root-on-NBD in conjunction with systemd, I've already added a -systemd-mark option to nbd-client so it will make argv[0][0] read as '@' (I think that method is slightly ugly, but that's a discussion for another time). In Debian, I've already supported root-on-NBD for quite a while with an initramfs script and some code in the init script of nbd-client which adds the PID for the root NBD device to the list of PIDs that shouldn't be killed; I understand that dracut (and hence Fedora as well) have similar support (though I'm not sure how well it all works). For non-root NBD devices, however, the situation would be slightly more complex. This is supported in Debian by the package's init script; AFAIK, though, no other distribution has support for that in its init scripts (or upstart/systemd configuration, yada yada). Currently, in Debian, the situation is that there is a configuration file, /etc/nbd-client, which is sourced in the init script, and which contains bash arrays with configuration. The init script then loops over those bash arrays and runs the appropriate nbd-client command to connect the device. Any actual mounting (etc) of the device, then, is left to other init scripts. It expects that filesystems on NBD devices have the "_netdev" option in its fstab entry listed, so that it will be mounted by the "mountnfs" rather than "mountall" init script. As can be expected, this took several iterations to get right in all corner cases. It seems to be working fine now, however. When converting this to systemd unit files, from skimming over the documentation, I guess I'll need something along the lines of the following: - I will need to create dev-nbd@.device unit files. These unit files would connect the device when needed. - It may be a good idea to move the configuration from a sourced shell script snipped to "something else". I do want to retain some backwards compatibility, but it's okay if that's just a program interpreting the shell script snippet and outputting something more modern. I do foresee some problems, though, and I'd like to see if these are indeed problems or whether I just need to read more documentation. I haven't found an easy answer in the documentation that I've read, but then maybe I haven't been looking very well. NBD device nodes are a bit special in that due to the way NBD devices are connected, the device must exist at all times, even before it is connected; I suspect (though have not actually tried) that systemd will only try to "start" a .device unit file if the device node itself is not there yet. For NBD, the difference between a connected device and a not-connected one can be spotted in the apparent size of the block device (the BLKGETSIZE64 ioctl will return 0 for a not-connected device) and in the presence (or lack thereof) of a file /sys/block/nbdX/pid (if it exists, it contains the PID of the nbd-client process handling the connection; if it does not, the device is not connected), not by the presence (or lack thereof) of the device node itself. This is not the case for partitions of NBD devices, however; these will only show up after the first open(), as explained above. As such, I might need two templates: one which connects the NBD device (for a /dev/nbdX device), and one for the partition (/dev/nbdXpY) which simply depends on the regular NBD device. However, if I understand correctly, it would not seem to be possible to create an nbdX template that does not also match nbdXpY. Any thoughts? -- This end should point toward the ground if you want to go to spa
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Thu, Mar 20, 2014 at 10:58:21AM +0100, Daniel Mack wrote:
> On 03/19/2014 09:24 PM, Djalal Harouni wrote:
> > Signed-off-by: Djalal Harouni
> > ---
> > domain.c | 13 +
> > 1 file changed, 5 insertions(+), 8 deletions(-)
> >
> > diff --git a/domain.c b/domain.c
> > index d27cad2..554b4fe 100644
> > --- a/domain.c
> > +++ b/domain.c
> > @@ -183,12 +183,13 @@ struct kdbus_domain *kdbus_domain_unref(struct
> > kdbus_domain *domain)
> > return NULL;
> > }
> >
> > -static struct kdbus_domain *kdbus_domain_find(struct kdbus_domain const
> > *parent,
> > +static struct kdbus_domain *kdbus_domain_find(struct kdbus_domain *parent,
> > const char *name)
> > {
> > struct kdbus_domain *domain = NULL;
> > struct kdbus_domain *n;
> >
> > + mutex_lock(&parent->lock);
> > list_for_each_entry(n, &parent->domain_list, domain_entry) {
> > if (strcmp(n->name, name))
> > continue;
> > @@ -196,6 +197,7 @@ static struct kdbus_domain *kdbus_domain_find(struct
> > kdbus_domain const *parent,
> > domain = kdbus_domain_ref(n);
> > break;
> > }
> > + mutex_unlock(&parent->lock);
> >
> > return domain;
> > }
> > @@ -288,9 +290,6 @@ int kdbus_domain_new(struct kdbus_domain *parent, const
> > char *name,
> > atomic64_set(&d->msg_seq_last, 0);
> > idr_init(&d->user_idr);
> >
> > - if (parent)
> > - mutex_lock(&parent->lock);
> > -
> > mutex_lock(&kdbus_subsys_lock);
> >
> > /* compose name and path of base directory in /dev */
> > @@ -340,21 +339,19 @@ int kdbus_domain_new(struct kdbus_domain *parent,
> > const char *name,
> >
> > /* link into parent domain */
> > if (parent) {
>
> What if 'parent' was already unrefed at this point? That can happen any
> time as soon we give up the lock.
Ok yes, but in that case what about the first 'parent' check at line
259 ? we can also race against it? I thought that since we are at this
point, we are sure that the parent won't be unrefed!
> kdbus_domain_unref() calls kdbus_domain_disconnect(), wihch grabs
> domain->lock, so we're only safe as long as we hold the lock across all
> operations on the object, right?
Yes, you are right.
I've two questions:
1) Can we improve it in ordre to reduce the lock hold time ?
currently creating a domain will make create/disconnect/open... buses
and endpoints on the parent of that domain block, these are separated
operations on different domains.
Also it seems that now there is only support for one level of nested
domains? will this be increased?
2) What about creating custom endpoints on the bus that was already
unrefed ? IMHO this is the same scenario!
Hmm perhaps this can be improved by taking a ref ASAP and revalidate
objects by checking the "*->disconnected" ?
Thanks Daniel!
>
> Daniel
>
--
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] domain: move compose logic on its own kdbus_domain_compose_path() function
On Thu, Mar 20, 2014 at 11:01:35AM +0100, Daniel Mack wrote: > Hi, > > On 03/19/2014 09:24 PM, Djalal Harouni wrote: > > Signed-off-by: Djalal Harouni > > --- > > domain.c | 68 > > +++- > > 1 file changed, 37 insertions(+), 31 deletions(-) > > > > diff --git a/domain.c b/domain.c > > index 2e05e90..d27cad2 100644 > > --- a/domain.c > > +++ b/domain.c > > @@ -223,12 +223,44 @@ struct kdbus_domain > > *kdbus_domain_find_by_major(unsigned int major) > > return domain; > > } > > > > +/* Caller has validated parent and name arguments */ > > +static int kdbus_domain_compose_path(struct kdbus_domain *domain, > > +struct kdbus_domain *parent, > > +const char *name) > > [...] > > > + ret = kdbus_domain_compose_path(d, parent, name); > > + if (ret < 0) > > + goto exit_unlock; > > Hmm, what's the purpose of adding such a single-user function? We > generally try to avoid them, unless it really makes the code more > readable, which isn't the case here IMHO. Ok, I was planing to put that mutex inside it... Please ignore this one. -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] V2 sd-ipv4ll: generate predictable addresses
On Fri, Mar 21, 2014 at 8:46 AM, Umut Tezduyar Lindskog
wrote:
> On Thu, Mar 20, 2014 at 7:16 PM, Tom Gundersen wrote:
>> On Thu, Mar 20, 2014 at 6:52 PM, Tom Gundersen wrote:
>>> On Wed, Mar 19, 2014 at 2:36 PM, Umut Tezduyar Lindskog
>>> wrote:
---
src/libsystemd-network/sd-ipv4ll.c | 86 +---
src/network/networkd-link.c| 12 +++-
src/network/networkd.h |1 +
src/shared/net-util.c | 39 +
src/shared/net-util.h |2 +
src/systemd/sd-ipv4ll.h|1 +
src/udev/net/link-config.c | 27 +
7 files changed, 119 insertions(+), 49 deletions(-)
diff --git a/src/libsystemd-network/sd-ipv4ll.c
b/src/libsystemd-network/sd-ipv4ll.c
index c6f6e01..fbe3efd 100644
--- a/src/libsystemd-network/sd-ipv4ll.c
+++ b/src/libsystemd-network/sd-ipv4ll.c
@@ -76,6 +76,8 @@ struct sd_ipv4ll {
usec_t defend_window;
int next_wakeup_valid;
be32_t address;
+struct random_data *random_data;
+char *random_data_state;
/* External */
be32_t claimed_address;
struct ether_addr mac_addr;
@@ -130,30 +132,27 @@ static int ipv4ll_stop(sd_ipv4ll *ll, int event) {
return 0;
}
-static be32_t ipv4ll_pick_address(sd_ipv4ll *ll) {
+static int ipv4ll_pick_address(sd_ipv4ll *ll, be32_t *address) {
be32_t addr;
+int r;
+int32_t random;
assert(ll);
+assert(address);
+assert(ll->random_data);
-if (ll->address) {
-do {
-uint32_t r = random_u32() & 0x;
-addr = htonl(IPV4LL_NETWORK | r);
-} while (addr == ll->address ||
-(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK
||
-(ntohl(addr) & 0xFF00) == 0x ||
-(ntohl(addr) & 0xFF00) == 0xFF00);
-} else {
-uint32_t a = 1;
-int i;
-
-for (i = 0; i < ETH_ALEN; i++)
-a += ll->mac_addr.ether_addr_octet[i]*i;
-a = (a % 0xFE00) + 0x0100;
-addr = htonl(IPV4LL_NETWORK | (uint32_t) a);
-}
+do {
+r = random_r(ll->random_data, &random);
+if (r < 0)
+return r;
+addr = htonl((random & 0x) | IPV4LL_NETWORK);
+} while (addr == ll->address ||
+(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
+(ntohl(addr) & 0xFF00) == 0x ||
+(ntohl(addr) & 0xFF00) == 0xFF00);
-return addr;
+*address = addr;
+return 0;
}
static int ipv4ll_timer(sd_event_source *s, uint64_t usec, void
*userdata) {
@@ -306,7 +305,9 @@ static void ipv4ll_run_state_machine(sd_ipv4ll *ll,
IPv4LLTrigger trigger, void
ll->claimed_address = 0;
/* Pick a new address */
-ll->address = ipv4ll_pick_address(ll);
+r = ipv4ll_pick_address(ll, &ll->address);
+if (r < 0)
+goto out;
ll->conflict++;
ll->defend_window = 0;
ipv4ll_set_state(ll, IPV4LL_STATE_WAITING_PROBE,
1);
@@ -435,6 +436,36 @@ int sd_ipv4ll_get_address(sd_ipv4ll *ll, struct
in_addr *address){
return 0;
}
+int sd_ipv4ll_set_address_seed (sd_ipv4ll *ll, uint64_t entropy) {
+int r;
+
+assert_return(ll, -EINVAL);
+
+free(ll->random_data);
+free(ll->random_data_state);
+
+ll->random_data = new0(struct random_data, 1);
+ll->random_data_state = new0(char, 128);
+
+if (!ll->random_data || !ll->random_data_state) {
+r = -ENOMEM;
+goto error;
+}
+
+r = initstate_r((unsigned int)entropy, ll->random_data_state,
128, ll->random_data);
+if (r < 0)
+goto error;
+
+error:
+if (r < 0){
+free(ll->random_data);
+free(ll->random_data_state);
+ll->random_data = NULL;
+ll->random_data_state = NULL;
+}
+return r;
+}
+
int sd_ipv4ll_start (sd_ipv4ll *ll
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Fri, Mar 21, 2014 at 8:51 AM, Umut Tezduyar Lindskog
wrote:
> On Thu, Mar 20, 2014 at 8:29 PM, Tom Gundersen wrote:
>> On Wed, Mar 19, 2014 at 2:09 PM, Tom Gundersen wrote:
>>> On Wed, Mar 19, 2014 at 1:25 PM, poma wrote:
Still the same issue, DHCPC starts too early, before the correct MAC
address is set for the bridge.
git 7bf2f4397255bc8f6cf20a0f2adab4c984ea7d14
>>>
>>> I haven't yet gotten around to this. We probably should just restart
>>> the dhcp client if the mac address changes, for whatever reason.
>>> Unless anyone else has a better idea.
>>
>> Adding Umut as well as this problem is the same in sd-ipv4ll.
>>
>> I have now shuffled the code around a bit in git to give a clearer
>> error message when this problem is encountered. The underlying problem
>> remains though.
>>
>> My proposal is:
>>
>> Whenever the MAC address changes under us networkd calls
>> sd_{dhcp_client,ipv4ll}_set_mac(), and it is the libs' responsibility
>> to then do the right thing.
>>
>> Currently the libs don't support this and will fail with EBUSY, so I
>> suggest we change that into letting them restart themselves
>> internally, and send out notifications that the lease has been lost
>> (so networkd will drop the addresses correctly, if it has any
>> assigned).
>>
>> Umut, Patrik, what do you think?
>
> I think it is absolutely necessary to restart ipv4ll because ipv4ll
> checks for address collisions based on the link's mac address.
>
> Is there a specific reason why you don't prefer using the APIs in
> manager instead of library making decisions.
We could do either, but I thought it would be nicer to keep the magic
hidden in the library if possible.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Thu, 2014-03-20 at 20:29 +0100, Tom Gundersen wrote:
> My proposal is:
>
> Whenever the MAC address changes under us networkd calls
> sd_{dhcp_client,ipv4ll}_set_mac(), and it is the libs' responsibility
> to then do the right thing.
>
> Currently the libs don't support this and will fail with EBUSY, so I
> suggest we change that into letting them restart themselves
> internally, and send out notifications that the lease has been lost
> (so networkd will drop the addresses correctly, if it has any
> assigned).
>
> Umut, Patrik, what do you think?
Yes, let's fix the library to take care of a changing MAC address.
Cheers,
Patrik
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd bridge with DHCP not working
On Thu, Mar 20, 2014 at 8:29 PM, Tom Gundersen wrote:
> On Wed, Mar 19, 2014 at 2:09 PM, Tom Gundersen wrote:
>> On Wed, Mar 19, 2014 at 1:25 PM, poma wrote:
>>> Still the same issue, DHCPC starts too early, before the correct MAC
>>> address is set for the bridge.
>>>
>>> git 7bf2f4397255bc8f6cf20a0f2adab4c984ea7d14
>>
>> I haven't yet gotten around to this. We probably should just restart
>> the dhcp client if the mac address changes, for whatever reason.
>> Unless anyone else has a better idea.
>
> Adding Umut as well as this problem is the same in sd-ipv4ll.
>
> I have now shuffled the code around a bit in git to give a clearer
> error message when this problem is encountered. The underlying problem
> remains though.
>
> My proposal is:
>
> Whenever the MAC address changes under us networkd calls
> sd_{dhcp_client,ipv4ll}_set_mac(), and it is the libs' responsibility
> to then do the right thing.
>
> Currently the libs don't support this and will fail with EBUSY, so I
> suggest we change that into letting them restart themselves
> internally, and send out notifications that the lease has been lost
> (so networkd will drop the addresses correctly, if it has any
> assigned).
>
> Umut, Patrik, what do you think?
I think it is absolutely necessary to restart ipv4ll because ipv4ll
checks for address collisions based on the link's mac address.
Is there a specific reason why you don't prefer using the APIs in
manager instead of library making decisions.
ex: stop_ipv4ll, set_mac, start_ipv4ll.
Thanks,
Umut
>
> Cheers,
>
> Tom
>
>>> journalctl -b -u systemd-networkd
>>> ...
>>> 12:51:55 networkd[579]: timestamp of '/etc/systemd/network' changed
>>> 12:51:55 networkd[579]: timestamp of '/run/systemd/network' changed
>>> 12:51:55 networkd[579]: bridge0: creating netdev
>>> 12:51:55 networkd[579]: enp1s6: link (with ifindex 2) added
>>> 12:51:55 networkd[579]: enp1s9: link (with ifindex 3) added
>>> 12:51:55 networkd[579]: enp3s0: found matching network
>>> '/etc/systemd/network/base0.network'
>>> 12:51:55 networkd[579]: enp3s0: requesting link status
>>> 12:51:55 networkd[579]: enp3s0: enslaving by 'bridge0'
>>> 12:51:55 networkd[579]: enp3s0: link (with ifindex 4) added
>>> 12:51:55 networkd[579]: lo: link (with ifindex 1) added
>>> 12:51:55 networkd[579]: bridge0: found matching network
>>> '/etc/systemd/network/bridge0dhcp.network'
>>> 12:51:55 networkd[579]: bridge0: requesting link status
>>> 12:51:55 networkd[579]: bridge0: bringing link up
>>> 12:51:55 networkd[579]: bridge0: link (with ifindex 5) added
>>> 12:51:55 networkd[579]: bridge0: netdev ready
>>> 12:51:55 networkd[579]: bridge0: enslaving link 'enp3s0'
>>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>>> 12:51:55 networkd[579]: bridge0: link status updated: -> 0x1002
>>> 12:51:55 networkd[579]: Sent message type=method_call sender=n/a
>>> destination=org.freedesktop.DBus object=/org/freedesktop/DBus
>>> interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0
>>> error=n/a
>>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>>> 12:51:55 networkd[579]: enp3s0: link status updated: -> 0x1002
>>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>>> 12:51:55 networkd[579]: bridge0: link is up
>>> 12:51:55 networkd[579]: bridge0: carrier on
>>> 12:51:55 networkd[579]: DHCP CLIENT: set MAC address to 96:c0:ae:06:29:ce
>>> 12:51:55 networkd[579]: bridge0: acquiring DHCPv4 lease
>>> 12:51:55 networkd[579]: DHCP CLIENT: STARTED
>>> 12:51:55 networkd[579]: bridge0: link status updated: 0x1002 ->
>>> 0x00011043
>>> 12:51:55 networkd[579]: Got message type=method_return
>>> sender=org.freedesktop.DBus destination=:1.6 object=n/a interface=n/a
>>> member=n/a cookie=1 reply_cookie=1 error=n/a
>>> 12:51:55 networkd[579]: DHCP CLIENT: DISCOVER
>>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>>> 12:51:55 networkd[579]: Got message type=signal
>>> sender=org.freedesktop.DBus destination=:1.6
>>> object=/org/freedesktop/DBus interface=org.freedesktop.DBus
>>> member=NameAcquired cookie=2 reply_cookie=0 error=n/a
>>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>>> 12:51:55 networkd[579]: bridge0: MAC address: 00:12:34:56:78:30
>>> 12:51:55 networkd[579]: bridge0: carrier off
>>> 12:51:55 networkd[579]: DHCP CLIENT: STOPPED
>>> 12:51:56 networkd[579]: bridge0: link status updated: 0x00011043 ->
>>> 0x1043
>>> 12:51:56 networkd[579]: enp3s0: enslaved
>>> 12:51:56 networkd[579]: enp3s0: bringing link up
>>> 12:51:56 networkd[579]: enp3s0: link configured
>>> 12:51:56 networkd[579]: bridge0: MAC address: 00:12:34:56:78:30
>>> 12:51:56 networkd[579]: bridge0: link status updated: 0x1043 ->
>>> 0x1003
>>> 12:51:56 networkd[579]
Re: [systemd-devel] [PATCH] V2 sd-ipv4ll: generate predictable addresses
On Thu, Mar 20, 2014 at 7:16 PM, Tom Gundersen wrote:
> On Thu, Mar 20, 2014 at 6:52 PM, Tom Gundersen wrote:
>> On Wed, Mar 19, 2014 at 2:36 PM, Umut Tezduyar Lindskog
>> wrote:
>>> ---
>>> src/libsystemd-network/sd-ipv4ll.c | 86 +---
>>> src/network/networkd-link.c| 12 +++-
>>> src/network/networkd.h |1 +
>>> src/shared/net-util.c | 39 +
>>> src/shared/net-util.h |2 +
>>> src/systemd/sd-ipv4ll.h|1 +
>>> src/udev/net/link-config.c | 27 +
>>> 7 files changed, 119 insertions(+), 49 deletions(-)
>>>
>>> diff --git a/src/libsystemd-network/sd-ipv4ll.c
>>> b/src/libsystemd-network/sd-ipv4ll.c
>>> index c6f6e01..fbe3efd 100644
>>> --- a/src/libsystemd-network/sd-ipv4ll.c
>>> +++ b/src/libsystemd-network/sd-ipv4ll.c
>>> @@ -76,6 +76,8 @@ struct sd_ipv4ll {
>>> usec_t defend_window;
>>> int next_wakeup_valid;
>>> be32_t address;
>>> +struct random_data *random_data;
>>> +char *random_data_state;
>>> /* External */
>>> be32_t claimed_address;
>>> struct ether_addr mac_addr;
>>> @@ -130,30 +132,27 @@ static int ipv4ll_stop(sd_ipv4ll *ll, int event) {
>>> return 0;
>>> }
>>>
>>> -static be32_t ipv4ll_pick_address(sd_ipv4ll *ll) {
>>> +static int ipv4ll_pick_address(sd_ipv4ll *ll, be32_t *address) {
>>> be32_t addr;
>>> +int r;
>>> +int32_t random;
>>>
>>> assert(ll);
>>> +assert(address);
>>> +assert(ll->random_data);
>>>
>>> -if (ll->address) {
>>> -do {
>>> -uint32_t r = random_u32() & 0x;
>>> -addr = htonl(IPV4LL_NETWORK | r);
>>> -} while (addr == ll->address ||
>>> -(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
>>> -(ntohl(addr) & 0xFF00) == 0x ||
>>> -(ntohl(addr) & 0xFF00) == 0xFF00);
>>> -} else {
>>> -uint32_t a = 1;
>>> -int i;
>>> -
>>> -for (i = 0; i < ETH_ALEN; i++)
>>> -a += ll->mac_addr.ether_addr_octet[i]*i;
>>> -a = (a % 0xFE00) + 0x0100;
>>> -addr = htonl(IPV4LL_NETWORK | (uint32_t) a);
>>> -}
>>> +do {
>>> +r = random_r(ll->random_data, &random);
>>> +if (r < 0)
>>> +return r;
>>> +addr = htonl((random & 0x) | IPV4LL_NETWORK);
>>> +} while (addr == ll->address ||
>>> +(ntohl(addr) & IPV4LL_NETMASK) != IPV4LL_NETWORK ||
>>> +(ntohl(addr) & 0xFF00) == 0x ||
>>> +(ntohl(addr) & 0xFF00) == 0xFF00);
>>>
>>> -return addr;
>>> +*address = addr;
>>> +return 0;
>>> }
>>>
>>> static int ipv4ll_timer(sd_event_source *s, uint64_t usec, void *userdata)
>>> {
>>> @@ -306,7 +305,9 @@ static void ipv4ll_run_state_machine(sd_ipv4ll *ll,
>>> IPv4LLTrigger trigger, void
>>> ll->claimed_address = 0;
>>>
>>> /* Pick a new address */
>>> -ll->address = ipv4ll_pick_address(ll);
>>> +r = ipv4ll_pick_address(ll, &ll->address);
>>> +if (r < 0)
>>> +goto out;
>>> ll->conflict++;
>>> ll->defend_window = 0;
>>> ipv4ll_set_state(ll, IPV4LL_STATE_WAITING_PROBE,
>>> 1);
>>> @@ -435,6 +436,36 @@ int sd_ipv4ll_get_address(sd_ipv4ll *ll, struct
>>> in_addr *address){
>>> return 0;
>>> }
>>>
>>> +int sd_ipv4ll_set_address_seed (sd_ipv4ll *ll, uint64_t entropy) {
>>> +int r;
>>> +
>>> +assert_return(ll, -EINVAL);
>>> +
>>> +free(ll->random_data);
>>> +free(ll->random_data_state);
>>> +
>>> +ll->random_data = new0(struct random_data, 1);
>>> +ll->random_data_state = new0(char, 128);
>>> +
>>> +if (!ll->random_data || !ll->random_data_state) {
>>> +r = -ENOMEM;
>>> +goto error;
>>> +}
>>> +
>>> +r = initstate_r((unsigned int)entropy, ll->random_data_state, 128,
>>> ll->random_data);
>>> +if (r < 0)
>>> +goto error;
>>> +
>>> +error:
>>> +if (r < 0){
>>> +free(ll->random_data);
>>> +free(ll->random_data_state);
>>> +ll->random_data = NULL;
>>> +ll->random_data_state = NULL;
>>> +}
>>> +return r;
>>> +}
>>> +
>>> int sd_ipv4ll_start (sd_ipv4ll *ll) {
>>> int r;
>>>
>>> @@ -453,8 +484,17 @@ int sd_ipv4ll_start (sd_ipv4ll *ll) {
>>> ll->defend_window = 0;
>>> ll->claimed_address = 0;
>>>
>>> -if (ll->address
[systemd-devel] Partition discovery broken, invalid UUID in efi variable
Hi, posting here, because gummiboot doesn't seem to have a mailing list. While trying to use the discovereable partitions stuff I ran into the following: Running systemd-efi-boot-generator on my machine results in: "Failed to read ESP partition UUID: Input/output error" The cause for this is that, the efi variable LoaderDevicePartUUID which is supposed to hold an UUID only contains the literal string "ESP", which can't be parsed by systemd. The machine is booted by gummiboot v43 totally fine otherwise. Regards, Thomas pgpSOvv0uZE4l.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
