[systemd-devel] systemd and hostname supplied by DHCP
Hi systemd developers and users, The systemd 219 brought with Yocto "Fido" can't set hostname supplied by DHCP on my Beaglebone: eth0: eth0: could not bring up interface: Invalid argument eth0: gained carrier eth0: DHCPv4 address 192.168.205.87/24 via 192.168.205.1 eth0: link configured eth0: Could not set hostname: No route to host How can I fix this error? On my desktop machine (Arch Linux with systemd 225) I don't receive that error message and both use the same DHCP server. I dumped DHCP protocol to be user that DHCP contains the right hostname for both machines. Thank you very much. Ciao, Alessio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] xorg uses 100% CPU after upgrading to 226
Hi On Mon, Sep 28, 2015 at 4:56 AM, Jin Liu wrote: [...] > I tried to start X the usual way - as root, via sddm display manager. It > works fine. Seems the problem only happens when X is running as normal user. > Any directions to investigate? TBH, it sounds like an Xorg problem. Sure, it might be triggered by a slightly different DBus behavior on the systemd side, but that doesn't necessarily mean it's a bug in systemd. I have no idea why your Xserver loops, I don't know the codebase very well. It looks like your xserver never dispatches the DBus FD, but I cannot tell you why. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Slides for November USENIX/LISA tutorial on "systemd, the Next-Generation Linux System Manager"
On Sun, Sep 27, 2015 at 09:57:14PM -0700, Chaiken, Alison wrote: > > > The slides: http://she-devel.com/LISA15/LISA15_systemd.pdf > > Slides in other formats and systemd-nspawn containers in which to > perform the exercises are available as well; tune to > http://she-devel.com/ and look for "LISA15." I also plan to provide > Qemu .raw images and (potentially) VMware images. > > The tutorial logistics: > https://www.usenix.org/conference/lisa15/training-program/full-training-program#M7 > > > Dry-run on November 1 in the San Francisco Bay Area: > http://events.hackerdojo.com/event/5837791858524160-systemd-the-next-generation-linux-system-manager > > > Obviously comments are solicited. The material is licensed CC-BY-SA, > so feel free to take the whole bundle, improve it, and offer your own > class.I'm sick of speaking on this topic now, so November is my last > time. I don't understand one part: why do you say that creating a new target requires writing C++ code? Also, drop-ins are not "run-time extensions", at least in the systemd parlance, becuase they can appear both in /run (i.e. be runtime), and /etc (i.e. be static). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Please register for systemd.conf 2015 now, only 14 tickets left!
On Wed, Sep 23, 2015, 18:14 Lennart Poettering wrote: > We are close to being sold out now, only 14 tickets are still > available now. If you intend to attend, make sure to register for the > conference *now*, before it's too late and all tickets are gone. > > Register here: > > https://systemd.events/systemdconf-2015/registration > > To get an idea about the sessions offered, please see our preliminary > schedule: > > https://systemd.events/systemdconf-2015/schedule > How should users of sponsorship tickets register? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and hostname supplied by DHCP
On Mon, Sep 28, 2015 at 1:19 AM Alessio Igor Bogani < alessioigorbog...@gmail.com> wrote: > Hi systemd developers and users, > > The systemd 219 brought with Yocto "Fido" can't set hostname supplied > by DHCP on my Beaglebone: > > eth0: eth0: could not bring up interface: > Invalid argument > eth0: gained carrier > eth0: DHCPv4 address 192.168.205.87/24 via 192.168.205.1 > eth0: link configured > eth0: Could not set hostname: No route to host > "Could not set hostname: No route to host" sounds like systemd is trying to resolve and ping the provided hostname. But, it's failing, and so systemd is deciding that it's not a usable hostname. Doesn't seem related to the DHCP protocol implementation at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Git development moved to github
Am Donnerstag, den 06.08.2015, 09:07 +0200 schrieb Lennart Poettering: > On Wed, 05.08.15 22:42, Thomas Meyer (tho...@m3y3r.de) wrote: > > > Hi, > > > > Regarding > > http://lists.freedesktop.org/archives/systemd-devel/2015-June > > /032652.html > > > > "The official development > > git repository is now at github [1]. The old repository will still > > be > > back-synced" > > > > Will it? > > > > github HEAD b5a306ef73f9c31499f2d97f8b9d3db514b56a09 > > fdo HEAD 7ee7b225bd2fc3e7a3980f5fb7b10dfc6e205578 > > > > Bug or feature? > > David is doing the syncs manually, but he's currently on vacation. So why not install a cron job or even a systemd.timer unit? Or remove the old FDO mirror. > > If you want the newest git snapshot always go to the github repo. > Thanks. > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Slides for November USENIX/LISA tutorial on "systemd, the Next-Generation Linux System Manager"
Zbigniew Jędrzejewski-Szmek wrote:
I don't understand one part: why do you say that creating a new target
requires writing C++ code?
Certainly new targets don't require C++ code, as systemd is written in
C! But I was trying to say that new targets with naively expected
synchronization behavior require new code. twb and ohsix also queried
me on this point in IRC. By 'expected synchronization behavior,' I mean
that the initialization will pause until all the 'Wants'-ed services
stabilize, perhaps indicating completion by reaching passive targets.
If it is in fact possible to write a new .target unit that will serve as
a new user-defined runlevel without writing C code, then my statement is
wrong. Please someone say so, before I tell others wrong information!
Also, drop-ins are not "run-time extensions", at least in the systemd
parlance, becuase they can appear both in /run (i.e. be runtime), and
/etc (i.e. be static).
Good point. I will improve that.
Thanks Zbigniew, ohsix and twb for all your helpful comments. I will
incorporate them when I have a chance.
-- Alison
---
Alison Chaiken ali...@she-devel.com, 650-279-5600
http://{ she-devel.com, exerciseforthereader.org }
"There is expressive potential in not being together." -- Mark Volkert,
Assistant Concertmaster, San Francisco Symphony
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to bind to other drivers using systemd
On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner wrote: > I am looking for guidance on how to properly resolve driver binding > with systemd (which seems to me the best place to do that). This seems to be a too exotic and niche use case, nothing general-purpose enough to implement high-level knobs in systemd. As you mention, you could use custom udev rules to actually bind a specific driver. I don't think we want anything more abstract in systemd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to bind to other drivers using systemd
On Mon, Sep 28, 2015 at 08:06:50PM +0200, Kay Sievers wrote: > On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner wrote: > > I am looking for guidance on how to properly resolve driver binding > > with systemd (which seems to me the best place to do that). > > This seems to be a too exotic and niche use case, nothing > general-purpose enough to implement high-level knobs in systemd. These alternative drivers might be new yet, so there is no much around them, but we need to start right to avoid problems in the future. Accelerated userspace datapath is one use case that changes the default NIC driver to UIO or VFIO driver. Then you use DPDK applications for fast packet processing or use DPDK integrated Open vSwitch for switching. Consider that Open Stack (WIP), Open Shift and maybe containers can use the above setup, so isn't really a niche use case. It's pretty much a requirement for NFV projects as well. > As you mention, you could use custom udev rules to actually bind a > specific driver. I don't think we want anything more abstract in > systemd. The problem with that is we can't stop the service to roll back the driver. Or more importantly, create a dependency to, let's say, start Open vSwitch only after the ports are bound to the right driver. Or start an application that requires the NIC to be bound first. Thanks, fbl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to bind to other drivers using systemd
On Mon, Sep 28, 2015 at 8:48 PM, Flavio Leitner wrote: > On Mon, Sep 28, 2015 at 08:06:50PM +0200, Kay Sievers wrote: >> On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner wrote: >> > I am looking for guidance on how to properly resolve driver binding >> > with systemd (which seems to me the best place to do that). >> >> This seems to be a too exotic and niche use case, nothing >> general-purpose enough to implement high-level knobs in systemd. > > These alternative drivers might be new yet, so there is no much around > them, but we need to start right to avoid problems in the future. > > Accelerated userspace datapath is one use case that changes the default > NIC driver to UIO or VFIO driver. Then you use DPDK applications for > fast packet processing or use DPDK integrated Open vSwitch for switching. > > Consider that Open Stack (WIP), Open Shift and maybe containers can use > the above setup, so isn't really a niche use case. It's pretty much a > requirement for NFV projects as well. > >> As you mention, you could use custom udev rules to actually bind a >> specific driver. I don't think we want anything more abstract in >> systemd. > > The problem with that is we can't stop the service to roll back the > driver. Or more importantly, create a dependency to, let's say, > start Open vSwitch only after the ports are bound to the right driver. > Or start an application that requires the NIC to be bound first. Sure, I understand all that. I would still call all that a niche and I still don't think it's systemd's job to solve such a problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Slides for November USENIX/LISA tutorial on "systemd, the Next-Generation Linux System Manager"
On Mon, Sep 28, 2015 at 10:47:43AM -0700, Chaiken, Alison wrote: > Zbigniew Jędrzejewski-Szmek wrote: > >I don't understand one part: why do you say that creating a new target > >requires writing C++ code? > > If it is in fact possible to write a > new .target unit that will serve as a new user-defined runlevel > without writing C code, then my statement is wrong. Please someone > say so, before I tell others wrong information! Yeah, it is definitely possible to create a new *target*... Simply create a new .target dir, put some symlinks there, and then possibly modify some units to be After= the new target. OTOH, with *run-levels*, the situation is more complicated, because run-levels are nowadays hardcoded to correspond to specific targets, so indeed adding a new run-level would probably require modifications to the source. But your slide said "targets". > >Also, drop-ins are not "run-time extensions", at least in the systemd > >parlance, becuase they can appear both in /run (i.e. be runtime), and > >/etc (i.e. be static). > > Good point. I will improve that. > > Thanks Zbigniew, ohsix and twb for all your helpful comments. I > will incorporate them when I have a chance. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to bind to other drivers using systemd
I wonder if this could be handled with a generic Type=oneshot, ExecStart=driverctl bind foo... -- Mantas Mikulėnas On Sep 28, 2015 21:48, "Flavio Leitner" wrote: > On Mon, Sep 28, 2015 at 08:06:50PM +0200, Kay Sievers wrote: > > On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner > wrote: > > > I am looking for guidance on how to properly resolve driver binding > > > with systemd (which seems to me the best place to do that). > > > > This seems to be a too exotic and niche use case, nothing > > general-purpose enough to implement high-level knobs in systemd. > > These alternative drivers might be new yet, so there is no much around > them, but we need to start right to avoid problems in the future. > > Accelerated userspace datapath is one use case that changes the default > NIC driver to UIO or VFIO driver. Then you use DPDK applications for > fast packet processing or use DPDK integrated Open vSwitch for switching. > > Consider that Open Stack (WIP), Open Shift and maybe containers can use > the above setup, so isn't really a niche use case. It's pretty much a > requirement for NFV projects as well. > > > As you mention, you could use custom udev rules to actually bind a > > specific driver. I don't think we want anything more abstract in > > systemd. > > The problem with that is we can't stop the service to roll back the > driver. Or more importantly, create a dependency to, let's say, > start Open vSwitch only after the ports are bound to the right driver. > Or start an application that requires the NIC to be bound first. > > Thanks, > fbl > > ___ > 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
[systemd-devel] Simple oneshot service before switching root leads to no /var mount
I'm rolling my own initrd, and I'm trying to run a oneshot service in initrd just before the switch root happens. I added this unit to the initrd and enabled it. [Unit] Description=Test Unit Requires=initrd-fs.target After=initrd-fs.target [Service] Type=oneshot ExecStart=/bin/sh -c "echo hello" [Install] RequiredBy=initrd-switch-root.target The service does run, and I get "hello" in the journal, but then my /var mount doesn't mount. I'm having a hard time correlating the two seeming different things. The var.mount unit complains about a failed dependency. It's dependency is dev-disk-by\x2dpartlabel-varfs.device, which has no logs, is loaded, but inactive (dead). There is also a fsck dependency that is loaded, but inactive (dead). Without this simple oneshot service in initrd, everything works fine, fsck checks varfs and /var is mounted. Thoughts? Is there a better way to position a service to just before switch root?___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
