When the code for generating resolv.conf was moved from networkd to
resolved the DHCP domain name code was dropped.
---
src/network/networkd-link.c| 2 ++
src/network/sd-network.c | 4
src/resolve/resolved-link.c| 31 +++
src/resolve/resolved-link.h
Probably a left-over from when router solicitations were
requested in the DHCP6 code. But since they are now separate,
this state is no longer needed.
Signed-off-by: Dan Williams
---
src/libsystemd-network/dhcp6-protocol.h | 1 -
src/libsystemd-network/sd-dhcp6-client.c | 4
2 files chang
All routes added by networkd are currently set RTPROT_BOOT, which according
to the kernel means "Route installed during boot" (rtnetlink.h). But this
is not always the case as networkd changes routing after boot too. Since
the kernel gives more detailed protocols, use them.
With this patch, user
All routes added by networkd are currently set RTPROT_BOOT, which according
to the kernel means "Route installed during boot" (rtnetlink.h). But this
is not always the case as networkd changes routing after boot too. Since
the kernel gives more detailed protocols, use them.
With this patch, user
On Mon, Jul 21, 2014, at 09:43 AM, Lennart Poettering wrote:
>
> I am pretty strongly against this. Making this administrator
> configurable apepars very wrong, this really should be a decision for
> the distribution vendor, and that's it.
You list one concern below, are there others?
> We shoul
Hi,
> You were looking for the "noauto" option for crypttab (it's in the manpage,
> btw).
> The unit will then only get activated when the automount point is accessed.
> As far
> as I know, this will only work if the corresponding fstab device is from
> /dev/mapper/.
Oh, wow. I wonder how I misse
Hi,
> When "foo@bar.service" is accessed, systemd first searches for the
> exact name "foo@bar.service", and only then for "foo@.service", to
> allow certain instances to be customized.
>
> Since systemd-cryptsetup@.service is only used through the cryptsetup
> generator, and since there are quit
'Twas brillig, and Lennart Poettering at 22/07/14 12:10 did gyre and gimble:
>> > I guess it's OK to do this kind of user lookup stuff from the journal
>> > code (i.e. server_fix_perms())?
> Hmm, yuck. Actually it is really difficult
> ...
> Bummer, not sure if we can save this idea...
Yeah, I
At Tuesday 22 July 2014 13:01:24 Lennart Poettering wrote:
> I am totally not convinced this would be a good idea. You cannot fix
> this anyway... Think about udevd: if you start it without /usr is
> around, then it won't find the rules files below /usr. So by your logic
> you'd add a RequiresMount
On Mon, 21.07.14 23:44, Colin Guthrie (gm...@colin.guthr.ie) wrote:
>
> 'Twas brillig, and Lennart Poettering at 21/07/14 23:28 did gyre and gimble:
> > On Mon, 21.07.14 15:43, Lennart Poettering (lenn...@poettering.net) wrote:
> >
> >>> While I appreciate sysusers is intended primarily for boot
On Tue, 22.07.14 08:33, Jon Severinsson (j...@severinsson.net) wrote:
>
> At Tuesday 22 July 2014 04:46:31 Andrey Borzenkov wrote:
> > But what exact problem does it solve?
>
> Units thinking they can read from /usr before local-fs-pre.target
Sorry, that ship has sailed. Many udev rules, many e
On Tue, 22.07.14 00:39, Jon Severinsson (j...@severinsson.net) wrote:
> Unless both /usr and /usr/local is mounted in the initrd these
> services might miss some of their configuration otherwise.
Hmm?
I am totally not convinced this would be a good idea. You cannot fix
this anyway... Think abou
The current inhibitors for going into suspend at lid closure are based on the
presence of a docking station, multiple or no displays and a fixed timeout
after the last suspend event.
I understand the goal to prevent an immediate suspend when the system is booted
with closed lid and other inhibitor
13 matches
Mail list logo
