Re: [systemd-devel] Appc support in systemd-importd
On Wed, 11.03.15 16:33, Lennart Poettering (lenn...@poettering.net) wrote: * Alban liked the idea of saving the manifest so we can extract the whole ACI and modify nspawn to detect a container is an ACI and set /var/lib/machines/appc-image.aci/rootfs as the container's root. The benefit of keeping the manifest would be knowing which binary to start. Is that acceptable? This would be quite different from dkr handling though. Currently my thinking for dkr is after all that everything gets converted at import time and from that point on is just a raw directory with an associated native config file for nspawn. Or in other words: nspawn + machined have no idea what dkr is, only importd has... I wonder what it would take to make ACI imports work the same way... If I understand things right ACI tarballs come with only two directories: rootfs plus manifest. Maybe it would work to place rootfs for a container foobar directly as directory in /var/lib/machines/foobar, and then placing the manifest as /var/lib/machines/foobar.aci-manifest, with a converted version as /var/lib/machines/foobar.nspawn or so? Thinking about this more: Given the ACI requires some HTTP service to be exposed towards the container I figure we have to teach ACI support anyway to nspawn. And if that's the case we can as well support it all the way in machined and nspawn, and support its untarred stuff natively without rearranging the directories. I figure Alban's idea is good then! 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] Appc support in systemd-importd
On Wed, 11.03.15 15:24, Iago López Galeiras (i...@endocode.com) wrote: (added Vincent Batts to CC) Hi, We're looking into adding appc[1] support in systemd-importd. An appc image (ACI) is just a tar with a rootfs directory and a json manifest. We would have to implement image discovery and simply extract the rootfs. Some questions: A great! I remember Vincent Batts was interested in that too. Vincent, do you have any code already? * I see that the dkr implementation ignores the information in the docker manifest (resource restrictions, binary to exec...). Is that by design or just not implemented yet? Should we do the same with appc (*only* extract the rootfs)? This is not implemented yet. I want to introduce a concept of .nspawn files that can carry runtime information for containers (comparable to a dkr manifest), basically a way to encode the various bits one currently specifies on the command line in configuration files that can be searched for by name, where one of these files can be maintained per tree. This requires a bit of design tough to make sure we can both ship these files along with their trees and allow local modifications... Actually implementing these .nspawn files shuld be easy, the complexity is just in coming up with a good scheme for discovering, overriding, provisioning them. And then, as soon as we have them, the idea would be to convert the docker/ACI manifests in a smart way. * Alban liked the idea of saving the manifest so we can extract the whole ACI and modify nspawn to detect a container is an ACI and set /var/lib/machines/appc-image.aci/rootfs as the container's root. The benefit of keeping the manifest would be knowing which binary to start. Is that acceptable? This would be quite different from dkr handling though. Currently my thinking for dkr is after all that everything gets converted at import time and from that point on is just a raw directory with an associated native config file for nspawn. Or in other words: nspawn + machined have no idea what dkr is, only importd has... I wonder what it would take to make ACI imports work the same way... If I understand things right ACI tarballs come with only two directories: rootfs plus manifest. Maybe it would work to place rootfs for a container foobar directly as directory in /var/lib/machines/foobar, and then placing the manifest as /var/lib/machines/foobar.aci-manifest, with a converted version as /var/lib/machines/foobar.nspawn or so? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/6] fix strict aliasing issues in src/udev/udev-ctrl.c
it is ironic that
The only purpose of this structure is to cast the structure pointer
passed in addr in order to avoid compiler warnings. See EXAMPLE below.
from bind(2)
---
src/udev/udev-ctrl.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/udev/udev-ctrl.c b/src/udev/udev-ctrl.c
index c0c5981..61d3c5b 100644
--- a/src/udev/udev-ctrl.c
+++ b/src/udev/udev-ctrl.c
@@ -18,6 +18,7 @@
#include sys/socket.h
#include sys/un.h
+#include socket-util.h
#include udev.h
/* wire protocol magic must match */
@@ -55,7 +56,7 @@ struct udev_ctrl {
int refcount;
struct udev *udev;
int sock;
-struct sockaddr_un saddr;
+union sockaddr_union saddr;
socklen_t addrlen;
bool bound;
bool cleanup_socket;
@@ -94,9 +95,9 @@ struct udev_ctrl *udev_ctrl_new_from_fd(struct udev *udev,
int fd) {
if (r 0)
log_warning_errno(errno, could not set SO_PASSCRED: %m);
-uctrl-saddr.sun_family = AF_LOCAL;
-strscpy(uctrl-saddr.sun_path, sizeof(uctrl-saddr.sun_path),
/run/udev/control);
-uctrl-addrlen = offsetof(struct sockaddr_un, sun_path) +
strlen(uctrl-saddr.sun_path);
+uctrl-saddr.un.sun_family = AF_LOCAL;
+strscpy(uctrl-saddr.un.sun_path, sizeof(uctrl-saddr.un.sun_path),
/run/udev/control);
+uctrl-addrlen = offsetof(struct sockaddr_un, sun_path) +
strlen(uctrl-saddr.un.sun_path);
return uctrl;
}
@@ -108,10 +109,10 @@ int udev_ctrl_enable_receiving(struct udev_ctrl *uctrl) {
int err;
if (!uctrl-bound) {
-err = bind(uctrl-sock, (struct sockaddr *)uctrl-saddr,
uctrl-addrlen);
+err = bind(uctrl-sock, uctrl-saddr.sa, uctrl-addrlen);
if (err 0 errno == EADDRINUSE) {
-unlink(uctrl-saddr.sun_path);
-err = bind(uctrl-sock, (struct sockaddr
*)uctrl-saddr, uctrl-addrlen);
+unlink(uctrl-saddr.un.sun_path);
+err = bind(uctrl-sock, uctrl-saddr.sa,
uctrl-addrlen);
}
if (err 0) {
@@ -160,7 +161,7 @@ int udev_ctrl_cleanup(struct udev_ctrl *uctrl) {
if (uctrl == NULL)
return 0;
if (uctrl-cleanup_socket)
-unlink(uctrl-saddr.sun_path);
+unlink(uctrl-saddr.un.sun_path);
return 0;
}
@@ -249,7 +250,7 @@ static int ctrl_send(struct udev_ctrl *uctrl, enum
udev_ctrl_msg_type type, int
ctrl_msg_wire.intval = intval;
if (!uctrl-connected) {
-if (connect(uctrl-sock, (struct sockaddr *)uctrl-saddr,
uctrl-addrlen) 0) {
+if (connect(uctrl-sock, uctrl-saddr.sa, uctrl-addrlen)
0) {
err = -errno;
goto out;
}
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vconsole-setup: check error of child process
On Wed, Mar 11, 2015 at 12:55 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Mar 10, 2015 at 8:56 PM, lucas.de.mar...@gmail.com wrote:
From: Lucas De Marchi lucas.demar...@intel.com
If we don't check the error of the child process, systemd-vconsole-setup
would exit with 0 even if it could not really setup the console.
For a simple test, move loadkeys elsewhere and execute
systemd-vconsole-setup:
[root@localhost ~]# strace -f -e execve
/usr/lib/systemd/systemd-vconsole-setup
execve(/usr/lib/systemd/systemd-vconsole-setup,
[/usr/lib/systemd/systemd-vconsol...], [/* 15 vars */]) = 0
Process 171 attached
[pid 171] execve(/usr/bin/loadkeys, [/usr/bin/loadkeys, -q,
-C, /dev/tty0, br-abnt2], [/* 15 vars */]) = -1 ENOENT (No such file
or directory)
[pid 171] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=171,
si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 0 +++
Now systemd-vconsole-setup exits with EXIT_FAILURE if the child failed
for whatever reason.
---
src/vconsole/vconsole-setup.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..601ca4a 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -304,8 +304,12 @@ int main(int argc, char **argv) {
return EXIT_FAILURE;
}
-if (font_pid 0)
-wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
+if (font_pid 0) {
+r = wait_for_terminate_and_warn(KBD_SETFONT, font_pid,
true);
+if (r != 0)
+return EXIT_FAILURE;
+}
+
Looks mostly good. However, I'd prefer if we continue on r 0 but
remember the error for later. This way, we still try loading the right
keymap even though the font might have failed.
Is there any reason to continue on r 0 but not on r 0? I'm ok with
changing the current behavior, but just like to know which one is
better.
--
Lucas De Marchi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vconsole-setup: check error of child process
On Wed, Mar 11, 2015 at 1:17 PM, David Herrmann dh.herrm...@gmail.com wrote:
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..601ca4a 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -304,8 +304,12 @@ int main(int argc, char **argv) {
return EXIT_FAILURE;
}
-if (font_pid 0)
-wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
+if (font_pid 0) {
+r = wait_for_terminate_and_warn(KBD_SETFONT, font_pid,
true);
+if (r != 0)
+return EXIT_FAILURE;
+}
+
Looks mostly good. However, I'd prefer if we continue on r 0 but
remember the error for later. This way, we still try loading the right
keymap even though the font might have failed.
Is there any reason to continue on r 0 but not on r 0? I'm ok with
changing the current behavior, but just like to know which one is
better.
Yeah, not sure here. For most helpers here r0 means serious error
(fork() failed, etc.), r0 means just the spawned application failed.
I guess we should continue for all !=0. That is, don't return
prematurely at all.
ok... I'll send a v2
--
Lucas De Marchi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/6] network: fix strict aliasing issue
We shouldn't assume 64-bit arch with the way we do math either.
(although I will submit a patch to glibc to add a uint64_t union alias)
---
src/network/networkd-address.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/network/networkd-address.c b/src/network/networkd-address.c
index 0be6165..4b7f451 100644
--- a/src/network/networkd-address.c
+++ b/src/network/networkd-address.c
@@ -605,12 +605,12 @@ bool address_equal(Address *a1, Address *a2) {
}
case AF_INET6: {
-uint64_t *b1, *b2;
+uint32_t *b1, *b2;
-b1 = (uint64_t*)a1-in_addr.in6;
-b2 = (uint64_t*)a2-in_addr.in6;
+b1 = a1-in_addr.in6.s6_addr32[0];
+b2 = a2-in_addr.in6.s6_addr32[0];
-return (((b1[0] ^ b2[0]) | (b1[1] ^ b2[1])) == 0UL);
+return (((b1[0] ^ b2[0]) | (b1[1] ^ b2[1]) | (b1[2] ^ b2[2]) |
(b1[3] ^ b2[3])) == 0);
}
default:
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vconsole-setup: check error of child process
Hi
On Tue, Mar 10, 2015 at 8:56 PM, lucas.de.mar...@gmail.com wrote:
From: Lucas De Marchi lucas.demar...@intel.com
If we don't check the error of the child process, systemd-vconsole-setup
would exit with 0 even if it could not really setup the console.
For a simple test, move loadkeys elsewhere and execute
systemd-vconsole-setup:
[root@localhost ~]# strace -f -e execve
/usr/lib/systemd/systemd-vconsole-setup
execve(/usr/lib/systemd/systemd-vconsole-setup,
[/usr/lib/systemd/systemd-vconsol...], [/* 15 vars */]) = 0
Process 171 attached
[pid 171] execve(/usr/bin/loadkeys, [/usr/bin/loadkeys, -q,
-C, /dev/tty0, br-abnt2], [/* 15 vars */]) = -1 ENOENT (No such file or
directory)
[pid 171] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=171,
si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 0 +++
Now systemd-vconsole-setup exits with EXIT_FAILURE if the child failed
for whatever reason.
---
src/vconsole/vconsole-setup.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..601ca4a 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -304,8 +304,12 @@ int main(int argc, char **argv) {
return EXIT_FAILURE;
}
-if (font_pid 0)
-wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
+if (font_pid 0) {
+r = wait_for_terminate_and_warn(KBD_SETFONT, font_pid, true);
+if (r != 0)
+return EXIT_FAILURE;
+}
+
Looks mostly good. However, I'd prefer if we continue on r 0 but
remember the error for later. This way, we still try loading the right
keymap even though the font might have failed.
Thanks
David
r = keymap_load(vc, vc_keymap, vc_keymap_toggle, utf8, keymap_pid);
if (r 0) {
@@ -313,10 +317,13 @@ int main(int argc, char **argv) {
return EXIT_FAILURE;
}
-if (keymap_pid 0)
-wait_for_terminate_and_warn(KBD_LOADKEYS, keymap_pid, true);
+if (keymap_pid 0) {
+r = wait_for_terminate_and_warn(KBD_LOADKEYS, keymap_pid,
true);
+if (r != 0)
+return EXIT_FAILURE;
+}
-/* Only copy the font when we started setfont successfully */
+/* Only copy the font when we executed setfont successfully */
if (font_copy font_pid 0)
font_copy_to_all_vcs(fd);
--
2.3.2
___
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] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
I think the rbtree version was far more understandable as greedy_realloc0()
is very messy to do correctly.
Take fopenat() from lsof.
Future: generate BootLoaderSpec files for other kernel install locations
v5: fix syscall invocation from draft version
---
Makefile.am | 4 +-
TODO | 3 -
man/systemctl.xml | 15 ++-
src/core/shutdown.c | 30 --
src/shared/fileio.c | 59
src/shared/fileio.h | 2 +
src/shared/missing.h | 11 +++
src/shared/rpmvercmp.c| 26 --
src/shared/strv.c | 9 +-
src/systemctl/bootspec.c | 231 ++
src/systemctl/bootspec.h | 51 ++
src/systemctl/systemctl.c | 57 +++-
12 files changed, 469 insertions(+), 29 deletions(-)
create mode 100644 src/systemctl/bootspec.c
create mode 100644 src/systemctl/bootspec.h
diff --git a/Makefile.am b/Makefile.am
index 353a7de..20a6484 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2736,7 +2736,9 @@ systemd_escape_LDADD = \
# -
systemctl_SOURCES = \
- src/systemctl/systemctl.c
+ src/systemctl/systemctl.c \
+ src/systemctl/bootspec.c \
+ src/systemctl/bootspec.h
systemctl_LDADD = \
libsystemd-units.la \
diff --git a/TODO b/TODO
index 6180077..9ba7be0 100644
--- a/TODO
+++ b/TODO
@@ -86,9 +86,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 338c1d3..c550339 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -607,6 +607,15 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/varlistentry
varlistentry
+ termcommandlist-kernels/command/term
+
+ listitem
+paraList kernels ordered by version.
+/para
+ /listitem
+/varlistentry
+
+varlistentry
termcommandstart
replaceablePATTERN/replaceable.../command/term
listitem
@@ -1550,7 +1559,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/varlistentry
varlistentry
- termcommandkexec/command/term
+ termcommandkexec
optionalreplaceableVERSION/replaceable/optionaloptionalreplaceableKERNEL-ARG/replaceable.../optional/command/term
listitem
paraShut down and reboot the system via kexec. This is
@@ -1560,6 +1569,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
services is skipped, however all processes are killed and
all file systems are unmounted or mounted read-only,
immediately followed by the reboot./para
+
+paraAlso allows specifying the version and optionally
+extra kernel parameters to append. If no version is specified
+then the most recent kernel is booted./para
/listitem
/varlistentry
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 70a461e..616a70a 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/reboot.h
#include linux/reboot.h
@@ -173,15 +174,21 @@ int main(int argc, char *argv[]) {
goto error;
}
+in_container = !!detect_virtualization(NULL);
+
if (streq(arg_verb, reboot))
cmd = RB_AUTOBOOT;
else if (streq(arg_verb, poweroff))
cmd = RB_POWER_OFF;
else if (streq(arg_verb, halt))
cmd = RB_HALT_SYSTEM;
-else if (streq(arg_verb, kexec))
-cmd = LINUX_REBOOT_CMD_KEXEC;
-else {
+else if (streq(arg_verb, kexec)) {
+if (in_container) {
+log_warning(Can't kexec from container. Rebooting…);
+cmd = RB_AUTOBOOT;
+} else
+cmd = LINUX_REBOOT_CMD_KEXEC;
+} else {
r = -EINVAL;
log_error(Unknown action '%s'., arg_verb);
goto error;
@@ -200,8 +207,6 @@ int main(int argc, char *argv[]) {
log_info(Sending SIGKILL to remaining processes...);
broadcast_signal(SIGKILL, true, false);
-in_container = detect_container(NULL) 0;
-
need_umount = !in_container;
[systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
I think the rbtree version was far more understandable as greedy_realloc0()
is very messy to do correctly.
Take fopenat() from lsof.
Where is $BOOT?
Shouldn't /boot/efi be a symlink to . (/boot) ?
Debian defaults to $BOOT=/boot/efi
kay fedora default too, but if there is no fstab entry, systemd will mount
the ESP at /boot
Future: generate BootLoaderSpec files for other kernel install locations
v5: fix syscall invocation from draft version
---
Makefile.am | 4 +-
TODO | 3 -
man/systemctl.xml | 15 ++-
src/core/shutdown.c | 30 --
src/shared/fileio.c | 59
src/shared/fileio.h | 2 +
src/shared/missing.h | 11 +++
src/shared/rpmvercmp.c| 26 --
src/shared/strv.c | 9 +-
src/systemctl/bootspec.c | 231 ++
src/systemctl/bootspec.h | 52 +++
src/systemctl/systemctl.c | 57 +++-
12 files changed, 470 insertions(+), 29 deletions(-)
create mode 100644 src/systemctl/bootspec.c
create mode 100644 src/systemctl/bootspec.h
diff --git a/Makefile.am b/Makefile.am
index 353a7de..20a6484 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2736,7 +2736,9 @@ systemd_escape_LDADD = \
# -
systemctl_SOURCES = \
- src/systemctl/systemctl.c
+ src/systemctl/systemctl.c \
+ src/systemctl/bootspec.c \
+ src/systemctl/bootspec.h
systemctl_LDADD = \
libsystemd-units.la \
diff --git a/TODO b/TODO
index 6180077..9ba7be0 100644
--- a/TODO
+++ b/TODO
@@ -86,9 +86,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 338c1d3..c550339 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -607,6 +607,15 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/varlistentry
varlistentry
+ termcommandlist-kernels/command/term
+
+ listitem
+paraList kernels ordered by version.
+/para
+ /listitem
+/varlistentry
+
+varlistentry
termcommandstart
replaceablePATTERN/replaceable.../command/term
listitem
@@ -1550,7 +1559,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/varlistentry
varlistentry
- termcommandkexec/command/term
+ termcommandkexec
optionalreplaceableVERSION/replaceable/optionaloptionalreplaceableKERNEL-ARG/replaceable.../optional/command/term
listitem
paraShut down and reboot the system via kexec. This is
@@ -1560,6 +1569,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
services is skipped, however all processes are killed and
all file systems are unmounted or mounted read-only,
immediately followed by the reboot./para
+
+paraAlso allows specifying the version and optionally
+extra kernel parameters to append. If no version is specified
+then the most recent kernel is booted./para
/listitem
/varlistentry
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 70a461e..616a70a 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/reboot.h
#include linux/reboot.h
@@ -173,15 +174,21 @@ int main(int argc, char *argv[]) {
goto error;
}
+in_container = !!detect_virtualization(NULL);
+
if (streq(arg_verb, reboot))
cmd = RB_AUTOBOOT;
else if (streq(arg_verb, poweroff))
cmd = RB_POWER_OFF;
else if (streq(arg_verb, halt))
cmd = RB_HALT_SYSTEM;
-else if (streq(arg_verb, kexec))
-cmd = LINUX_REBOOT_CMD_KEXEC;
-else {
+else if (streq(arg_verb, kexec)) {
+if (in_container) {
+log_warning(Can't kexec from container. Rebooting…);
+cmd = RB_AUTOBOOT;
+} else
+cmd = LINUX_REBOOT_CMD_KEXEC;
+} else {
r = -EINVAL;
log_error(Unknown action '%s'., arg_verb);
goto error;
@@ -200,8 +207,6 @@ int main(int argc, char *argv[]) {
Re: [systemd-devel] Appc support in systemd-importd
On 11/03/15 16:33 +0100, Lennart Poettering wrote: On Wed, 11.03.15 15:24, Iago López Galeiras (i...@endocode.com) wrote: (added Vincent Batts to CC) Hi, We're looking into adding appc[1] support in systemd-importd. An appc image (ACI) is just a tar with a rootfs directory and a json manifest. We would have to implement image discovery and simply extract the rootfs. Some questions: A great! I remember Vincent Batts was interested in that too. Vincent, do you have any code already? What began as a noble effort has so far been sidelined by continuing work on the trust story of distributing these container images. Looking at my branch, it's not more than stubs. I was last reading through the other import/pull logic in use. vb pgpV9GkrRxxaq.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Wed, Mar 11, 2015 at 2:41 PM, Chris Murphy li...@colorremedies.com wrote: A more general purpose solution for UEFI would be EFI drivers for various filesystems including md, LVM, and Btrfs, so that there's quasi-native firmware support for them. Interesting. ext4, ReiserFS, Btrfs, NTFS, and HFS+ UEFI drivers. http://www.rodsbooks.com/refind/drivers.html Apparently this makes GRUB fs modules into stand alone EFI drivers. http://efi.akeo.ie/ -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy li...@colorremedies.com wrote: On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger tobias.hun...@gmail.com wrote: If you're concerned about bootloader configuration modification as a threat vector, then it needs to go on an encrypted volume. This suggests an initial bootloader configuration that only enables the user to supply a passphrase/key file to unlock that volume, and then load a new bootloader configuration file. I am still hoping secure boot and sd-boot will solve this issue mid-term by making sure all the early boot components are signed properly. The bootloader configuration files aren't signed. Maybe the should be. With systemd-boot, there will be no config to sign: https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/ And maybe done away with in favor of dynamic discovery and hot keys for indicating common boot options. The all included kernels are found at /boot/EFI/Linux/*.efi Any general purpose solution should account for degraded bootable raid, which means each ESP needs to be identical. Either each ESP bootloader looks to a single location on raid for configuration, or uses dynamic discovery, or some system of sequentially updating each ESP needs to be devised. We get that transparently from firmwares with bios raid support. We will not care about any sort of conventional software raid, because the firmware itself will not handle it, and it makes nt much sense to use over-complicated options in the later boot steps when it cannot recover itself anyway. For a single-system disk, the entire /boot, ESP content should rather be seen as throw-way content which can be re-constructed from a running system, from the content in /usr, at any given time. There is no point in handling raid without native firmware support; manual intervention is needed anyway on these systems if things go wrong, and that step can just re-create the ESP content if needed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Wed, Mar 11, 2015 at 11:50 AM, Kay Sievers k...@vrfy.org wrote: On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy li...@colorremedies.com wrote: \ The bootloader configuration files aren't signed. Maybe the should be. With systemd-boot, there will be no config to sign: https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/ That's definitely an improvement. And maybe done away with in favor of dynamic discovery and hot keys for indicating common boot options. The all included kernels are found at /boot/EFI/Linux/*.efi Yeah until the distros stop persistently mounting the ESP, I'm not a fan at all of anything but the most minimalist approach to the ESP. The FAT kernel maintainer says it's a bad idea, pretty much any crash or panic while the ESP is mounted, even ro, can cause FAT corruption and there's nothing to be done about it (well, fsck it at every boot might help some, which also some distros don't ever do). Any general purpose solution should account for degraded bootable raid, which means each ESP needs to be identical. Either each ESP bootloader looks to a single location on raid for configuration, or uses dynamic discovery, or some system of sequentially updating each ESP needs to be devised. We get that transparently from firmwares with bios raid support. a.) such support lacks widespread availability b.) Intel IMSM requires mdadm to manage it once the kernel is running, and I'm not aware of any support for AMD's equivalent on Linux c.) Intel IMSM is an all or nothing approach to whole devices, they first go into a container, making both LVM and Btrfs raid impossible on those devices. We will not care about any sort of conventional software raid, because the firmware itself will not handle it, and it makes nt much sense to use over-complicated options in the later boot steps when it cannot recover itself anyway. OK except this has worked just fine on BIOS systems for years and they recover OK. GRUB2's mdadm supports degraded 1,10, 4, 5, 6 booting. The identical core.img is embedded in the MBR gap or BIOSBoot partition in each drive. Each core.img looks to the same e.g. /boot/grub location on the array, and can even find the kernel and initramfs on degraded raid6. I don't care for that usecase especially, but it does work, completely unattended. And at least a two disk raid1 degraded boot ought to work, unattended. For a single-system disk, the entire /boot, ESP content should rather be seen as throw-way content which can be re-constructed from a running system, from the content in /usr, at any given time. I agree with this. But it should be a very simple additional step to apply this to all ESP's on the system to make sure all of them enable the system to find a kernel and boot the system. There is no point in handling raid without native firmware support; manual intervention is needed anyway on these systems if things go wrong, and that step can just re-create the ESP content if needed. I don't agree with this. OS X supports this for 10+ years on EFI with software raid, and no such thing as firmware raid. No manual intervention is required in the degraded boot case. I'm not exactly sure how Windows works, but they have bootable mirroring software raid that doesn't depend on firmware raid. It's not general purpose to have to depend on proprietary firmware RAID to get UEFI resilient boot. This wasn't necessary on BIOS systems, there's no good reason to require it now. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Wed, Mar 11, 2015 at 7:45 PM, Chris Murphy li...@colorremedies.com wrote: On Wed, Mar 11, 2015 at 11:50 AM, Kay Sievers k...@vrfy.org wrote: The all included kernels are found at /boot/EFI/Linux/*.efi Yeah until the distros stop persistently mounting the ESP, I'm not a fan at all of anything but the most minimalist approach to the ESP. Systemd by default mounts it with autofs, it will not be mounted until it is accessed, which does not happen during normal operation. We currently miss autofs timeout handling, which would umount /boot again when it is no longer used. That would make stuff pretty robust, I expect. It's just that distros have their rather broken concept of putting it into fstab, and even cascading mounts with splitting /boot and the ESP. The FAT kernel maintainer says it's a bad idea, pretty much any crash or panic while the ESP is mounted, even ro, can cause FAT corruption and there's nothing to be done about it (well, fsck it at every boot might help some, which also some distros don't ever do). Right, the Linux FAT driver, or maybe just the way Linux handles the writeback to disk, is absolutely fragile. Corrupted FAT file systems are the norm and not the exception. We must mount it unconditionally, it will just break after a while. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
On Wed, Mar 11, 2015 at 7:45 PM, Chris Murphy li...@colorremedies.com wrote: On Wed, Mar 11, 2015 at 11:50 AM, Kay Sievers k...@vrfy.org wrote: There is no point in handling raid without native firmware support; manual intervention is needed anyway on these systems if things go wrong, and that step can just re-create the ESP content if needed. I don't agree with this. OS X supports this for 10+ years on EFI with software raid, and no such thing as firmware raid. It is the Apple firmware and not OS X. The firmware supports all sorts of Apple specific things like HFS+ and drivers for the WiFi hardware. And that is exactly what I meant with native support. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. The recent systemd-boot boot loader and efi stub loader which carries the kernel, the cmdline, the initrd in one single EFI binary will also not use any boot loader snippets, it will be discovered by the loader itself, which parses the PE/COFF files and looks for specific content. The snippets are meant to unify the boot loader *configuration*, but they do not mean that every bootable kernel will or should have one. There might be many ways for kernels to be found by the boot loader, the snippets are just one source for that. I'm not sure what exact problem this patch tries to solve, rebooting with kexec is faster than a full reboot. Currently we do not support kexec very well. Lennart asked for something like this, but perhaps we no longer want to support kexec loading? but it generally does not sound right to duplicate the boot loader selection/discovery/enumeration logic here. I don't really think we should do that, or will be able to catch with the boot loader up here. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. Hopefully it could be unified in some way. I find it disturbing that systemd will have a great deal of EFI-specific code. The recent systemd-boot boot loader and efi stub loader which carries the kernel, the cmdline, the initrd in one single EFI binary will also not use any boot loader snippets, it will be discovered by the loader itself, which parses the PE/COFF files and looks for specific content. The snippets are meant to unify the boot loader *configuration*, but they do not mean that every bootable kernel will or should have one. There might be many ways for kernels to be found by the boot loader, the snippets are just one source for that. I'm not sure what exact problem this patch tries to solve, but it generally does not sound right to duplicate the boot loader selection/discovery/enumeration logic here. I don't really think we should do that, or will be able to catch with the boot loader up here. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
I think the rbtree version was far more understandable as greedy_realloc0()
is very messy to do correctly.
Take fopenat() from lsof.
Add opendirat()
Future: generate BootLoaderSpec files for other kernel install locations
v5: fix syscall invocation from draft version
v6: usr either /boot/efi or /boot
---
Makefile.am | 4 +-
TODO | 3 -
man/systemctl.xml | 15 ++-
src/core/shutdown.c | 30 --
src/shared/fileio.c | 69 +
src/shared/fileio.h | 5 +
src/shared/missing.h | 11 +++
src/shared/rpmvercmp.c| 26 +++--
src/shared/strv.c | 9 +-
src/systemctl/bootspec.c | 247 ++
src/systemctl/bootspec.h | 48 +
src/systemctl/systemctl.c | 57 ++-
12 files changed, 495 insertions(+), 29 deletions(-)
create mode 100644 src/systemctl/bootspec.c
create mode 100644 src/systemctl/bootspec.h
diff --git a/Makefile.am b/Makefile.am
index 353a7de..20a6484 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2736,7 +2736,9 @@ systemd_escape_LDADD = \
# -
systemctl_SOURCES = \
- src/systemctl/systemctl.c
+ src/systemctl/systemctl.c \
+ src/systemctl/bootspec.c \
+ src/systemctl/bootspec.h
systemctl_LDADD = \
libsystemd-units.la \
diff --git a/TODO b/TODO
index 6180077..9ba7be0 100644
--- a/TODO
+++ b/TODO
@@ -86,9 +86,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 338c1d3..c550339 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -607,6 +607,15 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/varlistentry
varlistentry
+ termcommandlist-kernels/command/term
+
+ listitem
+paraList kernels ordered by version.
+/para
+ /listitem
+/varlistentry
+
+varlistentry
termcommandstart
replaceablePATTERN/replaceable.../command/term
listitem
@@ -1550,7 +1559,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
/varlistentry
varlistentry
- termcommandkexec/command/term
+ termcommandkexec
optionalreplaceableVERSION/replaceable/optionaloptionalreplaceableKERNEL-ARG/replaceable.../optional/command/term
listitem
paraShut down and reboot the system via kexec. This is
@@ -1560,6 +1569,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket
systemd-udevd.service
services is skipped, however all processes are killed and
all file systems are unmounted or mounted read-only,
immediately followed by the reboot./para
+
+paraAlso allows specifying the version and optionally
+extra kernel parameters to append. If no version is specified
+then the most recent kernel is booted./para
/listitem
/varlistentry
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 70a461e..616a70a 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/reboot.h
#include linux/reboot.h
@@ -173,15 +174,21 @@ int main(int argc, char *argv[]) {
goto error;
}
+in_container = !!detect_virtualization(NULL);
+
if (streq(arg_verb, reboot))
cmd = RB_AUTOBOOT;
else if (streq(arg_verb, poweroff))
cmd = RB_POWER_OFF;
else if (streq(arg_verb, halt))
cmd = RB_HALT_SYSTEM;
-else if (streq(arg_verb, kexec))
-cmd = LINUX_REBOOT_CMD_KEXEC;
-else {
+else if (streq(arg_verb, kexec)) {
+if (in_container) {
+log_warning(Can't kexec from container. Rebooting…);
+cmd = RB_AUTOBOOT;
+} else
+cmd = LINUX_REBOOT_CMD_KEXEC;
+} else {
r = -EINVAL;
log_error(Unknown action '%s'., arg_verb);
goto error;
@@ -200,8 +207,6 @@ int main(int argc, char *argv[]) {
log_info(Sending SIGKILL to remaining processes...);
broadcast_signal(SIGKILL, true, false);
-in_container = detect_container(NULL)
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 2:12 AM, Shawn Landden sh...@churchofgit.com wrote: On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. Hopefully it could be unified in some way. I find it disturbing that systemd will have a great deal of EFI-specific code. Well, I find it a lot more disturbing that we want kexec, which is in many cases just a pretty dirty short-cut for a reboot. And we need to teach that short-cut all sorts of logic and more dirty tricks is has no business with, just to be able to do its short-cutting. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. The recent systemd-boot boot loader and efi stub loader which carries the kernel, the cmdline, the initrd in one single EFI binary will also not use any boot loader snippets, it will be discovered by the loader itself, which parses the PE/COFF files and looks for specific content. The snippets are meant to unify the boot loader *configuration*, but they do not mean that every bootable kernel will or should have one. There might be many ways for kernels to be found by the boot loader, the snippets are just one source for that. I'm not sure what exact problem this patch tries to solve, but it generally does not sound right to duplicate the boot loader selection/discovery/enumeration logic here. I don't really think we should do that, or will be able to catch with the boot loader up here. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] fsckd: Don't use strjoina on gettext() call
Le 11/03/2015 09:29, Martin Pitt a écrit :
Hello all,
Didier Roche [2015-03-10 17:56 +0100]:
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -272,7 +272,7 @@ static int plymouth_send_message(int plymouth_fd, const
char *message, bool upda
}
static int manager_send_plymouth_message(Manager *m, const char *message) {
-const char *plymouth_cancel_message = NULL;
+_cleanup_free_ const char *plymouth_cancel_message = NULL,
*l10n_cancel_message = NULL;
int r;
As far as I can see, this would free(l10n_cancel_message) on exit, but
you must never free the result of gettext(). So split this into
_cleanup_free_ const char *plymouth_cancel_message = NULL;
const char *l10n_cancel_message;
Indeed (weird I didn't get a double free crash), but the man page says
it's statically allocated. Will fix it and report while bringing up the
other patch with the architecture modification.
Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] path_is_mount_point: handle false positive on some fs
Le 10/03/2015 18:54, Lennart Poettering a écrit : On Tue, 10.03.15 18:01, Didier Roche (didro...@ubuntu.com) wrote: The context is bug https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140, where systemd-machine-id-commit unit is entering in failed state (the binary handles gracefully the fact that it can't unmount the file) on a default ubuntu live system (which is a squashfs/overlayfs system). Hmm, it's not clear to me by that bug what precisely fails... Any idea? Maybe it would be better to just handle that failure gracefully... Basically, ConditionPathIsMountPoint=/etc/machine-id is met in the unit and so systemd-machine-id-commit is launched. This one: - executes the double checking path_is_mount_point(etc_machine_id, false) successfully (of course) - find that machine-id fd is a temporary fs (based on the same issue), read the machine-id file content - switch namespace - call unmount(etc_machine_id), which obviously fails as there is nothing to unmount. I don't think we should shadow that failure and not returning in error here, right? Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
If you're concerned about bootloader configuration modification as a threat vector, then it needs to go on an encrypted volume. This suggests an initial bootloader configuration that only enables the user to supply a passphrase/key file to unlock that volume, and then load a new bootloader configuration file. I am still hoping secure boot and sd-boot will solve this issue mid-term by making sure all the early boot components are signed properly. Let's wait and see. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] path_is_mount_point: handle false positive on some fs
On Tue, Mar 10, 2015 at 04:53:38PM +0100, Lennart Poettering wrote: Note that the st_dev thing is the traditional way to detect whether one crosses a file system boundary. It's used for this by tools like cp, find, We slightly enhance this by using name_to_handle_at(), so that we can also detect bind mounts from file systems onto themselves. Now, if overlayfs breaks the same file system logic of all other tools, I am not convinced that systemd should not be broken by it too.. It sounds surprising that we should work around this in systemd, but not in all other tools. Or to turn this around: instead of patching systemd the better idea would probably be to teach overlayfs name_to_handle_at() support, so +1 -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cgtop: fix assert when not on tty
systemd-cgtop --dept=1 -b -n 10 -d 0.1 | cat
Assertion 'new_length = 3' failed at src/shared/util.c:3 \
595, function ellipsize_mem(). Aborting.
Aborted (core dumped)
---
src/cgtop/cgtop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index 3c7ad40..46ba1aa 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -447,7 +447,7 @@ static int display(Hashmap *a) {
Group *g;
Group **array;
signed path_columns;
-unsigned rows, n = 0, j, maxtcpu = 0, maxtpath = 0;
+unsigned rows, n = 0, j, maxtcpu = 0, maxtpath = 3;
char buffer[MAX3(21, FORMAT_BYTES_MAX, FORMAT_TIMESPAN_MAX)];
assert(a);
--
2.1.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] fsckd: Don't use strjoina on gettext() call
Hello all,
Didier Roche [2015-03-10 17:56 +0100]:
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -272,7 +272,7 @@ static int plymouth_send_message(int plymouth_fd, const
char *message, bool upda
}
static int manager_send_plymouth_message(Manager *m, const char *message) {
-const char *plymouth_cancel_message = NULL;
+_cleanup_free_ const char *plymouth_cancel_message = NULL,
*l10n_cancel_message = NULL;
int r;
As far as I can see, this would free(l10n_cancel_message) on exit, but
you must never free the result of gettext(). So split this into
_cleanup_free_ const char *plymouth_cancel_message = NULL;
const char *l10n_cancel_message;
?
r = manager_connect_plymouth(m);
@@ -288,7 +288,8 @@ static int manager_send_plymouth_message(Manager *m,
const char *message) {
m-plymouth_cancel_sent = true;
-plymouth_cancel_message = strjoina(fsckd-cancel-msg:,
_(Press Ctrl+C to cancel all filesystem checks in progress));
+l10n_cancel_message = _(Press Ctrl+C to cancel all
filesystem checks in progress);
+plymouth_cancel_message = strjoina(fsckd-cancel-msg:,
l10n_cancel_message);
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 9 commits - configure.ac .gitignore Makefile.am Makefile-man.am man/systemd-fsckd.service.xml man/systemd-f...@.service.xml po/de.po po/el.po po/fr.po po/hu.po po
Le 10/03/2015 11:55, Lennart Poettering a écrit :
On Tue, 10.03.15 08:33, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-03-09 19:11 +0100]:
Anyway, please look into fixing this, I am kinda relying on patches
for this, as I don't use this myself. Fedora isn't set up for it, nor
do I use a file system that still requires fsck at boot...
Yep, we'll fix those. But for the record, this can be tested easily
anywhere by replacing /usr/sbin/fsck with test/mocks/fsck (I'm on
btrfs myself..)
Hmm, is there also a ply mocker? That would be good!
There is none AFAIK, I'm using plymouth-x11 which is working quite well.
The only difficulty that I realized is that Control+C doesn't work for
cancelling into that X window. Consequently, everytime I changed to c
or any other key to test.
Well, again: fsck should *not* 'forward'. It should not be bothered at
all with processing stdout of the actual fsck tool at all. Instead it
should open a AF_UNIX/SOCK_STREAM connection to fsckd, use shutdown()
to close the read side, and then make the resulting fd the fd passed
to fsck's -C parameter. That way, the fsck tool will pass the progress
data *directly* to systemd-fsckd, and systemd-fsck will never see it
at all!
The suggestion is now implemented in the attached patch. Please note
that they rely on 0001-fsckd-Don-t-use-strjoina-on-gettext-call.patch
(just posted a new version) and
0002-fsckd-check-if-plymouth-is-running-before-attempting.patch (didn't
change that one).
It should handle what you had your mind, still enabling cancellation
through SIGTERM while removing the need for intermediates sockets.
Please note that I needed to open in systemd-fsck the socket in the
fork() children part to be able to identify the right fsck pid. I thus
used then an empty cmdline[] slot for this. Another way would be to
build the command line in the fork() children call entirely of course.
Not sure what you would prefer.
As always, I'm opened to any suggestion and hope that will satisfy your
original vision more :)
Cheers,
Didier
From cdfcfb8490cd07c7b9129e6ce7c382c962c2c4dd Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Wed, 11 Mar 2015 12:58:39 +0100
Subject: [PATCH 3/3] fsckd: directly connect fsck output to systemd-fsckd
* Remove the intermediate structure to handle progress report and cancellation
communication from systemd-fsck to systemd-fsckd.
* Directly connect fsck -Cfd to systemd-fsckd. systemd-fsck doesn't get any
fd connecting from fsck anymore.
* Handle cancellation in systemd-fsckd by directly SIGTERM the fsck process
(which in turn, will make systemd-fsck terminate)
* In case of premature termination of fsck, only ignore the unidentified error
if SIGTERM was sent.
---
src/fsck/fsck.c | 111 ---
src/fsckd/fsckd.c | 154 ++
src/fsckd/fsckd.h | 13 -
3 files changed, 130 insertions(+), 148 deletions(-)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 6e46633..b3dbd29 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -27,6 +27,7 @@
#include fcntl.h
#include sys/file.h
#include sys/stat.h
+#include sys/socket.h
#include sd-bus.h
#include libudev.h
@@ -130,81 +131,38 @@ static void test_files(void) {
}
-static int process_progress(int fd, pid_t fsck_pid, dev_t device_num) {
-_cleanup_fclose_ FILE *f = NULL;
-usec_t last = 0;
-_cleanup_close_ int fsckd_fd = -1;
+static int make_progress_fd(void) {
static const union sockaddr_union sa = {
.un.sun_family = AF_UNIX,
.un.sun_path = FSCKD_SOCKET_PATH,
};
+int fsck_fd;
-fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
-if (fsckd_fd 0)
-return log_warning_errno(errno, Cannot open fsckd socket, we won't report fsck progress: %m);
-if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un, sun_path) + strlen(sa.un.sun_path)) 0)
-return log_warning_errno(errno, Cannot connect to fsckd socket, we won't report fsck progress: %m);
+fsck_fd = socket(AF_UNIX, SOCK_STREAM, 0);
+if (fsck_fd 0)
+return log_warning_errno(errno, Cannot crate fsck socket, we won't report fsck progress: %m);
-f = fdopen(fd, r);
-if (!f)
-return log_warning_errno(errno, Cannot connect to fsck, we won't report fsck progress: %m);
-
-while (!feof(f)) {
-int pass;
-size_t buflen;
-size_t cur, max;
-ssize_t r;
-usec_t t;
-_cleanup_free_ char *device = NULL;
-FsckProgress progress;
-FsckdMessage fsckd_message;
-
-if (fscanf(f, %i %lu %lu %ms, pass, cur, max, device) != 4)
-break;
-
-/* Only update once every 50ms */
-
Re: [systemd-devel] SAT for dependencies
On Wed, Mar 11, 2015 at 01:25:36PM +0100, Max wrote: Hello. Part of the core systemd functionality is dependency resolution between jobs which should be executed. This sounds rather similar to dependencies between packages which has been solved using SAT solver tools. I wonder if it might make sense to use something like https://github.com/msoos/cryptominisat from within systemd for that? Not really. The dependency solver is very simple, because the dependencies are simple and are solved greedily. Or maybe somebody already tried that? Also, am I right that dependency resolution logic is in src/core/job.c or I should look into some other code as well? src/core/transaction.c. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] libsystemd-daemon wrapper
On Wed, Mar 11, 2015 at 01:18:37PM +0100, Max wrote:
23.02.2015 13:29, Lennart Poettering пишет:
On Mon, 23.02.15 11:30, Max (maxim.sur...@campus.tu-berlin.de) wrote:
Hi.
I've got question partially inspired by recent posts to this ML from some
troll
without shift on his keyboard :)
It's been mentioned that calls like sd_listen_fds(0) and others become
NOOP when
socket activation is not available due to lack of systemd. Which is fine
but leads to
rather inflated code as in here:
http://0pointer.de/blog/projects/socket-activation.html
Is there some wrapper library which hides this boilerplate from developers?
I mean instead of writing every time code like
if (sd_listen_fds(0) 1) {
... // error
} else if (n == 1)
... // systemd OK
else {
... // fallback to legacy
}
I'd really prefer to use something like:
int fd = listen_on_fd_with_or_without_systemd(...);
which effectively incorporates all the fallback-to-legacy logic.
The same question, naturally, applies to non-scocket-activation daemons.
I've tried to search for it but unfortunately came up with nothing so I'd
appreciate
links to such projects or to documentation which would explain why this
kind of
wrapper is really stupid idea :)
For testing purposes we do provide the systemd-activate tool to run
socket activated daemons without socket activation.
I am not really sure thought whether we should provide more than
that.
I'm pretty-sure you shouldn't - I'm afraid I've been unclear. I rather though
that
such wrapper library might exist as a part of some other project which aims to
simplify support both systemd and legacy system. Or it might have been
developed
while porting some code to systemd as an effort to try to preserve backward
compatibility. I don't really think this belongs to systemd itself.
Internal or external to systemd is not the question.
The real problem is listed in the paragraph quoted below: the details
of opening of sockets are specific to an application, so the wrapper
library could only provide a set of helper functions which wrap BSD
socket API, but this API is already as simple as possible, so there is
nothing to be gained in doing that.
The thing is simply that I cannot see how an API we would
provide could be any simpler than the BSD socket API is on its own. If
you want to listen on something, you need socket(), maybe a couple of
setsockopt()s, a bind() and a listen(). Any API that would wrap that
would kinda need the same amount of function calls, hence wouldn't be
any shorter or easier with it...
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SAT for dependencies
Hello. Part of the core systemd functionality is dependency resolution between jobs which should be executed. This sounds rather similar to dependencies between packages which has been solved using SAT solver tools. I wonder if it might make sense to use something like https://github.com/msoos/cryptominisat from within systemd for that? Or maybe somebody already tried that? Also, am I right that dependency resolution logic is in src/core/job.c or I should look into some other code as well? best regards, Max. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden sh...@churchofgit.com wrote: On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. The recent systemd-boot boot loader and efi stub loader which carries the kernel, the cmdline, the initrd in one single EFI binary will also not use any boot loader snippets, it will be discovered by the loader itself, which parses the PE/COFF files and looks for specific content. The snippets are meant to unify the boot loader *configuration*, but they do not mean that every bootable kernel will or should have one. There might be many ways for kernels to be found by the boot loader, the snippets are just one source for that. I'm not sure what exact problem this patch tries to solve, rebooting with kexec is faster than a full reboot. Currently we do not support kexec very well. Lennart asked for something like this, but perhaps we no longer want to support kexec loading? I kind of miss a description what this change is supposed to support in the end. It can't be described with replacing a call to a binary. Automatic searching and deciding what kernel to boot, and how to search for these kernels, and how all that should continue to work reliably in the longer run, while the boot loaders underneath improve and change; that is something we should define before and have a clear idea, before we copy only parts of that logic from the current tools. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: generate pkg-config files during configure
On Wed, Mar 11, 2015 at 5:04 AM, Jeff Waugh j...@bethesignal.org wrote: Generate pkg-config files during configure as God (Havoc) intended. This fixes all of systemd's pkg-config files when cross-compiling (and possibly other use cases). Thoughts, feelings? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Wed, Mar 11, 2015 at 6:24 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden sh...@churchofgit.com wrote: On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. The recent systemd-boot boot loader and efi stub loader which carries the kernel, the cmdline, the initrd in one single EFI binary will also not use any boot loader snippets, it will be discovered by the loader itself, which parses the PE/COFF files and looks for specific content. The snippets are meant to unify the boot loader *configuration*, but they do not mean that every bootable kernel will or should have one. There might be many ways for kernels to be found by the boot loader, the snippets are just one source for that. I'm not sure what exact problem this patch tries to solve, rebooting with kexec is faster than a full reboot. Currently we do not support kexec very well. Lennart asked for something like this, but perhaps we no longer want to support kexec loading? I kind of miss a description what this change is supposed to support in the end. It can't be described with replacing a call to a binary. Automatic searching and deciding what kernel to boot, and how to search for these kernels, and how all that should continue to work reliably in the longer run, while the boot loaders underneath improve and change; that is something we should define before and have a clear idea, before we copy only parts of that logic from the current tools. I thought you wrote a specification? freedesktop.org/wiki/Specifications/BootLoaderSpec/ Anyways, you should at least merge this patch: 1423865887-1507-1-git-send-email-sh...@churchofgit.com ( https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28005.html ) Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] minimal required units
В Wed, 11 Mar 2015 12:02:29 -0700 aaron_wri...@selinc.com пишет: I'm trying to make an embedded device, and I would like to start with the minimal setup as possible. Are there some units that are required by systemd? I ask because systemd is complaining about a missing rescue.target unit, When does it do it? but I don't list rescue.target as a dependency of any other unit. However, grep tells me that /usr/lib/systemd/systemd contains the rescue.target string, which worries me. Is there a list of all the units that are required, even though no other unit lists them? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Appc support in systemd-importd
Hi, We're looking into adding appc[1] support in systemd-importd. An appc image (ACI) is just a tar with a rootfs directory and a json manifest. We would have to implement image discovery and simply extract the rootfs. Some questions: * I see that the dkr implementation ignores the information in the docker manifest (resource restrictions, binary to exec...). Is that by design or just not implemented yet? Should we do the same with appc (*only* extract the rootfs)? * Alban liked the idea of saving the manifest so we can extract the whole ACI and modify nspawn to detect a container is an ACI and set /var/lib/machines/appc-image.aci/rootfs as the container's root. The benefit of keeping the manifest would be knowing which binary to start. Is that acceptable? [1]: https://github.com/appc/spec/blob/master/SPEC.md Cheers, Iago -- Iago López Galeiras, Endocode AG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Linking containers
Excerpts from Peter Paule's message of 2015-03-02 18:49:42 +0100: I am not sure I want to talk a TCP/TLS based protocol just to add a interface to a local switch. To integrate this stuff closely they should either provide a C library, or a bus API or something similar, but having to reimplement a new protocol just to be able to add an interface to a switch is too much... There's a C-API available, but it's poorly documented. Here's the answer from one of the `of-config`-maintainers: I'm afraid that ovsdb-idl.h (and the commented code of the functions declared there) is the only source of information. The ovs-vsctl tool also uses IDL, so you can inspire there. You can also try to aks in openvswitch's ovs-dev mailing list. https://github.com/openvswitch/ovs/blob/acf72f1322a041fdf30a1c115dbc0e7a6dffac00/lib/ovsdb-idl.c https://github.com/openvswitch/ovs/blob/acf72f1322a041fdf30a1c115dbc0e7a6dffac00/lib/ovsdb-idl.h I understand that. I just mentioned it because you would gain support for other sw/hw products as well because OpenFlow is vendor-agnostic. BTW: I opened a ticket at their repository at github. Maybe I get some more usable information I can pass on to you. The --network-veth and --network-bridge= switches currently support only a single interface. If you want more you need to set them up first, and then move them into the container with --network-interface= which may be called multiple times. Ok. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to remove images using machinectl
Excerpts from Lennart Poettering's message of 2015-03-03 11:40:54 +0100: On Tue, 03.03.15 07:11, Peter Paule (systemd-de...@fedux.org) wrote: Excerpts from Erik Johnson's message of 2015-03-02 14:10:06 -0700: Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: @Erik Did you use the aur package or did you compile systemd and install it using make? Do you have experience rolling back to the normal package provided by arch? To fix the bus policy it is sufficient to copy that one file in. The policy XML file is not processed any further it's installed as is into the system. I'm just asking because I thought about installing systemd on my arch, but as it is my machine which I use very frequently I don't want to crash it. :-) @Lennart Is is difficult to get rid of a systemd package installed from git? Well if you built systemd with ./autogen.sh c make -j6 sudo make install then you should be able to simply install the original package from your distro again and it should replace everything again. Thanks :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: add kexec loading, avoid calling `kexec` binary unnessecarily
On Thu, Mar 12, 2015 at 2:36 AM, Shawn Landden sh...@churchofgit.com wrote: On Wed, Mar 11, 2015 at 6:24 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 2:07 AM, Shawn Landden sh...@churchofgit.com wrote: On Wed, Mar 11, 2015 at 5:51 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Mar 12, 2015 at 1:22 AM, Shawn Landden sh...@churchofgit.com wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. I think the rbtree version was far more understandable as greedy_realloc0() is very messy to do correctly. Take fopenat() from lsof. Add opendirat() We have that in util.c :: xopendirat() Future: generate BootLoaderSpec files for other kernel install locations This approach duplicates, the potentially complex, boot manager kernel selection logic. The recent systemd-boot boot loader and efi stub loader which carries the kernel, the cmdline, the initrd in one single EFI binary will also not use any boot loader snippets, it will be discovered by the loader itself, which parses the PE/COFF files and looks for specific content. The snippets are meant to unify the boot loader *configuration*, but they do not mean that every bootable kernel will or should have one. There might be many ways for kernels to be found by the boot loader, the snippets are just one source for that. I'm not sure what exact problem this patch tries to solve, rebooting with kexec is faster than a full reboot. Currently we do not support kexec very well. Lennart asked for something like this, but perhaps we no longer want to support kexec loading? I kind of miss a description what this change is supposed to support in the end. It can't be described with replacing a call to a binary. Automatic searching and deciding what kernel to boot, and how to search for these kernels, and how all that should continue to work reliably in the longer run, while the boot loaders underneath improve and change; that is something we should define before and have a clear idea, before we copy only parts of that logic from the current tools. I thought you wrote a specification? freedesktop.org/wiki/Specifications/BootLoaderSpec/ It does not specify how to find or select new kernels, and it probably never will. Boot loaders are free to add anything they want to offer. The boot loader spec mainly tries to unify the explicit *configuration*, but not the logic inside the boot loaders. Even gummiboot has its own config file, which specifies the pattern for the default selection logic, that is all intentionally not part of the spec, but it changes the way the selection logic works inside the loader. Now with the boot loader merged into system tree, we could potentially share some code here, but I still don't see how all that fits together, and we should find that out before we make any promises like that. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] initrd mount wrongly unmounted during bootup
В Wed, 11 Mar 2015 11:26:52 -0700 aaron_wri...@selinc.com пишет: I'm working with an embedded device that mounts / and /var in initrd. It then switches root and fires up systemd. Early in the boot, after paths target, /var gets unmounted. I want systemd to not do that, but I can't figure out how to stop it. I would like systemd to leave /var mounted, but still unmount it during shutdown. I would rather not move the mounting of /var out of initrd. Is this possible? I'm trying to use a very stripped down systemd. As minimal as possible. Do you use udev in initrd? I'm using systemd-219. The logs say that var.mount is bound to an inactive unit, and it is stopping too. I assume that is why /var gets unmounted, but I don't know what to do to stop it. There is no /etc/fstab file. There is no var.mount file. I assume I'm either missing something simple, or it is not possible. Did you try this commit? commit 628c89cc68ab96fce2de7ebba5933725d147aecc Author: Lennart Poettering lenn...@poettering.net Date: Fri Feb 27 21:55:08 2015 +0100 core: rework device state logic This change introduces a new state tentative for device units. Device units are considered plugged when udev announced them, dead when they are not available in the kernel, and tentative when they are referenced in /proc/self/mountinfo or /proc/swaps but not (yet) announced via udev. This should fix a race when device nodes (like loop devices) are created and immediately mounted. Previously, systemd might end up seeing the mount unit before the device, and would thus pull down the mount because its BindTo dependency on the device would not be fulfilled. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
В Wed, 11 Mar 2015 18:50:23 +0100 Kay Sievers k...@vrfy.org пишет: On Wed, Mar 11, 2015 at 6:32 PM, Chris Murphy li...@colorremedies.com wrote: On Wed, Mar 11, 2015 at 2:22 AM, Tobias Hunger tobias.hun...@gmail.com wrote: If you're concerned about bootloader configuration modification as a threat vector, then it needs to go on an encrypted volume. This suggests an initial bootloader configuration that only enables the user to supply a passphrase/key file to unlock that volume, and then load a new bootloader configuration file. I am still hoping secure boot and sd-boot will solve this issue mid-term by making sure all the early boot components are signed properly. The bootloader configuration files aren't signed. Maybe the should be. With systemd-boot, there will be no config to sign: https://harald.hoyer.xyz/2015/02/25/single-uefi-executable-for-kernelinitrdcmdline/ How exactly putting files in a container solves the problem that they are not signed? This is not quite obvious from blog post. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
В Wed, 11 Mar 2015 14:41:43 -0600 Chris Murphy li...@colorremedies.com пишет: On Wed, Mar 11, 2015 at 1:56 PM, Kay Sievers k...@vrfy.org wrote: Systemd by default mounts it with autofs, it will not be mounted until it is accessed, which does not happen during normal operation. We currently miss autofs timeout handling, which would umount /boot again when it is no longer used. That would make stuff pretty robust, I expect. It's just that distros have their rather broken concept of putting it into fstab, and even cascading mounts with splitting /boot and the ESP. That's an improvement, sure. But the very idea of ESPs that need any post-install modification in the first place is what introduces this fragility in the first place. Windows never makes ESP modifications post-install, Windows bootloader configuration is stored on ESP; of course it is not changed often. Also Windows still needs to update bootloader every now and then. This is actually quite similar to secure boot with grub2 used by Linux today where only pointer to /boot need to be set. As neither binary nor grub.cfg snippet normally change we probably could skip even that after initial installation. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
