[systemd-devel] bus driver on kdbus
Lukas, Ryan, just wanted to let you know that I am working to get rid of the bus driverd in systemd after all, for kdbus. The reason is that leaving it in, as it is now, is very racy, and not just theorectically, but IRL. Ryan, you might remember the mouse cursor bug when running gnome on kdbus, we showed you two weeks ago in Nuremberg, this was caused by a race between AddMatch being processed by the driver and a subsequent method call to another service. Quite possibly, if the driver is otherwise busy the method call might get executed earlier, possibly triggering a signal, which is then not subject to the match that was to be created. This bug only showed on gdbus since only there AddMatch is called asychronously. Anyway, I fixed this now by making the requirement that driver calls are executed in order on the sender side (ie. the client translates driver bus calls into ioctls). This means the bus proxy will execute them when a legacy dbus1 client is connected, but it is expected that a native kdbus client will process them locally instead of ever letting them onto the bus. Lukas, this effectively means that your initial gdbus patch was the right way to go after all, and my request to let the driverd be in charge was quite mislead. Sorry! I will now remove the entirety of the driver daemon, not just AddMatch/RemoveMatch as all but two of those calls are subject to similar (theoretical...) races. Ryan, I know that you really don't like having to translate the bus driver calls on the client side, but I don't see any other way that fixes the race and was somewhat clean to me. Note that in our new sd-bus.h API we won't do any translations for this. We simply expect people to invoke our high-level C APIs rather than construct bus calls for the driver interfaces. We can do this, since we our C library interface is entirely new anyway. This means that the bus driver interface is thus kinda bound to using the AF_UNIX transport. And where the kdbus transports is used ioctls are the way to go. A nice side effect of this change is actually that things are a bit faster for legacy dbus1 clients. The bus driver service so far was the one service on the system so far got the most traffic during startup. With this change we can entirely eliminate this. 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 Mon, Apr 14, 2014 at 1:17 AM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: On 04/14/2014 12:34 AM, Tom Gundersen wrote: On Mon, Apr 14, 2014 at 12:12 AM, Henrik /KaarPoSoft hen...@kaarposoft.dk wrote: On 03/22/2014 10:41 AM, Tom Gundersen wrote: On Sat, Mar 22, 2014 at 5:06 AM, poma pomidorabelis...@gmail.com wrote: systemd-networkd bridge dhcp OK https://bugzilla.redhat.com/attachment.cgi?id=877526 Thanks for reporting back. Cheers, Tom Dear all, I started this thread about a month ago, having some trouble with DHCP on a bridge. Tom Gundersen worked his magic, and on Fri Mar 21 21:53:15 2014 I reported that everything worked fine out of the (then) current git. Sorry, but I did not note the exact commit sha )-: I have been using this git version since then without problems. Now I have upgraded to 212, and systemd-networkd bridge with DHCP is *NOT* working for me. See attached config and log. Any help and hints would be most appreciated. I'm pretty sure this problem was caused by d39ed and fixed by 20861. If the problem persists in current git (should not, but I have had a hard time reproducing this, so even though my tests pass it may), could you paste the same logs with an up-to-date checkout? (You can recompile and just pick out the systemd-networkd binary, shouldn't need to upgrade all of systemd if you don't want to). Thanks for reporting and sorry for the inconvenience. Cheers, Tom git a163b64c4b08e8a4ad39a9a295acf3d1634024a3 works like a charm, thank you! log attached Great. Thanks! Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bus driver on kdbus
On 04/14/2014 08:39 AM, Lennart Poettering wrote: Lukas, Ryan, Hi Lennart, Ryan just wanted to let you know that I am working to get rid of the bus driverd in systemd after all, for kdbus. The reason is that leaving it in, as it is now, is very racy, and not just theorectically, but IRL. Ryan, you might remember the mouse cursor bug when running gnome on kdbus, we showed you two weeks ago in Nuremberg, this was caused by a race between AddMatch being processed by the driver and a subsequent method call to another service. Quite possibly, if the driver is otherwise busy the method call might get executed earlier, possibly triggering a signal, which is then not subject to the match that was to be created. This bug only showed on gdbus since only there AddMatch is called asychronously. Yes, you're right, I also noticed that something is wrong with AddMatch. Anyway, I fixed this now by making the requirement that driver calls are executed in order on the sender side (ie. the client translates driver bus calls into ioctls). This means the bus proxy will execute them when a legacy dbus1 client is connected, but it is expected that a native kdbus client will process them locally instead of ever letting them onto the bus. Lukas, this effectively means that your initial gdbus patch was the right way to go after all, and my request to let the driverd be in charge was quite mislead. Sorry! Ok, so I'll prepare and upload [1] new version of my patchset for gdbus (with translating all bus calls into ioctls directly in library), as soon as it's possible. I will now remove the entirety of the driver daemon, not just AddMatch/RemoveMatch as all but two of those calls are subject to similar (theoretical...) races. Ryan, I know that you really don't like having to translate the bus driver calls on the client side, but I don't see any other way that fixes the race and was somewhat clean to me. Ryan, what do you think about it? Note that in our new sd-bus.h API we won't do any translations for this. We simply expect people to invoke our high-level C APIs rather than construct bus calls for the driver interfaces. We can do this, since we our C library interface is entirely new anyway. This means that the bus driver interface is thus kinda bound to using the AF_UNIX transport. And where the kdbus transports is used ioctls are the way to go. A nice side effect of this change is actually that things are a bit faster for legacy dbus1 clients. The bus driver service so far was the one service on the system so far got the most traffic during startup. With this change we can entirely eliminate this. Lennart [1] https://bugzilla.gnome.org/show_bug.cgi?id=721861 Thanks, -- Lukasz Skalski Samsung RD Institute Poland Samsung Electronics l.skal...@samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] networkd: ipip tunell add address support
On 04/14/2014 04:06 AM, Susant Sahani wrote: This patch extends supports to configure address for ipip tunnel patch. File: ipip.network [Match] Name=em1 [Network] Tunnel=ipip-tun Address=192.168.10.24 You might want to skip tun from ipip-tun to match modes directly ( ip tu ad ipiptun mode ipip -- local foo remote bar ttl 64 dev em1 ) or atleast remove the - so it matches the ip commands which uses ipiptun, gretun and sittun ( ip tu ad ipiptun -- mode ipip local foo remote bar ttl 64 dev em1 ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] networkd: ipip tunell add address support
On 04/14/2014 03:50 PM, Jóhann B. Guðmundsson wrote: On 04/14/2014 04:06 AM, Susant Sahani wrote: This patch extends supports to configure address for ipip tunnel patch. File: ipip.network [Match] Name=em1 [Network] Tunnel=ipip-tun Address=192.168.10.24 You might want to skip tun from ipip-tun to match modes directly ( ip tu ad ipiptun mode ipip -- local foo remote bar ttl 64 dev em1 ) or atleast remove the - so it matches the ip commands which uses ipiptun, gretun and sittun ( ip tu ad ipiptun -- mode ipip local foo remote bar ttl 64 dev em1 ) It's a name not tunnel type. Tunnel type configured in .netdev . you can put anything here . Should match the .netdev Name='XYZ' The Kind is mode which you can replace with ipip/sit/gre . file: ipip.netdev -- [NetDev] Name=ipip-tun===Name Kind=ipip == tunnel type JBG Thanks, Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] fsck: Search for fsck.type in PATH
'Twas brillig, and Mike Gilbert at 12/04/14 20:54 did gyre and gimble:
On Sat, Apr 12, 2014 at 3:10 PM, Mike Gilbert flop...@gentoo.org wrote:
On Sat, Apr 12, 2014 at 1:40 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
+static void test_fsck_exists(void) {
+/* Ensure we use a sane default for PATH. */
+unsetenv(PATH);
+
+/* fsck.minix is provided by util-linux and will probably exist.
*/
+assert(fsck_exists(minix) == 0);
+
+assert(fsck_exists(AbCdE) == -ENOENT);
+}
assert_se().
We are comparing integers, not strings. This matches the other integer
comparisons in this source file.
I guess I have misinterpreted what assert_se means... is that
documented somewhere?
the _se suffix just means side effect. So if systemd were compiled
without asserts the action would still happen (whereas a normal assert()
is totally skipped).
In this case the side effect is actually calling fsck_exists().
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] networkd: ipip tunell add address support
On 04/14/2014 10:31 AM, Susant Sahani wrote: It's a name not tunnel type. Tunnel type configured in .netdev . you can put anything here . Should match the .netdev Name='XYZ' The Kind is mode which you can replace with ipip/sit/gre . file: ipip.netdev -- [NetDev] Name=ipip-tun===Name Kind=ipip == tunnel type I thought you had switched to correct it Kind=tunnel just like you define bridging, bonding and vlan there, with Tunnel= in the network section setting the mode of the tunnel. I guess Tom just has to rule on this since to me how you are implementing things adds an additional learning curve to administrators both since it deviates from the command line as well as configuration this from /etc/net configuration perspective. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] networkd: ipip tunell add address support
On 04/14/2014 04:04 PM, Jóhann B. Guðmundsson wrote: On 04/14/2014 10:31 AM, Susant Sahani wrote: It's a name not tunnel type. Tunnel type configured in .netdev . you can put anything here . Should match the .netdev Name='XYZ' The Kind is mode which you can replace with ipip/sit/gre . file: ipip.netdev -- [NetDev] Name=ipip-tun===Name Kind=ipip == tunnel type I thought you had switched to correct it Kind=tunnel just like you define bridging, bonding and vlan there, with Tunnel= in the network section setting the mode of the tunnel. hmm . That was my original idea. You might want to check . I guess Tom just has to rule on this since to me how you are implementing things adds an additional learning curve to administrators both since it deviates from the command line as well as configuration this from /etc/net configuration perspective. Yes :) JBG Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add libkmod flags for test_rtnl_manual
--- Makefile.am | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Without CFLAGS my gcc is unable to find linkmod.h. KMOD_LIBS just look better than -lkomd for me. diff --git a/Makefile.am b/Makefile.am index 0ad1729..6767a76 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1402,10 +1402,14 @@ test_ipcrm_LDADD = \ test_rtnl_manual_SOURCES = \ src/test/test-rtnl-manual.c +test_rtnl_manual_CFLAGS = \ + $(AM_CFLAGS) \ + $(KMOD_CFLAGS) + test_rtnl_manual_LDADD = \ libsystemd-internal.la \ libsystemd-shared.la \ - -lkmod + $(KMOD_LIBS) test_ellipsize_SOURCES = \ src/test/test-ellipsize.c -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pci.ids confusion
On Sun, Apr 13, 2014 at 6:58 AM, Jerome Leclanche adys...@gmail.com wrote: This is a followup of a chat on #systemd. The pciids-devel list is dead and someone recommended I post here instead. While browsing some debug logs, I came accross a confusing message: systemd[1]: Found device M4A785TD Motherboard. I was even more confused since I don't actually have a M4A785TD but a P7P55D-E DELUXE. Turns out this is one of my two ethernet adapters. Specifically, in hwdata/pci.ids, 1019 8168 RTL8111/8168 PCI Express Gigabit Ethernet controller. Out of curiousity I started digging in the pci.ids file (10ec Realtek Semiconductor Co., Ltd. around line 9120). I'm trying to understand the format but it's looking like motherboards are a subsystem of their own ethernet adapter. This is further confirmed with lspci: 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard I'd love to submit a fix but this is very counter-intuitive. Can anyone shed some light on it? The PCI database contains a lot of wrong, mindlessly added, and inconsistent data; some strings just do not make much sense, and there seems to be not much effort to correct it. I pushed a change to show the primary string too; it is all not pretty, but should be less confusing that what you see today: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d060b62fcb4746d3758c567e9379c6728a035b66 Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bus driver on kdbus
On Mon, 14.04.14 10:48, Ryan Lortie (de...@desrt.ca) wrote: I will now remove the entirety of the driver daemon, not just AddMatch/RemoveMatch as all but two of those calls are subject to similar (theoretical...) races. It's always been somewhat clear to me that kdbus is not a reimplementation of dbus, but rather something completely different. The extent of this difference is starting to get to the point where it's distracting. Au contraire. I am pretty sure that with handling the driver client side makes things much simpler and closer to classic dbus1. I mean, previously we already had this weird confusion that some of the driver apis where handled client side (where the kernel's notifications would be converted into NameOwnerChanged), while others where handled by driverd. With moving processing of these messages to the client side everythwing becomes neatly uniform. Sending a message to the bus driver is just an alternative way for executing an ioctl. The execution order and semantics are then *exactly* the same on dbus1. We pretty much get as close to dbus1 semantics in this regard as possible. The only difference between dbus1 and kdbus here is that in dbus1 you encode your requests in a marshalled bus messagend the other time in a simple ioctl. But the execution is scheduled exactly and precisely the same way as on dbus1, and that is a great boon for compatibility. I understand that you're walking a fine line here between the existing large userbase of D-Bus and the requirements of simplicity of kernel code, but it's starting to feel like this is D-Bus only in name -- a name taken as a way of adopting the current userbase. Well, Ryan, you asked for adoption of gvariant for everything, so you require us to remarshal for all messages. Where's the precise difference between remarshalling payload messages to/from gvariant, and driver messages to/from ioctl calls? Ultimately, it's the exact same thing, whether you marshal into gvariant and call sendmsg() or whether you marshal into some struct and call ioctl(). If you have an issue with different marshallings, then we can certainly drop the gvariant thing and speak only dbus1 marshalling again, but I wasn't aware that remarshalling was something you had an issue with? ;-) If we can intellectually separate semantics from marshalling, then the new scheme really boils down to that the execution scheduling is simply turned into exactly what it was in dbus1, so we get closer to D-Bus, not further away. driver calls on the client side, but I don't see any other way that fixes the race and was somewhat clean to me. David and I discussed some possibilities in Nuremberg, including treating communications with the bus driver as special -- indeed, they already are, due to the on behalf of functionality. When a call is pending with the bus driver, other messages from the process that sent that message would be frozen. We could even improve the on behalf of API by limiting it to target clients that are currently being served by the driver. This could possibly be implemented by explicit queue control APIs in the driver (since we already have other APIs there that impact the messages that a client sees, for example). With the new scheme we can simply drop the on-behalf-of thing, everything becomes much simpler, we need no further synchronization, the right synchronization happens automatically, because we schedule things exactly as we did on dbus1. Let's not complicate this all by inventing some weird inter-peer synchronization mechanisms, and turning the bus driver into some magic thing. By doing the driver handling client side, we actually make it less magic, since talking to the bus driver is reduced to simply using a different marshalling+syscall, and that's it. We could also add proper support for match rules to the kernel... No. We are not going to marshal/demarshal things in the kernel. This is a total no-no. I haven't forgotten our discussion about the specifics of how hashing works for adding bits to the bloom filter and how we should design for change. You were able to convince me that we could do upgrades, but this argument relied on my not having to implement the specifics of the receive-side hashing in the client library, relying instead on the bus driver to do it for me. I'm no longer convinced that we can handle additions to the specification in a nice way (ie: without requiring lockstep upgrades of all of the client libraries). Hey, we devised a scheme how we can do bloom filter upgrades, and how to do this in a compatible fashion by uploading multiple filters per match, and simply checking the oldest match against the message filter, that is as new the filter is. If you follow what I mean. We have a scheme for upgrades, and it's actually relatively easy to implement. And it is followed by kdbus and sd-bus. This problem is solved, I really don't see why you need to reopen this. If you
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). So yeah, the ESP belongs on a naked GPT partition, nowhere else. And the gummiboot installer will protect the user from accidental mistakes that might turn the machine unbootable. 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] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
On 04/14/2014 06:16 PM, Lennart Poettering wrote: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). Does UEFI allow firmware to write to ESP ? If so that would indeed prevent ESP to be on soft RAID. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
В Mon, 14 Apr 2014 18:22:50 +0200 Francis Moreau francis.m...@gmail.com пишет: On 04/14/2014 06:16 PM, Lennart Poettering wrote: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). Does UEFI allow firmware to write to ESP ? Yes, it does. ESP is really not special in this respect. If so that would indeed prevent ESP to be on soft RAID. Thanks ___ 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] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
On Mon, Apr 14, 2014 at 9:22 AM, Francis Moreau francis.m...@gmail.com wrote: On 04/14/2014 06:16 PM, Lennart Poettering wrote: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). Does UEFI allow firmware to write to ESP ? If so that would indeed prevent ESP to be on soft RAID. Sure, it does. You can just start an EFI Shell and edit any file in the ESP. The only safe (at least in theory) thing is to have a bios raid driver included in the EFI firmware itself, which sets up the ESP to be the mirrored disks. With that, writes from the firmware will end up on both disks without any operating system involved. Setting up the ESP as a raid without explicit firmware support does not sound like a good idea. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Not really, because the API relies on the queue tracking data. But for the queue tracking logic to not break current setups, it would need to be updated/rewritten to handle holes in the sequence numbers; with current kernels it is just broken whenever namespaces are involved. We just did not notice, because we do not use settle with systemd. I'm not volunteering to rewrite the logic to handle holes. Instead I'm suggesting that we keep the current (as of before this commit) logic, to cater to people who use it successfully when no namespaces are involved. I don't think it is worth to try to make the specific queue tracking logic work again, it is not a useful API and it makes promises we cannot hold. I'm not suggesting that. But maybe keeping the partially broken logic around for a while might be more useful for some people than outright removal. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Mon, Apr 14, 2014 at 9:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Not really, because the API relies on the queue tracking data. But for the queue tracking logic to not break current setups, it would need to be updated/rewritten to handle holes in the sequence numbers; with current kernels it is just broken whenever namespaces are involved. We just did not notice, because we do not use settle with systemd. I'm not volunteering to rewrite the logic to handle holes. Instead I'm suggesting that we keep the current (as of before this commit) logic, to cater to people who use it successfully when no namespaces are involved. I don't think it is worth to try to make the specific queue tracking logic work again, it is not a useful API and it makes promises we cannot hold. I'm not suggesting that. But maybe keeping the partially broken logic around for a while might be more useful for some people than outright removal. It is currently broken for our own setups, unit files use namespaces in default setups. We cannot just keep the status quo and pretend it works, things are broken now and need to be fixed. We would need to rewrite the logic behind the API, or get rid of it; I decided for removal, because the assumptions the API makes are not valid anymore. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pci.ids confusion
Ah, yes. It makes a lot more sense with that change. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (M4A785TD Motherboard) Thanks! J. Leclanche On Mon, Apr 14, 2014 at 4:34 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Apr 13, 2014 at 6:58 AM, Jerome Leclanche adys...@gmail.com wrote: This is a followup of a chat on #systemd. The pciids-devel list is dead and someone recommended I post here instead. While browsing some debug logs, I came accross a confusing message: systemd[1]: Found device M4A785TD Motherboard. I was even more confused since I don't actually have a M4A785TD but a P7P55D-E DELUXE. Turns out this is one of my two ethernet adapters. Specifically, in hwdata/pci.ids, 1019 8168 RTL8111/8168 PCI Express Gigabit Ethernet controller. Out of curiousity I started digging in the pci.ids file (10ec Realtek Semiconductor Co., Ltd. around line 9120). I'm trying to understand the format but it's looking like motherboards are a subsystem of their own ethernet adapter. This is further confirmed with lspci: 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard I'd love to submit a fix but this is very counter-intuitive. Can anyone shed some light on it? The PCI database contains a lot of wrong, mindlessly added, and inconsistent data; some strings just do not make much sense, and there seems to be not much effort to correct it. I pushed a change to show the primary string too; it is all not pretty, but should be less confusing that what you see today: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d060b62fcb4746d3758c567e9379c6728a035b66 Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Mon, Apr 14, 2014 at 09:51:08AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 9:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Not really, because the API relies on the queue tracking data. But for the queue tracking logic to not break current setups, it would need to be updated/rewritten to handle holes in the sequence numbers; with current kernels it is just broken whenever namespaces are involved. We just did not notice, because we do not use settle with systemd. I'm not volunteering to rewrite the logic to handle holes. Instead I'm suggesting that we keep the current (as of before this commit) logic, to cater to people who use it successfully when no namespaces are involved. I don't think it is worth to try to make the specific queue tracking logic work again, it is not a useful API and it makes promises we cannot hold. I'm not suggesting that. But maybe keeping the partially broken logic around for a while might be more useful for some people than outright removal. It is currently broken for our own setups, unit files use namespaces in default setups. I know. We cannot just keep the status quo and pretend it works, things are broken now and need to be fixed. Yes. We would need to rewrite the logic behind the API, or get rid of it; I decided for removal, because the assumptions the API makes are not valid anymore. Yes, but udev is also used in different setups... Documenting things as deprecated is one thing, but replacing implementation by stub functions is another. People who use this functionality would probably prefer to have some time to move off it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am man/udevadm.xml src/libudev src/shared src/test src/udev
On Mon, Apr 14, 2014 at 10:03 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:51:08AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 9:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Apr 14, 2014 at 09:29:54AM -0700, Kay Sievers wrote: On Mon, Apr 14, 2014 at 8:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Apr 13, 2014 at 04:58:31PM -0700, Kay Sievers wrote: Makefile.am |6 man/udevadm.xml | 22 - src/libudev/libudev-monitor.c | 17 - src/libudev/libudev-queue-private.c | 406 src/libudev/libudev-queue.c | 302 ++ src/libudev/libudev.h | 10 src/shared/udev-util.h |2 src/test/test-libudev.c | 24 -- src/udev/udev-ctrl.c|2 src/udev/udevadm-settle.c | 131 +-- src/udev/udevd.c| 59 ++--- 11 files changed, 84 insertions(+), 897 deletions(-) New commits: commit 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f Author: Kay Sievers k...@vrfy.org Date: Sat Apr 12 22:35:50 2014 -0700 udev: remove seqnum API and all assumptions about seqnums The way the kernel namespaces have been implemented breaks assumptions udev made regarding uevent sequence numbers. Creating devices in a namespace steals uevents and its sequence numbers from the host. It confuses the udevadmin settle logic, which might block until util a timeout is reached, even when no uevent is pending. Remove any assumptions about sequence numbers and deprecate libudev's API exposing these numbers; none of that can reliably be used anymore when namespaces are involved. Hi Kay, maybe we should make the deprecation process a bit gentler: instead of ripping out the functionality in one step, instead just deprecate the functions, and allow people to use them, with the caveat that launching a namespace and creating devices in it will break this functionality. Then after a few releases, actually remove the functionality. Not everyone uses namespaces, and that'd be a nod towards those poeple. Would that be possible? Not really, because the API relies on the queue tracking data. But for the queue tracking logic to not break current setups, it would need to be updated/rewritten to handle holes in the sequence numbers; with current kernels it is just broken whenever namespaces are involved. We just did not notice, because we do not use settle with systemd. I'm not volunteering to rewrite the logic to handle holes. Instead I'm suggesting that we keep the current (as of before this commit) logic, to cater to people who use it successfully when no namespaces are involved. I don't think it is worth to try to make the specific queue tracking logic work again, it is not a useful API and it makes promises we cannot hold. I'm not suggesting that. But maybe keeping the partially broken logic around for a while might be more useful for some people than outright removal. It is currently broken for our own setups, unit files use namespaces in default setups. I know. We cannot just keep the status quo and pretend it works, things are broken now and need to be fixed. Yes. We would need to rewrite the logic behind the API, or get rid of it; I decided for removal, because the assumptions the API makes are not valid anymore. Yes, but udev is also used in different setups... Documenting things as deprecated is one thing, but replacing implementation by stub functions is another. People who use this functionality would probably prefer to have some time to move off it. It is not a stub, things will just block for any/all events now, ignoring the specific sequence numbers given in the API. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: minor typo fix
diff --git a/src/core/dbus.c b/src/core/dbus.c
index d482e6c..e9bf34c 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -918,7 +918,7 @@ static int bus_init_system(Manager *m) {
r = bus_setup_system(m, bus);
if (r 0) {
-log_error(Fauiled to set up system bus: %s, strerror(-r));
+log_error(Failed to set up system bus: %s, strerror(-r));
return 0;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
Am 14.04.2014 18:16, schrieb Lennart Poettering: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). While this is unsafe, the firmware doesn't write to the ESP during normal operation (i.e. bootup and efivar configuration). Tianocore does not write to the ESP either, if used properly. Newer versions will allow to store efivars in the image itself instead of the ESP. Manual installation of gummiboot onto the ESP using efibootmgr does in fact yield the desired results - until you use the EFI shell to modify files on the ESP, then you'll obviously corrupt it. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
On 04/14/2014 06:38 PM, Kay Sievers wrote: On Mon, Apr 14, 2014 at 9:22 AM, Francis Moreau francis.m...@gmail.com wrote: On 04/14/2014 06:16 PM, Lennart Poettering wrote: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). Does UEFI allow firmware to write to ESP ? If so that would indeed prevent ESP to be on soft RAID. Sure, it does. You can just start an EFI Shell and edit any file in the ESP. yes but I would be deliberately asking to the firmware to write to ESP in that case. The only safe (at least in theory) thing is to have a bios raid driver included in the EFI firmware itself, which sets up the ESP to be the mirrored disks. With that, writes from the firmware will end up on both disks without any operating system involved. Indeed, that gives one (and only one) reason to use fake raid over soft one unfortunately. Setting up the ESP as a raid without explicit firmware support does not sound like a good idea. Sad because I'm currently finding the gain to be able to write to ESP through the EFI shell very tiny compare to be able to have ESP mirrored. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
On 04/14/2014 08:11 PM, Thomas Bächler wrote: Am 14.04.2014 18:16, schrieb Lennart Poettering: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). While this is unsafe, the firmware doesn't write to the ESP during normal operation (i.e. bootup and efivar configuration). Unfortunately it seesms that nothing in UEFI will prevent futur firmares to change that. Actually adding a flag somehow to instruct the firmware that ESP is a read only partition would do the trick. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
