Re: [systemd-devel] How to factory reset?
On Mon, 16.03.15 11:31, Tobias Hunger (tobias.hun...@gmail.com) wrote: Just a short update: I managed to get my machine image to (kind of) boot in systemd-nspawn this weekend. Kind-of as it tries to mount some drives that are obviously not there in the container. But apart from that it seems to boot fine:-) On real hardware I am not so lucky: Once I get to system-switch-root.service I get lots of output about missing nodes in dev (/dev/ttyX mostly). Note that systemd only supports /dev mounted from devtmpfs, where the nodes are created by the kernel (and not userspace), and hence cannot really be missing. If the nodes are missing this is an indication that /dev is configured in some other way... 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] How to factory reset?
On Wed, 11.03.15 20:56, Kay Sievers (k...@vrfy.org) wrote: 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. Quick update on this: autofs expiry is now implemented and enabled for the ESP mount systemd does by default. This should shorten the time-frame of corruptions of the ESP quite a bit. 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] How to factory reset?
On Fri, 13.03.15 01:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger tobias.hun...@gmail.com wrote: presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical piece of information that can not get restored via tmpfiles.d. Thinking about this a bit longer: /usr does not seem like a good idea. The machine-id is supposed to be unique and usr-images are meant to be reused. Maybe provide a kernel command line option to force the machine-id if none is set yet? I think this could be an option. We currently check /var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid. I think that the first should work for your use case, since you keep /var. But we also check some commandline option, this seems useful for some use cases. I think /var/lib/dbus/machine-id is nothing to use here. It purely exists for compat with upgrades from classic dbus1 systems, where we should avoid inventing a new machine id, if the dbus one is fine. I'd be fine with adding a kernel switch to make this configurable, as Zbigniew suggested. 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] How to factory reset?
On Fri, 13.03.15 14:20, Tobias Hunger (tobias.hun...@gmail.com) wrote: Hi Zbyszek, I would expect the machine-id to be written before mount units are processed, so for that to work I would need to mount /var in the initrd, wouldn't I? Yeah, /var/lib/dbus/machine-id isn't a general purpose solution, since /var ca nbe mounted very late. (Also, as mentioned in other mail, it's compat only, please don't use it.) Currently I am trying to just write the machine-id to /etc in the initrd. This makes systemd loose the understanding that /etc is empty though, which might have some side-effects that I am not yet anticipating. Isn't systemd started from inside the initrd once the new root has been set up? Maybe I could set $container_uuid and feed the machine-id to systemd that way? I am afraid that this will lead to some other side-effects, because systemd might assume to be running inside a container. Looks like I will have to do some testing over the weekend:-) $container_uuid is only used in containers. If you set it in other conditions, we don't care. Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. That is only read on kvm, since on physical hardware it is more often than not filled with rubbish, that is not useful as a real machine id. 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] How to factory reset?
Just a short update: I managed to get my machine image to (kind of) boot in systemd-nspawn this weekend. Kind-of as it tries to mount some drives that are obviously not there in the container. But apart from that it seems to boot fine:-) On real hardware I am not so lucky: Once I get to system-switch-root.service I get lots of output about missing nodes in dev (/dev/ttyX mostly). This might be due to me messing up the configuration, arch's mkinitcpio being unprepared to handle a stateless system or some problem in systemd. At this time I am not sure which. I am rather positive that this will be really straight forward to figure out once I can actually get a shell in the initrd, which unfortunately seems harder than expected on Arch Linux (provided you use systemd HOOK in /etc/mkinitcpio.conf, which is not the recommended way of doing things):-/ Best Regards, Tobias PS: Any hints on systemd-in-initrd debugging in arch linux would be appreciated at this point:-) On Fri, Mar 13, 2015 at 2:20 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Zbyszek, I would expect the machine-id to be written before mount units are processed, so for that to work I would need to mount /var in the initrd, wouldn't I? Currently I am trying to just write the machine-id to /etc in the initrd. This makes systemd loose the understanding that /etc is empty though, which might have some side-effects that I am not yet anticipating. Isn't systemd started from inside the initrd once the new root has been set up? Maybe I could set $container_uuid and feed the machine-id to systemd that way? I am afraid that this will lead to some other side-effects, because systemd might assume to be running inside a container. Looks like I will have to do some testing over the weekend:-) Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. Best Regards, Tobias On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger tobias.hun...@gmail.com wrote: presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical piece of information that can not get restored via tmpfiles.d. Thinking about this a bit longer: /usr does not seem like a good idea. The machine-id is supposed to be unique and usr-images are meant to be reused. Maybe provide a kernel command line option to force the machine-id if none is set yet? I think this could be an option. We currently check /var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid. I think that the first should work for your use case, since you keep /var. But we also check some commandline option, this seems useful for some use cases. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
Hi Zbyszek, I would expect the machine-id to be written before mount units are processed, so for that to work I would need to mount /var in the initrd, wouldn't I? Currently I am trying to just write the machine-id to /etc in the initrd. This makes systemd loose the understanding that /etc is empty though, which might have some side-effects that I am not yet anticipating. Isn't systemd started from inside the initrd once the new root has been set up? Maybe I could set $container_uuid and feed the machine-id to systemd that way? I am afraid that this will lead to some other side-effects, because systemd might assume to be running inside a container. Looks like I will have to do some testing over the weekend:-) Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. Best Regards, Tobias On Fri, Mar 13, 2015 at 1:16 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger tobias.hun...@gmail.com wrote: presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical piece of information that can not get restored via tmpfiles.d. Thinking about this a bit longer: /usr does not seem like a good idea. The machine-id is supposed to be unique and usr-images are meant to be reused. Maybe provide a kernel command line option to force the machine-id if none is set yet? I think this could be an option. We currently check /var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid. I think that the first should work for your use case, since you keep /var. But we also check some commandline option, this seems useful for some use cases. Zbyszek ___ 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 Fri, Mar 13, 2015 at 02:20:04PM +0100, Tobias Hunger wrote: Hi Zbyszek, I would expect the machine-id to be written before mount units are processed, so for that to work I would need to mount /var in the initrd, wouldn't I? (Without looking at the code again) I don't think so. machine-id-setup is performed by PID1 itself, and I think it does it quite early. Currently I am trying to just write the machine-id to /etc in the initrd. This makes systemd loose the understanding that /etc is empty though, which might have some side-effects that I am not yet anticipating. Yeah, that does not seem like the right approach. Isn't systemd started from inside the initrd once the new root has been set up? Maybe I could set $container_uuid and feed the machine-id to systemd that way? I am afraid that this will lead to some other side-effects, because systemd might assume to be running inside a container. Looks like I will have to do some testing over the weekend:-) Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. Best Regards, Tobias Zbyszek ___ 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 10/03/15 16:01, Lennart Poettering wrote: Yes, dbus is currently not compatible with stateless bootups. PAM is neither. For PAM we ship a tmpfiles snippet to work around this, for dbus we don't though, since kdbus kinda makes the problem go away... In the meantime, you might be interested in https://bugs.freedesktop.org/show_bug.cgi?id=89280. S ___ 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: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. And maybe done away with in favor of dynamic discovery and hot keys for indicating common boot options. 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. -- 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 1:46 PM, Kay Sievers k...@vrfy.org wrote: 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. :) Apple's raid support is not enabled by Apple firmware. That Apple's firmware understands HFS+ is completely beside the point. They could put their bootloader on the ESP, it's the bootloader that understands Apple raid, finds and loads the kernel. The reason the firmware has HFS+ support baked in is the HFS+ volume header contains a hint for the active system, rather than depending on NVRAM. Back on Linux though, any dependency on proprietary firmware raid, means Btrfs raid cannot be used at all on those drives so I don't see how this is a general purpose solution. BIOS permits a superior solution. -- 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 Thu, Mar 12, 2015 at 11:30 AM, David Herrmann dh.herrm...@gmail.com wrote: On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov arvidj...@gmail.com wrote: В 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. The config/etc. snippets are now part of the _signed_ EFI binary, which is always verified by the firmware. Therefore, we don't need to verify the other snippets separately. http://people.freedesktop.org/~kay/efistub.txt 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?
Hi On Thu, Mar 12, 2015 at 2:41 PM, Andrei Borzenkov arvidj...@gmail.com wrote: initrd and cmdline are volatile and generated on end-user system. So your container must be signed on end user system. End user obviously does not have Microsoft or vendor private keys to sign your container, so end user must manage own keys. Apparently, it is not quite as simple, otherwise we would not need to invent shim in the first place. The signed EFI binary is distributed by your distribution/vendor/key-owner. The machine-owner is responsible of putting the key of your vendor into the firmware. Thanks David ___ 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 Thu, Mar 12, 2015 at 2:41 PM, Andrei Borzenkov arvidj...@gmail.com wrote: On Thu, Mar 12, 2015 at 4:24 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Thu, Mar 12, 2015 at 2:06 PM, Andrei Borzenkov arvidj...@gmail.com wrote: On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann dh.herrm...@gmail.com wrote: 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. The config/etc. snippets are now part of the _signed_ EFI binary, which is always verified by the firmware. Therefore, we don't need to verify the other snippets separately. Where signing key comes from? Is this key generated by user on end system and enrolled in firmware? This is the key used by EFI secure boot. We don't change the semantics in any way. (yes, the key can be provided by the machine owner and stored in firmware, please see EFI specs for information) I know how secure boot works. You misunderstand the question. initrd and cmdline are volatile and generated on end-user system. So your container must be signed on end user system. End user obviously does not have Microsoft or vendor private keys to sign your container, so end user must manage own keys. Apparently, it is not quite as simple, otherwise we would not need to invent shim in the first place. So how do you envision signing of container in practice? In case this was not clear: we envision signed containers (including static cmdline and initrd) being provided by the vendor. This means we need general purpose initrd's and cmdline's that will work without modification on generic systems (which dracut can give us). If people want to roll their own initrd/commandline and still use secure boot, they can still do that, but then they have to sign it themselves (with their own key, which they must enroll, etc). Cheers, Tom ___ 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 Thu, Mar 12, 2015 at 4:24 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Thu, Mar 12, 2015 at 2:06 PM, Andrei Borzenkov arvidj...@gmail.com wrote: On Thu, Mar 12, 2015 at 1:30 PM, David Herrmann dh.herrm...@gmail.com wrote: 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. The config/etc. snippets are now part of the _signed_ EFI binary, which is always verified by the firmware. Therefore, we don't need to verify the other snippets separately. Where signing key comes from? Is this key generated by user on end system and enrolled in firmware? This is the key used by EFI secure boot. We don't change the semantics in any way. (yes, the key can be provided by the machine owner and stored in firmware, please see EFI specs for information) I know how secure boot works. You misunderstand the question. initrd and cmdline are volatile and generated on end-user system. So your container must be signed on end user system. End user obviously does not have Microsoft or vendor private keys to sign your container, so end user must manage own keys. Apparently, it is not quite as simple, otherwise we would not need to invent shim in the first place. So how do you envision signing of container in practice? ___ 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 Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger tobias.hun...@gmail.com wrote: presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical piece of information that can not get restored via tmpfiles.d. Thinking about this a bit longer: /usr does not seem like a good idea. The machine-id is supposed to be unique and usr-images are meant to be reused. Maybe provide a kernel command line option to force the machine-id if none is set yet? I think this could be an option. We currently check /var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid. I think that the first should work for your use case, since you keep /var. But we also check some commandline option, this seems useful for some use cases. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to factory reset?
Hi On Thu, Mar 12, 2015 at 4:57 AM, Andrei Borzenkov arvidj...@gmail.com wrote: В 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. The config/etc. snippets are now part of the _signed_ EFI binary, which is always verified by the firmware. Therefore, we don't need to verify the other snippets separately. Thanks David ___ 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 Mon, 09.03.15 12:02, Tobias Hunger (tobias.hun...@gmail.com) wrote: Hi everybody, I am running a kiosk-like box here and have a read-only copy of /etc hidden away in /usr/ somewhere. /etc is a symlink to that directory and that works fine. Recently I thought I'd experiment with factory reset. My idea was to use a tmpfs mounted on /etc instead of that symlink and populate that from the directory in /usr on boots. That way I can still experiment with changes to the configuration, but on all reboots I get the trusted state back. So how is factory reset supposed to work is systemd? So you want not just factory reset, but actually a stateless system, where every single boot is basically a factory reset? My recommendation would be to set this up within the initrd: mount a tmpfs as /, then mount the physical /usr into it and transition to the host OS. There's currently no explicit support for this to make this easy from the initrd. (It is available in nspawn though with the --volatile=) switch. But it's on the todo list to add that, so that what I describe above is easily available. We also should provide a scheme that one can flush /etc explicitly ones for a factory reset, via a kernel cmdline option. That said, I figure it should suffice to add entries for / and /usr to the fstab and get the initrd to make use of it. Unfortunately the dbus.service will not come up, claiming that there is no /etc/dbus-1/system.conf. This file is in the tarball, and the output during boot-up suggests that dbus.service is started only after the /etc-tarball is extracted, so that file should be there. There seems to be a dbus.socket involved in the start of dbus.service and that is started before the tarball is extracted. Yes, dbus is currently not compatible with stateless bootups. PAM is neither. For PAM we ship a tmpfiles snippet to work around this, for dbus we don't though, since kdbus kinda makes the problem go away... Should I take a different approach entirely and e.g. populate /etc in the initrd? I'd like to keep the initrd generic if I can, so I am not happy with that idea. I am using systemd-nspawn for my experiments. This seems to add some files to /etc, which is not ideal, but does not seem to hurt too much either. Is there a better way to test setups like the one I intend to get? nspawn's --volatile= switch is how i did most of my own testing... Does systemd-nspawn indeed add/change files in /etc of the directory it is running from? Well, nspawn isn't. But systemd will, if it finds /etc empty. It will create a machine ID, and apply presets and stuff... 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] How to factory reset?
On Wed, Mar 11, 2015 at 9:39 PM, Andrei Borzenkov arvidj...@gmail.com wrote: 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. I'm not seeing a BCD on the ESP, that's usually on NTFS historically anyway. I see bootmgfw.efi, and bootmgr.efi. This is actually quite similar to secure boot with grub2 used by Linux today where only pointer to /boot need to be set. Right, with a grub.cfg using configfile on the ESP to point to a real grub.cfg, or BLS snippets, on /boot. Or even better would be dynamic discovery similar to gummiboot, rEFInd, and the built-in boot manager in Apple's firmware (talk about something that's very rarely updated). As neither binary nor grub.cfg snippet normally change we probably could skip even that after initial installation. Yes I'd like to see GRUB on the ESP be totally generic, except for an installer created grub.cfg that merely forwards to the real one on /boot. Then it's on a more reliable fs, it can be mirrored, and that one is always updated when there are kernel upgrades, rather than the one on the ESP. openSUSE does this already, maybe also Ubuntu. Fedora doesn't, it's main grub.cfg is on the ESP and that's the one always modified whenever kernels are installed, and since Fedora gets lots of kernel updates, this file is always being modified. I've tried to encourage a different strategy! https://bugzilla.redhat.com/show_bug.cgi?id=1048999 -- 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 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] 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] 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
Re: [systemd-devel] How to factory reset?
Hi Lennart, thanks for taking the time to answer! It is highly appreciated. On Tue, Mar 10, 2015 at 5:01 PM, Lennart Poettering lenn...@poettering.net wrote: So you want not just factory reset, but actually a stateless system, where every single boot is basically a factory reset? Yes, but I do have a state that I want to be applied by default at all times. My recommendation would be to set this up within the initrd: mount a tmpfs as /, then mount the physical /usr into it and transition to the host OS. That is a great idea! I was so focused on having a tmpfs on /etc that I did not even think about that:-/ I would like to keep e.g. logs between reboots, so maybe I can just have /var mounted from somewhere else. There's currently no explicit support for this to make this easy from the initrd. There are flags to set the root filesystem and equivalent flags for the usr one, so that should not be too hard to do. (It is available in nspawn though with the --volatile=) switch. But it's on the todo list to add that, so that what I describe above is easily available. We also should provide a scheme that one can flush /etc explicitly ones for a factory reset, via a kernel cmdline option. Please do not do that. Even if all filesystems are encrypted you could factory-reset random computers you have access to, simply by editing the bootloader configuration file usually found in the poorly protected EFI partition! Better have a unit that deletes /etc before the system is shut down. That way you at least need to have root access to the running machine to trigger a factory reset. That keeps at least people with encrypted drives save:-) That said, I figure it should suffice to add entries for / and /usr to the fstab and get the initrd to make use of it. I do not have no stinking fstab:-) My boxes are built up from bits and pieces of configuration. The mount units make are just so much nicer to handle than having several pieces edit the same file:-) Yes, dbus is currently not compatible with stateless bootups. PAM is neither. For PAM we ship a tmpfiles snippet to work around this, for dbus we don't though, since kdbus kinda makes the problem go away... I do have state for PAM, dbus and everything else, I was just not able to get it into place in time for those services to start properly. There are quite a few services with a condition of writable /etc, and with the setup I attempted /etc was writable, even before I managed to put my tmpfs into place and extract my configuration there. nspawn's --volatile= switch is how i did most of my own testing... I did not use --volatile since I need to boot from an image that is considerably different from the one on my development machine. So I will have to set up a tmpfs manually and mount a usr there and then just use normal nspawn with --directory. Having --volatile=/path/to/usr/directory would be nice to have for the experiments I do right now. I guess that is not so very common that it makes sense to consider sending in a patch for that. Well, nspawn isn't. But systemd will, if it finds /etc empty. It will create a machine ID, and apply presets and stuff... I *have* a machine ID and everything. Can I get that information into place somehow *before* systemd creates all of that? Thanks again for your reply. You did provide some food for further experiments: 1) Extract my etc-tarball to /usr/share/factory/etc and remove /etc from the root-image. Keep the etc.mount unit. 2) Try a empty root image with my etc-tarball extracted to /usr/share/factory/etc and no etc.mount. 3) Add var.mount to the setup of 2) to keep the logs. With a bit of luck that should stop all the units that have a condition on a writable /etc from getting started. I'll get back with results:-) Best Regards, Tobias ___ 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 Tue, 10.03.15 18:13, Tobias Hunger (tobias.hun...@gmail.com) wrote: So you want not just factory reset, but actually a stateless system, where every single boot is basically a factory reset? Yes, but I do have a state that I want to be applied by default at all times. Well, you want the factory defaults to be applied when the machine comes up, right? My recommendation would be to set this up within the initrd: mount a tmpfs as /, then mount the physical /usr into it and transition to the host OS. That is a great idea! I was so focused on having a tmpfs on /etc that I did not even think about that:-/ I would like to keep e.g. logs between reboots, so maybe I can just have /var mounted from somewhere else. Hmm, currently we focussed on two models: a) fully volatile, meaning / as tmpfs, with /usr mounted from physical media b) with only volatile state, but persitent configuration, meaning / mounted from physical media, and /var as tmpfs. Your model appears to be different from that. You actually want /var from from physical media, but /etc from tmpfs? That would be kinda the opposite of b)... Do you actually want all of /var mounted of physical media? If you are interested in just logging, maybe just adding a normal mount for /var/log/ should suffice, leaving the rest of /var on tmpfs? (It is available in nspawn though with the --volatile=) switch. But it's on the todo list to add that, so that what I describe above is easily available. We also should provide a scheme that one can flush /etc explicitly ones for a factory reset, via a kernel cmdline option. Please do not do that. Even if all filesystems are encrypted you could factory-reset random computers you have access to, simply by editing the bootloader configuration file usually found in the poorly protected EFI partition! Well, if you have access to the kernel cmdline you can do whatever you want. init=/bin/sh is infinitely more powerful than just being able to flush out /etc... Better have a unit that deletes /etc before the system is shut down. That way you at least need to have root access to the running machine to trigger a factory reset. That keeps at least people with encrypted drives save:-) Well, factory resets are supposed to be something that gets you back into a defined state if you fucked up your system. In such a case it might not be possible to boot up anymore to reset the state... Hence having this on the kernel cmdline is kinda a necessity to make this useful in real-life... Having --volatile=/path/to/usr/directory would be nice to have for the experiments I do right now. I guess that is not so very common that it makes sense to consider sending in a patch for that. Hmm, what precisely are you suggesting this would do? Well, nspawn isn't. But systemd will, if it finds /etc empty. It will create a machine ID, and apply presets and stuff... I *have* a machine ID and everything. Can I get that information into place somehow *before* systemd creates all of that? presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. Note though that some services like ldconfig.service also want to write to /etc, to generate some files, if they are missing... If you want to do something before that you have to order those units explicitly before each one of them. Note though that much like /usr, /etc is something that we assume is premounted when systemd is started, and where we do not support mounting it after systemd began its work. I mean, /etc is usually where moutns are configured, but if youw ant to mount someting on /etc, then how is that to be found? Hence, if you want /etc to be volatile, better do that in the initrd... Thanks again for your reply. You did provide some food for further experiments: 1) Extract my etc-tarball to /usr/share/factory/etc and remove /etc from the root-image. Keep the etc.mount unit. This will not work. Please do not work with a an etc.mount unit. Instead do the stuff in the initrd... 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] How to factory reset?
On Tue, Mar 10, 2015 at 6:38 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.03.15 18:13, Tobias Hunger (tobias.hun...@gmail.com) wrote: So you want not just factory reset, but actually a stateless system, where every single boot is basically a factory reset? Yes, but I do have a state that I want to be applied by default at all times. Well, you want the factory defaults to be applied when the machine comes up, right? Kind of:-) I have a somewhat strange mix of ideas taken from docker and Revisiting How We Put Together Linux Systems:-) Basically I have a system a bit like docker that creates images for all the machines I use each night:, very similar to what docker does: You have a file, that defines some base image (which may be empty) and allows you to further customize that image, creating a new image. Unlike docker I create snapshots in a btrfs filesystem, mostly following the ideas you brought forward in the Revisiting blog. The end result is a root:system:vendor:arch and a usr:vendor:arch:timestamp snapshot per physical or virtual machine I run. So initial install of a system is really simple: Partition the HDD, set up a btrfs volume, copy root:s:v:a and a current usr:v:a:t over the network, run a script that updates gummiboot based on usr:v:a:t subvolumes found and reboot. Updates are even simpler: Copy a new usr:v:a:t over, update gummiboot using the same script, reboot. Currently /etc is a symlink to /usr/someplace/etc. That works well, but has the downside that -- since /usr is mounted ro -- I can not just experiment with different configurations anymore. Well, not without remounting /usr rw that is. I think I can do better with all those cool ideas like factory reset and stateless system and such floating around:-) Hmm, currently we focussed on two models: a) fully volatile, meaning / as tmpfs, with /usr mounted from physical media b) with only volatile state, but persitent configuration, meaning / mounted from physical media, and /var as tmpfs. Your model appears to be different from that. You actually want /var from from physical media, but /etc from tmpfs? That would be kinda the opposite of b)... Yes, that is what I want. I have a fully configured system (with that configuration stored in /usr/someplace/etc), I want that system to reset to that configuration regularly (in my case each time it boots), but keep the state. Do you actually want all of /var mounted of physical media? If you are interested in just logging, maybe just adding a normal mount for /var/log/ should suffice, leaving the rest of /var on tmpfs? Most of the data is in /var/log, but depending on services configured other directories in /var might be interesting, too. I might very well decide to deploy a mail server into a VM using my automated setup. I can then boot that and tweak the configuration, restarting the service as necessary. If I screw up then I want a reboot to take me back to something that works. If I improve on the configuration I will just update my image definition and have the change as the default the next time I update. I definitely do not want to loose mails by rebooting the production VM into that updated image, so the state needs to stick around. This is probably not a very common use-case, I admit that. Well, factory resets are supposed to be something that gets you back into a defined state if you fucked up your system. In such a case it might not be possible to boot up anymore to reset the state... Hence having this on the kernel cmdline is kinda a necessity to make this useful in real-life... Hmmm. Right. I assume you are going to nuking /etc without any further user interaction, so my worry is probably unfounded. Having --volatile=/path/to/usr/directory would be nice to have for the experiments I do right now. I guess that is not so very common that it makes sense to consider sending in a patch for that. Hmm, what precisely are you suggesting this would do? Have / of the machine be a tmpfs and mount /path/to/usr/ into as /usr there. Forget about this, I do not think that would be widely useful and as script fixes me up nicely:-) presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical
Re: [systemd-devel] How to factory reset?
On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger tobias.hun...@gmail.com wrote: presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical piece of information that can not get restored via tmpfiles.d. Thinking about this a bit longer: /usr does not seem like a good idea. The machine-id is supposed to be unique and usr-images are meant to be reused. Maybe provide a kernel command line option to force the machine-id if none is set yet? Best Regards, Tobias ___ 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 Tue, Mar 10, 2015 at 11:13 AM, Tobias Hunger tobias.hun...@gmail.com wrote: Even if all filesystems are encrypted you could factory-reset random computers you have access to, simply by editing the bootloader configuration file usually found in the poorly protected EFI partition! 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. GRUB2 kinda does support this. The ESP grub.cfg can handle the cryptodisk and luksopen to grant access to the encrypted volume; and configfile command to load a new grub.cfg located on that volume. And from there the boot is normal including reading kernel and initramfs from the encrypted volume. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel