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
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
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
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
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
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
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.
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
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
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
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
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
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
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:
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
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
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
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
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
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
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:
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
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
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
В 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
В 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
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
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
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
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
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
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
32 matches
Mail list logo
