Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

[Richard Hughes]

On Mon, 29 Apr 2019 at 10:16, Lennart Poettering  wrote:
> Please rewrite this as `FOREACH_STRING(fn, "/system-update/,
> "/etc/system-update") …` and then exit fatally with an error if
> laccess() fails with any error != ENOENT. In the above failures to
> laccess() /system-update are handled differently from those handling
> /etc/system-update...

Okay, thanks.

> Why a new service? We already have system-update-cleanup.service for
> this purpose, no?

Right, but system-update-cleanup.service is covering all kinds of
corner-cases -- We'd need to use ConditionPathExistsGlob and
ConditionPathIsSymbolicLinkGlob, the latter which does not exist. It
seemed so much simpler and easier to understand to copy and paste it
into a new service.

> Please submit as PR via github!

Done: https://github.com/systemd/systemd/pull/12464

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

[Richard Hughes]

On Fri, 26 Apr 2019 at 14:47, Dan Nicholson  wrote:
> I think /etc is the only guaranteed to be writable location that's
> generic to all ostree systems. If possible, I'd get systemd to honor
> /etc/system-update.

Lennart, is the attached going to be acceptable to you (of course as a
PR with docs...), or do you want me to build a generator and ship
something in fwupd? Another completely acceptable answer might be:
just run the firmware update After=final.target as a one-shot
service...

If the /etc/system-update isn't too bad as a concept I'd really like
to keep everything in systemd so that if there are any changes to how
this works they are all done in one project, not two.

Richard
From f190efefb00c73087c8ceafd1ca0fdab100cfa36 Mon Sep 17 00:00:00 2001
From: Richard Hughes 
Date: Fri, 26 Apr 2019 14:53:34 +0100
Subject: [PATCH] Support /etc/system-update for OSTree systems

This is required when / is immutable and cannot be written at runtime.
---
 .../system-update-generator.c |  3 +-
 units/meson.build |  1 +
 units/system-update-sysroot-cleanup.service   | 35 +++
 3 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 units/system-update-sysroot-cleanup.service

diff --git a/src/system-update-generator/system-update-generator.c b/src/system-update-generator/system-update-generator.c
index 77e265d710..c90374d01b 100644
--- a/src/system-update-generator/system-update-generator.c
+++ b/src/system-update-generator/system-update-generator.c
@@ -20,7 +20,8 @@ static const char *arg_dest = NULL;
 static int generate_symlink(void) {
 const char *p = NULL;
 
-if (laccess("/system-update", F_OK) < 0) {
+if (laccess("/system-update", F_OK) < 0 &&
+laccess("/etc/system-update", F_OK) < 0) {
 if (errno == ENOENT)
 return 0;
 
diff --git a/units/meson.build b/units/meson.build
index a5610506d5..8111dd963e 100644
--- a/units/meson.build
+++ b/units/meson.build
@@ -77,6 +77,7 @@ units = [
 ['system-update.target',''],
 ['system-update-pre.target',''],
 ['system-update-cleanup.service',   ''],
+['system-update-sysroot-cleanup.service',''],
 ['systemd-ask-password-console.path',   '',
  'sysinit.target.wants/'],
 ['systemd-ask-password-wall.path',  '',
diff --git a/units/system-update-sysroot-cleanup.service b/units/system-update-sysroot-cleanup.service
new file mode 100644
index 00..f0dea64f19
--- /dev/null
+++ b/units/system-update-sysroot-cleanup.service
@@ -0,0 +1,35 @@
+#  SPDX-License-Identifier: LGPL-2.1+
+#
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+[Unit]
+Description=Remove the Offline System Updates symlink
+Documentation=man:systemd.special(7) man:systemd.offline-updates(7)
+After=system-update.target
+DefaultDependencies=no
+Conflicts=shutdown.target
+Before=shutdown.target
+SuccessAction=reboot
+
+# system-update-generator uses laccess("/etc/system-update"), while a plain
+# ConditionPathExists=/system-update uses access("/etc/system-update"), so
+# we need an alternate condition to cover the case of a dangling symlink.
+#
+# This service is only invoked if /etc/system-update exists, i.e. if the
+# condition tested by system-update-generator remains true and the system
+# would be diverted into system-update.target again after reboot. This way
+# we guard against being diverted into system-update.target again, which
+# works as a safety measure, but we will not step on the toes of the
+# update script if it successfully removed the symlink and scheduled a
+# reboot or some other action on its own.
+ConditionPathExists=|/etc/system-update
+ConditionPathIsSymbolicLink=|/etc/system-update
+
+[Service]
+Type=oneshot
+ExecStart=/bin/rm -fv /etc/system-update
-- 
2.21.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

[Richard Hughes]

On Fri, 26 Apr 2019 at 09:54, Lennart Poettering  wrote:
> Hmm, the assumption was always that / was mutable if offline updates
> are used to update /...

Right, I don't know if I'm misusing the offline updates feature to
update firmware. If there's something else I should be using I'm open
for ideas.  I guess shutdown is another time the update could be
applied, but it's not really what the user expects.

> I have the suspicion the ostree folks might have some specific ideas
> on how to do this in their environment?

I can certainly ask. I tried Ryans suggestion of putting the symlink
in /sysroot (which is mutable) but this doesn't get "assembled" into
the / soon enough for the systemd generator.

> What precisely is writable on those systems? Is /etc? You need
> something that is accessible during early boot (i.e. right after the
> transition from the initrd to the host OS). This excludes /var in the
> general case, but includes /etc, / or /usr...

/etc works, although it seems the wrong place for this kind of thing.

> Given that GRUB doesn't support that and maybe you don't want to bind
> yourself to EFI variables it's not the best approach anyway?

Perhaps not, the 2xBLS thing doesn't help either.

> I'd not make dynamic changes to ESP or /boot I must say (i.e. 2. +
> 3. from the list above). It should contain static data only I am sure,
> only updated at system updates.

I guess /boot works from a logical and mutable point of view. Would
you be open to a patch to system-update-generator.c that supports
looking for (and deleting) a /boot/system-update -- I think even if
/boot is the ESP I think it still works. The other path I could try is
/sysroot/system-update which might work, although is ostree specific.

Richard
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Using systemd.offline-updates from an ostree based system

[Richard Hughes]

 Hi all,

I use the offline updates feature
https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html
in fwupd to install some kinds of firmware. I've just found out this
doesn't work on Fedora SilverBlue as / is immutable and of course
creating the /system-update symlink fails.

I'm using the offline update mode rather than updating "live" as I'm
updating the keyboard controller itself, which means the keyboard (and
power button!) is disabled and various things like ACPI battery
reporting also get upset for the 30 seconds of flashing. I'm stuck for
ideas. I suppose I could write a new boot entry (BLS?) that has a new
kernel command line argument set to go into system-update.target (and
patch src/system-update-generator/system-update-generator.c) although
I don't think BLS has the concept of a "oneshot" entry that would
delete after running it once.

All ideas welcome, thanks.

Richard
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] PrivateNetwork and libusb

[Richard Hughes]

On 14 December 2016 at 11:36, Lennart Poettering  wrote:
> RestrictNamespaces=yes

I didn't see this on
https://www.freedesktop.org/software/systemd/man/systemd.exec.html --
is super-new or just undocumented? Otherwise, thanks!

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] PrivateNetwork and libusb

[Richard Hughes]

On 14 December 2016 at 09:32, Reindl Harald  wrote:
> RestrictAddressFamilies=AF_NETLINK

Great, that was the pointer I needed, thanks. I'm currently setting
this in the service file:

NoNewPrivileges=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelModules=yes
RestrictAddressFamilies=AF_NETLINK AF_UNIX

Are there other important settings I've missed? fwupd does access the
hardware and write the odd file to the filesystem so there didn't seem
any other super useful flags. Thanks.

Richard
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] PrivateNetwork and libusb

[Richard Hughes]

Hi all,

For a long time colord has had PrivateNetwork commented out in colord,
as it prevented libudev working correctly. We thought that perhaps
udev's AF_NETLINK messages are being filtered when network namespacing
is on. In an unrelated project (this time fwupd) we recently also
found that libusb hotplug events are not being allowed when run under
systemd but work fine when run manually. I assume this is libusb using
libudev to do hotplug detection, and thus is the same issue.

It would be a shame to have PrivateNetwork commented out in fwupd,
especially as it's a root daemon that has no business dealing with
networking stuff. Is there a way of using PrivateNetwork=yes and
allowing AF_NETLINK to correctly work?

Thanks,

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Question about system-update.target

[Richard Hughes]

At the moment the only user of system-update.target is PackageKit,
which does package updates offline in the special system-update boot
target. The other project that has just started using this mode is
fwupd, which is using it to update BIOS-based firmware (not UEFI
capsules) offline.

I've installed a symlink to system-update.target.wants so that the
fwupd process gets run, but I'm a little worried about what happens
when there are two optional services being run, both with
OnFailure=reboot.target

What return code I supposed to return if we launch
fwupd-offline-update.service and there are no BIOS updates to apply?
It seems to me that we want the behaviour of OnFailure to be if
none of the *-offline-update.service files returned success rather
than what happens now in that we launch pk-offline-update with no
package updates which returns failure, which reboots the machine
before the fwupd offline update process even gets a chance to properly
start.

Ideas welcome, thanks.

Richard
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about system-update.target

[Richard Hughes]

On 27 April 2015 at 15:18, Lennart Poettering lenn...@poettering.net wrote:
 Well, thinking about this, maybe OnFailure=reboot.target is missing
 the point for these services. After all, the system should reboot
 regardless if the update fails or not...

Not quite; PackageKit supports an update-offline-and-then-shutdown
mode at the request of the GNOME designers. If we can configure that
using systemd I'd gladly rip out the code in PackageKit and move it
down to systemd.

 This would mean that any updating service would pull this in, and
 order itself before it. Sicne this new service is hence ordered efter
 each updating service it will only run after all of them finished,
 regardless if failed or succeeded.
 Does this make sense to you?

Sure, it does, modulo the feature above.

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about system-update.target

[Richard Hughes]

On 27 April 2015 at 16:42, Lennart Poettering lenn...@poettering.net wrote:
 - ship a service packagekit-reboot.service that contains:

   [Service]
   ExecStart=/bin/systemctl reboot --no-block
   Type=oneshot

If that file was shipped in systemd, fwupd could use the same method
without having to ship the extra duplicated files. e.g.
system-update-post-reboot.service

 Then, order both your update services
 Before=packagegit-reboot.service packagekit-poweroff.service, so
 that they run before those services are started.

Makes sense so far.

 Finally, from packagekit, enqueue pretty early on, before you start
 installation either one or the other of the two services, depending on
 packagkit's configuration. This is easily done by issuing the
 StartUnit() bus call on the systemd service file passing either
 packagekit-reboot.service or packagekit-poweroff.service as first
 parameter, and replace as second.

Clever stuff.

 I hope that makes sense?

and remove OnFailure=reboot.target, right?

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about system-update.target

[Richard Hughes]

On 27 April 2015 at 17:53, Mantas Mikulėnas graw...@gmail.com wrote:
 In this case, failure doesn't make much sense, if you describe the task as
 ensuring that the BIOS is up-to-date.

In this case, the task is upload firmware blob foo.bin in /var/cache
to the flash chip

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Using the hwdb in external programs

[Richard Hughes]

Hi all,

I'm aware of at least half a dozen programs and daemons that read and
parse /usr/share/hwdata/pnp.ids to convert PNP_IDS to actual vendor
names. Although this file will be in hot cache at login, it does seem
a waste of a lot of duplicated parsing and hashing code. I'm aware the
PNP_ID database is used in the hwdb, and hashed in an efficient way.
I'm wondering if external applications (like gnome-settings-daemon)
could use the data there.

Ideas welcome, thanks,

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using the hwdb in external programs

[Richard Hughes]

On 14 August 2013 11:41, Kay Sievers k...@vrfy.org wrote:
 An example is here:
   
 http://cgit.freedesktop.org/systemd/systemd/tree/src/test/test-libudev.c#n432

Great! Thanks. So I know what to use where, what's the cost of those
functions? For instance, is udev_hwdb_new() going to use globs of
memory until udev_hwdb_unref() is called, or are any of the functions
especially CPU intensive? I can profile if required, although I'm
hoping the answer is very little; very little :)

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Handling lid close in logind?

[Richard Hughes]

Hey,

I know Lennart and Kay are still on walkabout, but I wanted to ask any
opinions on https://bugzilla.gnome.org/show_bug.cgi?id=680689

Basically:

* User inhibits suspend, perhaps by doing an update or burning a CD
* User closes laptop
* Laptop shows polkit auth box, but the lid is closed and the user
doesn't see the dialog
* Users puts laptop in bag
* Laptop overheats
* User writes angry blog

Ideas very welcome. Thanks.

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Handling lid close in logind?

[Richard Hughes]

On 3 September 2012 09:17, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 Laptop emits a long series of angry beeps. If it starts really overheating,
 thermal protection kicks in and the laptop shuts down.

Unless you're a macbook, with the white thermoplastic cover. Gloopy mess :)

I don't think the desktop guys want any kind of authentication when
the lid is closed. How feasible would it be to do the suspend when the
inhibit is removed? I guess then it puts logind into a active but
will suspend asap state which might be difficult to handle.

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd security issue

[Richard Hughes]

On 23 August 2012 17:25, Kay Sievers k...@vrfy.org wrote:
 F17 should already have proper multi-seat support, if that's what you look 
 for.

I plugged in the pluggable-dock thing, and got this in dmesg:

[259482.053980] udlfb: open /dev/fb1 user=1 fb_info=88020535f800 count=1
[259482.054006] udlfb: released /dev/fb1 user=1 count=0
[259482.054113] udlfb: open /dev/fb1 user=1 fb_info=88020535f800 count=1
[259482.055062] udlfb: /dev/fb1 FB_BLANK mode 0 -- 1
[259482.172189] udlfb: /dev/fb1 FB_BLANK mode 1 -- 0
[259482.833494] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Nothing appears on the DVI/VGA port, so I assume I have to set X stuff
manually. Have you got any pointers? Thanks.

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd security issue

[Richard Hughes]

On 24 August 2012 17:40, shawn shawnland...@gmail.com wrote:
 ...if you use udevadm you should be able to figure out
 which /dev/fb[0-9]* it is.

Sure, but what do I then do to assign the fb and usb devices the right
seat, and to start X with the right parameters? I assumed it would be
a bit more plug-and-play than that :)

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 183

[Richard Hughes]

On 25 May 2012 13:28, Lennart Poettering lenn...@poettering.net wrote:
        * A framework for implementing offline system updates is now
          integrated, for details see:
          http://freedesktop.org/wiki/Software/systemd/SystemUpdates

Seeing as system-update.target is now shipped in systemd itself,
wouldn't it make sense also to have r /system-update in
/usr/lib/tmpfiles.d/systemd.conf as well?

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Adding a service file to run with system-update.target

[Richard Hughes]

I've been playing with the offline updates thing a bit. Is this the
kind of service file that PackageKit should install into
/usr/lib/systemd/system/ ?

[Unit]
Description=Updates the operating system whilst offline
DefaultDependencies=no
After=system-update.target

[Service]
Type=oneshot
ExecStart=/usr/libexec/pk-offline-update

I'm guessing I also have to do something like ln -sf
/lib/systemd/system/packagekit-offline-update.service
/etc/systemd/system/system-update.target.wants/packagekit-offline-update.service
as well.

Thanks,

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd - consolekit, spice-vdagent questions

[Richard Hughes]

On 16 September 2011 13:17, Hans de Goede hdego...@redhat.com wrote:
 Hmm, I cannot find this in gnome-settings-daemon-3.1.91

git master, sorry.

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd - consolekit, spice-vdagent questions

[Richard Hughes]

On 15 September 2011 13:41, Matthias Clasen matthias.cla...@gmail.com wrote:
 gdbus introspect --system --dest org.freedesktop.login1 --object-path
 /org/freedesktop/login1

FWIW, so gnome-settings-daemon could track the active console I added
ConsoleKit support in an abstract way, on the logic that it could
easily be switched to logind when the latter actually worked. If you
want the code, it's in
gnome-settings-daemon/gnome-settings-daemon/gnome-settings-session.[c|h]

Richard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel