;re essentially asking "how does rpm-ostree work?".
> I won't try to repeat the rpm-ostree/bootc docs inline here.
> The design of those systems is fairly well documented online.
> Please read those docs.
Nah, this seems to be an option, not the defa
am pretty sure
there are many other tools like that in a similar situation, and not
sure you want to rule out all of them. systemd-firstboot's
--image=/--root= tool also wouldn't work btw, nor systemd-tmpfiles
--image=/--root=).
Again, I am not sure I grok why ostree insists on managi
On Mi, 23.04.25 13:27, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Tue, Apr 22, 2025 at 03:57:42PM +0200, Lennart Poettering wrote:
> > I don't follow? The UID assignments are stored in /etc/passwd,
> > i.e. your example config file and the UID assignme
etworkManager.
Hence it's really pointless to enable systemd-networkd-wait-online,
it's never gonna work if you use a different network management
solution.
Hence, you have to look at NetworkManager's wait-online tool, and
figure out if and how to configure it, but that's so
hat the UID column of sysusers.d/ snippets actually can
take a path in the fs instead of a numeric UID. If you really want to
do weird stuff, such as flushing out /etc/ on boot (though I seriously
don't grok why in heaven you'd do that? you are just shooting off the
legs you stand on that
he user upgrades, and the file in the image is owned by a gid that
> maps to a different group in the local database or to no group and
> is listed as unowned.
How does this bootc thing update? it deletes /etc/passwd? Why would it
do that? seems, humm, weird?
I don't follow at all
as something similar.
Note that means your boot will be delayed until networking is
complete. Depending on your setup that might or might not be what you
want.
And if you have more than a single interface you might want to
fine-tune what "being onlin
s and there would not be any conflict of
ownership anymore.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
http
ng with us on this, would be
happy to!
For example, if you think that exposing JSON user group records via
said API would be an option for kanidm, then I'd be happy to add the
fields you need to the spec (i.e. this spec:
https://systemd.io/USER_RECORD
ium capabilities to make /etc/shadow changes, which
are probably CAP_CHOWN + CAP_DAC_OVERRIDE. These two caps single
handedly are easily escalated to full root however, hence this doesn't
improve things too much, but maybe a bit (because any files the
service write are unpriv owned at least)
orry, but marhsalling is not where the cost is for local IPC. In
current Linux systems it's roundtrips, roundtrips, roundtrips. Forget
everything else.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject
packet.Especially when applications needing
> expanded responses already have DNS packet parsing implemented.
Well DNS RRsets are tiny, even in a DNSSEC world. "raw" bytes are
typically encoded in base64 in json, and that's what resolved does if
you ask for the raw bytes. b
#x27;s socket for that into the container. This is a model not
available to D-Bus (since *everything* is multiplex over the same
socket).
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
s relying on it. I trust you
> know about D-Bus much more than me and that it can pass binary encoded and
> structured information too. But I am not sure whether complete name
> resolution history on machine should pass via DBus. In whatever
to
> > go. There's work going on to add ALPN and stuff hooked into
> > systemd-resolved already. It provides simple SRV resolution APIs
> > already, asynchronously.
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
>
> There is not any
0's pty). This
> > matters a lot and makes a major difference.
>
> As I said this is under Plasma KDE Konsole.
That does not answer the question. Is it the inner or the outer pty
you are issuing that stty command on?
Lennart
--
Lennart Poettering, Berlin
--
_
t; QQQ io-util.c:218 ppoll_usec fds 0 nfds 1 timeout 9
>
> $
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Cod
s simple SRV resolution APIs
already, asynchronously.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://
On Do, 10.10.24 17:22, Simo Sorce (s...@redhat.com) wrote:
> On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote:
> > On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote:
> >
> > >
> >
> > This was again a reference to the fact that IPA folks
ot is a much fine grained
approach, i.e. it can lock disk encryption to the OS vendor, the
device vendor and its configuration.
I wished Fedora would focus more on making Measured Boot by default a
thing (other distros are working towards that, for example SUSE has
been investing in that), but Fedora
different time, it is from a different use case.
> In general you expect full disk encryption on corporate/centrally
> managed machines, not per-user encryption, unless you can escrow per-
> user encryption credentials, which I do not think systemd-homed is well
> positioned to d
still ongoing on how this should
look like in the end, and particular what the right paths are to use
for the 2nd copy.
I'd recommend to wait for this discussion to be resolved.
Lennart
--
Lennart Poettering, Berlin
--
___
dev
e trying to say here?
>
> Read-only snapshot contents are immutable, even by the root user.
Sure, but that's fine in an idmapped world.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscri
On Mi, 09.10.24 09:59, Lennart Poettering (mzerq...@0pointer.de) wrote:
> That said, for compat with traditional subuid/subgid as per the table
> on https://systemd.io/UIDS-GIDS the UID/GID range 524288…1879048191 is
> mapped 1:1 on homed homes, thus if you use those things work as
On Di, 08.10.24 11:42, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > Oh, that hasn't been the case for a long time anymore. Nowadays files
> > on disk are owned by the "nobody" user always, and idmapped mounts are
> >
the login.defs or
overflow UID stuff really should be avoided, and good documentation
helps for that.
I'd also be happy to update the UID/GID table on aforementioned
systemd documentation and delegate some range explicitly to IPA (or
IPA-like usecases) there, but for that I'd need some committment
On Di, 08.10.24 12:23, Stephen Gallagher (sgall...@redhat.com) wrote:
> On Tue, Oct 8, 2024 at 12:19 PM Lennart Poettering
> wrote:
> >
> > On Di, 08.10.24 18:07, Fedora Development ML
> > (devel@lists.fedoraproject.org) wrote:
> >
> > > Am 08.10
k-like behaviour, that you can
basically say "allow logins from any @google.com" account or similar,
and we'd generate a home dir from that automatically, as you log
in. But quite frankly, we have more pressing issues in systemd-homed
land right now. It's a bigger project, would re
On Di, 08.10.24 18:07, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Am 08.10.24 um 17:32 schrieb Lennart Poettering:
> > For example, I am fundamentally opposed to the model
> > these systems generally pursue of turning UID numbers into centrally,
> > orga
d in selinux is kinda small to non-existing.
Anyway, if all people want is to stick another "relabel" this call
after we create a new homedir, i am fine with that, but this would be
not be a full fix in my eyes.
Lennart
--
Lennart Poettering, Berlin
--
on my setup with many read-only snapshots in
> ~/, permissions changes wouldn't be permitted, even by the root
> user.
Not sure I grok what you are trying to say here?
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@
requires an fs that supports fscrypt), at
mid-level security (because fscrypt protectes file contents, not
metadata, unlike the LUKS/dm-crypt backend which protects everything.)
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@li
benefit from its use (see parallel
> discussion by Neal). I also see it as a sole contributor to SELinux AVCs
> in OpenQA tests we run for FreeIPA use cases.
That seems like a bug in the SELinux policy really.
Lennart
--
Lennart Poettering, Berlin
--
_
does, and
then take benefit of systemd-logind resource logic too.
So far there's was literal interest in that though.
But yeah, would be great if sssd/ipa world would integrate with
systemd-logind/systemd-userdbd and all that stuff more tightly, but
that should be on equal footing
ere is very
> little benefit to doing any integration work for homed if we can't
> universally reap the benefits of it.
Well, that's a bit like saying we shouldn't adopt mysql because it is
a shit web browser, no? I mean, it's true, mysql *is* a shit web
br
d that's entirely fine.
glibc NSS defines a somewhat OK'ish abstraction over homed and sssd so
that most apps don#t really have to care where a user comes from, from
the network (i.e. sssd) or from a locally managed thing (i.e. homed).
Lennart
--
Lennart Poettering, Berlin
--
_
and not try to abstract each
other.
Hence: if you have some user in ldap/ipa, and another in homed, that's
entirely fine, they should not affect each other.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedo
they throw at you then. It's an
instance of the rule to be lenient in what you accept, and strict with
what you generate i guess.
Hence, in systemd's tree, we do the O_PATH thing only for connect(),
we do not actually bother with any of that for the binding of
sockets.
Lennart
--
lobal property of a process, hence will affect all
threads. Hence, maybe do this in a short-lived forked off process.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to d
untime. Writing to /usr/ should be off limits for anything
that isn't really a package manager (and maybe very few other
exceptions).
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe s
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes)
and adjust it to your framework of choice, coding style and so
on. i.e. adjust the error handling, logging to your choice.]
Use this when:
- Your project is not in C or
- You really don't want an
rstanding of UNIX
APIs should be able to hack that up in a a few lines of code. It's a
protocol I can summarize and explain in *one* frickin' sentence.
sshd upstream understood this btw:
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
Lennart
--
Lennart Poetterin
he attacker could
have used various other vehicle libs for their goal, too. I mean, sshd
uses PAM, and that pull in variety of things through its modules, and
that's just very hard to properly review even when one just focusses
on the default PAM config on Fedora.
Lennart
--
Lennart Poettering, Ber
t it can be processed
by initrd generators, automatic dep generators in dpkg/rpm,
ldd-like tools and everything else that wants this info. This would
require some C macro magic, but could be added in probably just a
few lines of codes added t
On Fr, 02.02.24 10:10, Roberto Ragusa (m...@robertoragusa.it) wrote:
> On 1/31/24 09:41, Lennart Poettering wrote:
>
> > This tanks performance when writing to the device though. There's a
> > much better approach however: use an automount in between with a very
> > s
to work, but after 2s everything is forced out to disk
anyway and it is guaranteed the superblock of the disk is put back
into a clean state.
systemd supports this natively, for example with a simple
"systemd-mount -A /dev/sda1".
I wished the desktop UIs woul
On Mo, 11.12.23 11:10, DJ Delorie (d...@redhat.com) wrote:
> Lennart Poettering writes:
> > Well, as you might be aware many distributions these days do more than
> > "files dns" for "hosts", and similar for the other databases, and
> > hence a bui
On Fr, 08.12.23 20:20, DJ Delorie (d...@redhat.com) wrote:
> Lennart Poettering writes:
> > That said, I would certainly enjoy more if glibc would natively
> > fallback to /usr/lib/glibc/nsswitch.conf or something like that if
> > /etc/nsswitch.conf does not exist.
>
r/lib/glibc/nsswitch.conf or something like that if
/etc/nsswitch.conf does not exist.
Lennart
--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fed
c that allows
users to split things up doesn't leak into the contents of the files,
but remains in the structure of the file system.
That said, if you give me an "include" style logic in glibc's database
handling I'd also be happy. Beggars can't be choosers, after al
On Mo, 21.08.23 11:07, Lennart Poettering (mzerq...@0pointer.de) wrote:
> On Do, 17.08.23 08:25, Chris Adams (li...@cmadams.net) wrote:
>
> > Once upon a time, Lennart Poettering said:
> > > Yes, and if this is not what you want, then disable the
> > > rate
On Do, 17.08.23 08:25, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > Yes, and if this is not what you want, then disable the
> > ratelimit. That's what I am saying?
>
> It would be useful for systemd to have "cooldown pe
> ("sshd.socket: Trigger limit hit, refusing further activation.").
Yes, and if this is not what you want, then disable the
ratelimit. That's what I am saying?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@
ment what you are asking for is what
I proposed here:
https://github.com/util-linux/util-linux/issues/1969
And as it turns out Karel actually implemented this recently, see
https://github.com/util-linux/util-linux/commit/1592425a0a1472db3168cd9247f001d7c5dd84b6.
I think it would be a good
/man/systemd.socket.html#TriggerLimitIntervalSec=
I don't care too much whether you make ssh socket-activated by default
or not. But at least the option should exist, already for compat with
existing setups.
Lennart
--
Lennart Poettering, Berlin
___
need to send us patches
for this, if this matters to them. I don't think anyone in systemd
upstream wil work on this on their own.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an e
OTLDR partition is supposed to be the escape hatch if the
ESP is pre-existing and too small to contain multiple full sized
UKIs. But you could also make it an escape hatch for simplifying
transitions from the status quo ante.
Lennart
--
Lennart Poettering, Berlin
___
the same time,
and then create a symlink from /etc/services to it, including via
tmpfiles.d/, to at least push people away from assuming that this was
actually configurable config file, and not just a dump of some
outdated IANA data).
Lennart
--
Lennart Poettering, Berlin
__
and then see if for that count you actually manage to
reach the OS.
Hence, if you care about realibility, automatic fallback and such
things, you need a writable boot partition. And that doesn't leave
many options, but VFAT.
Lennart
--
Lennart Poettering, Berlin
___
On Mi, 10.05.23 17:54, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> On Wed, May 10, 2023, at 5:21 PM, Lennart Poettering wrote:
> > So to add to this. I happen to be at LFSMMBPF at the moment, the Linux
> > File System summit (among other things) where all the Linux
ainly
not *everything*.
You can stick your head in the sand and pretend that nothing of this
mattered, and you don't have to authenticate and things, but then you
simply didn't solve the problem at hand.
Lennart
--
Lennart Poettering, Berlin
__
you do it the other way round. Hence, unless you
established trust in your btrfs fs *before* you go into and and look
for kernel you are not doing security, you are just doing nonsense.
> I would rather have a multi-stage boot process, where the first stage
> does just enough to unlo
On Mi, 10.05.23 15:13, Lennart Poettering (mzerq...@0pointer.de) wrote:
> > We're generally looking toward encrypting subvolumes individually
> > using the upcoming Btrfs native encryption capability rather than
> > using LUKS. That allows us to
>
> How do you esta
nel. Pre-compiled UKIs
provided by Fedora should be comprehensive and suitable enough to be
rescue images, I don't see why we need a second version of that. The
only difference between a rescue boot and a regular boot should be one
of parameterization, not of picking different k
lex storage again.
You are arguing here into two opposing directions. One one hand you
want to chainload multiple kernels+initrd (claiming this was a good idea out
of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the
other hand you claim there's too much kernel+initrd in the b
ou want to boot from, and thus you'll also have alrge
images, and then what did you gain? You ave to put that in the ESP
too, and the size limits still apply. It's illusionary to believe that
the size constraints for a kernel + drivers + complex storage stack +
crypto stack + auth
On Di, 09.05.23 12:37, Neal Gompa (ngomp...@gmail.com) wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > I've been asked to consider converting /boot to
to reduce
the time where the partitions are mounted to a minimum, and autofs
makes that very simple and natural, as it means the file systems are
only mounted for a very short period of time when actually accessed,
and unmounted a seconds later.
Lennart
--
Lennart Poettering, Berlin
_
gt; nice to get rid of this anachronism if this area is being touched.)
I guess this might not be surprising, but this proposal makes a ton of
sense to me and has my full support, FWTW
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -
ver, and a FIDO2 EFI driver, and so on and so
on. Basically, you have to reimplement a good chunk of the Linux
kernel, of Linux userspace, systemd and so on in EFI mode.
Good luck with that.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -
On Fr, 20.01.23 14:04, Colin Walters (walt...@verbum.org) wrote:
>
>
> On Thu, Jan 19, 2023, at 11:53 AM, Gordon Messmer wrote:
> > On 2023-01-19 00:55, Lennart Poettering wrote:
> >>
> >> What you could do is split up the problem: have iscsi-starter.service
>
On Do, 19.01.23 08:53, Gordon Messmer (gordon.mess...@gmail.com) wrote:
> On 2023-01-19 00:55, Lennart Poettering wrote:
> >
> > What you could do is split up the problem: have iscsi-starter.service
> > or so, that is separate from the iscsi.service main service. The
> &g
ly like this btw:
[Unit]
DefaultDependencies=no
Before=sysinit.target iscsi.service
RequiresMountsFor=/var/lib/iscsi/nodes
ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/systemctl start --no-block
ink a policy of "aggressive time-out by
default, individual opt-outs per-service" is a better policy for a
stable OS than the current "conservative time-out by default,
individual opt-in per-service for something more aggressive".
So yes, lowering the time-outs
m the kernel, and the kernel
typically speaks netlink, not AF_UNIX. But quite frankly, I really
don't care what transport would be used. I'd just be happy if we could
get rid of the kernel forking its own stuff.
Lennart
--
Lennart Poettering, Berlin
ting is also the stuff that is expensive to dump.
Hence, I am not sure you'll gain that much via this mechanism: you cut
a long operation short and then execute long operation as result. You
might end delaying things more than you hope shortening them.
Lennart
--
Lennart Poettering, Berlin
On Fr, 06.01.23 10:10, Steve Grubb (sgr...@redhat.com) wrote:
> Hello,
>
> On Friday, January 6, 2023 9:33:12 AM EST Lennart Poettering wrote:
> > On Do, 05.01.23 20:17, Steve Grubb (sgr...@redhat.com) wrote:
> > > I work on RHEL security problems. I have been
itself. The init system could then hook into that and
dispatch things in proper services with sandboxing, resource controls
and everything applied, in a sensible cgroup.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproj
nything about this. To fix a situation
one needs actionable reports.
> No one helped anyway, even back when I could provide more information.
> They're even less likely now that I can't provide that information.
You do realise that you are are complaining but not giving anyone the
c
rom the write patterns Windows 9x did
on its file systems.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
http
will
be built-in. But once you enroll other certs things should be fine.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Condu
k for a bug report?
Please be specific, otherwise noone will be able to help you!
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code o
On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote:
> On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering
> wrote:
> >
> > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > > I understand the big issue you have is that the cert
roll hashes? Were was this
dicussed?
Without any of that the vagueness just constitutes FUD... Hence,
please be more specific!
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email t
> You *need* to think about these problems when designing this stuff.
> You can't take a myopic x86-only view to this. I have not heard of
> anything about UKI security for non-x86 because it seems to all be
> tied up in UEFI stuff.
I work for a company that is working on ARM UE
nd bad things happen.
ukify hence calculates the offsets manually (by adding up the section
sizes so that this cannot happen.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an emai
so not charged against NVRAM but are built into fedora shim. And
the shim signature key is the msft key.
Yeah, if you want to build your own UKIs + sysext, then you have to
use mokutil to enroll a cert, but it would be entirely sufficient to
enroll one for that, a
same keyring as kmods basically. Hence there's
nothing really new here when it comes to key management.
If you have beef with how Linux manages the keys for authenticating
kmods then bring that up with the kernel community, it has nothing to
do with the way UKIs/sysext works.
Lennart
--
Lenn
t; provide something useful to the Linux world here and I would be
> extremely apprehensive about Fedora adopting any portion of this
> stuff.
Umpfh. This is FUD. Please read up before writing scathing comments
like that.
Lennart
--
Lennart Poettering, Berlin
___
.
> We can only really have one boot manager, especially with how broken
> multiple ESPs on a system are.
Why would you have multiple ESPs? I don't follow?
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproj
hat writes to the ESP/VFAT are actually OK, then I
think it's just a minor step to say that /boot/ as VFAT is also OK
given these writes are more seldom, are done from the safer OS
environment, and can be tightly controlled.
Lennart
--
Lennart Poettering, Berlin
_
s
impossible to ever get lost, pile up or so.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproj
his own machines, but not every
Fedora system comes with a Neal Gompa deployment included.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fe
linearly in full, then syncing, and then
renaming it to the final name (and syncing again) you should get
equal/better guarantees from the fs, in a way actually compatible with
the pre-boot env.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing
driver might need to allocate a
bunch of separate long file name dir entries, which might then span
multiple sectors)
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@li
ESP to the
level this could be possible. Sure, it's still no journalling, but
it's as close as it can get.
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@li
so much by the OS.
What do you think a boot laoder is going to do with access modes, file
ownership, selinux labels?
I am pretty sure we should reduce problems and simplify things by just
using VFAT for boot loader stuff, and put everything at the least
number of places possible.
Lennart
--
L
4 for upgrades, but outside of
that, for new installs it's something that really should be avoided I
am sure.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
.
Anyway, if you want to know more about choice of the fs for /boot/,
see my ideas here:
https://0pointer.net/blog/linux-boot-partitions.html
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubsc
secure as your DHCP leases
are protected, but the security is definitely not going to be worse
than in the status quo ante that way)
(you could also build/sign your own UKIs with the network boot info
baked in. Or you could use TPM-bound systemd "credentials" to prov
1 - 100 of 1714 matches
Mail list logo
