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 extra dep
Lennart
--
Lennart Poettering, Be
Is 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 Poettering, Berlin
--
_
ld
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, Berlin
--
__
cessed
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 to relevant proj
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
> >
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 would use this, or
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.
>
/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
Fedor
lit 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 all.
Lennart
--
Lennart Poettering, Berlin
--
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 peri
ot;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@lists.fedorapro
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 idea to build on that, i.
ervalSec=
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
___
devel mailing list -- devel@lists
end 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 email to devel-l
XBOOTLDR 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
___
mlink 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
___
devel mailing list
at 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
___
devel mailing
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
our 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
___
devel mailing list -- devel@lists.fedorap
nless 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 unlock and load the OS volume to load the re
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 establish
Is
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 kernel.
Lennart
--
Lenna
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 boot
process?
What is it
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 stack would not apply to kernel that just runs in
uefi mode instead of native mo
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 convert
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
_
o 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 -- devel@list
river, 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 -- devel@lists.fedoraproje
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
&
[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 --job-mode=fail isc
ressive 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 by default would make sen
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
__
e 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 be
t 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.fedoraproject.org
To u
out 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
chance to do anything
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:
https://docs.f
ther 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 Conduct:
https://docs.fedoraproject.org/en-U
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 of Con
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
re 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 to devel-le...@l
gning 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 UEFI systems booting UKIs
in massive scale.
Lennart
--
Lennart Po
ngs 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 email to devel
ure 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, and sign UKIS, kmods, sysext with them.
(or, maybe you actually hit the NVRAM si
ence 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
--
Lennart Poettering, Berlin
_
remely 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
___
devel mailing list -- devel@lists.fedoraproject.org
To uns
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.fedoraproject.org
To unsu
T 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
___
devel mailing l
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.fedoraproject.org/en-US/p
t 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
Fedora Code of Conduct:
ht
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 list --
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...
. 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...@lists.fedoraproject.org
Fedora Code of Conduct:
htt
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
--
Lennart Poettering, Berlin
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...@lists.fedoraproject.o
ou 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 unsubscribe send an em
re 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 provide
the ne
considered a pretty common
case sooner or later.
I think initrd-less systems only make sense as a corner case for
certain low-security systems, but certainly not as a default.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@list
arios
Nah. When booting without root= so that the root partition is
auto-discovered then this is done on the disk the ESP that was used
for booting is found on and no other disks. Thus: once you pick a disk
for booting in the firmware menu, auto-discovery won't "leave" this
di
o, if there's good case to be
made to tweak them in some way we can certainly consider making that
upstream.
(i.e. if you compiled a good list of pros/cons and have some specific
values to propose please submit a github issue upstream about this,
and we
g its
> multiboot problems by switching to systemd-boot. :)
Having one ESP on each individual medium is fine. The firmware will
boot into the ESP that is configured in the EFI boot variables, or if
none is configured into the one that is found on the boot medium that
is found first according to yo
off-label use stuff you just create problems for yourself that
decrease realiability.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraprojec
posed to have multiple ESPs on the same
medium. Firmware should use the first one only, and ignore the
other, but you know how firmware is, when it finds unexpected stuff...
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fed
g you could place in XBOOTLDR you can as well put in
the ESP *anyway* if space permits it, since sd-boot checks both
place. (The reverse is not true however, certain specific things can only be
placed on the ESP, and not in XBOOTLDR, most prominently any fs
drivers that ar
On Do, 28.07.22 10:25, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > Given the overlap of the Fedora/RH boot loader folks and the shim
> > folks, I think there's definitely an avenue to get systemd-boot signed
> > as payload for
ction of the grub codebase, but actually mostly code
from the grub codebase.
But anyway, I am actually advocating for sticking to VFAT
everywhere. ext4 drivers in the boot loader only are necessary for the
upgrade path.
Lennart
--
Lennart Poettering, Berlin
___
n be convinced of other boot loaders.
Given the overlap of the Fedora/RH boot loader folks and the shim
folks, I think there's definitely an avenue to get systemd-boot signed
as payload for SHIM, as alternative to Grub. If Fedora wants this, and
has the man power for it, it should b
that the spec is
about defining a *shared*, *common* resource, because that way they
made it inaccessible to everyone else. Or they did understand it, but
simply didn't care.
Whether sd-boot is used to read it, or grub doesn't really matter at
that point...
Lennart
--
Lennart Poettering, Berlin
_
On Mi, 27.07.22 17:15, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> On Wed, Jul 27, 2022, at 4:47 PM, Lennart Poettering wrote:
> > On Mi, 27.07.22 16:19, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> >> Boot Loader Spec defines $BOOT
On Mi, 27.07.22 17:01, Chris Murphy (li...@colorremedies.com) wrote:
65;6800;1c
>
>
> On Wed, Jul 27, 2022, at 4:30 PM, Lennart Poettering wrote:
>
> > So, let's say you want to make sd-boot be able to access a legacy ext4
> > /boot/ fs. First, fix the GPT partition type
side systemd-boot
4. sign the resulting systemd-bootx64.withext4.efi via shim/…
5. profitt! now you have an sd-boot binary that can do ext4. yay.
6. ask relevant other distros to do the same. They are probably in a
very similar situation as fedora is, given they typically all use
Grub rig
tionally these are not new
codepaths, but new payloads used in existing codepaths.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Cod
ch as ubuntu core, which currently
chainload sd-boot from grub, just to be able to get the realiable TPM
measurements we provide you with...).
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
ial, in 30% people would hate it, and in
30% people might not care...
That's why I don't really want to agree or disagree with the proposal,
it's not clear at all to me that what you are doing there is a good
idea across the board. It might be in the coreos case, if you say so,
but universally,
se UEFI will only give you access to the TPM
in a bytestream, not with high-level commands).
Hence, I am not convinved the benefit really outweighs the effort
here. Modifying your kernel command line is invasive, and hackish, and
hence I think it's OK to leave
on where to find the root fs in a credential,
encrypt/sign it with the key from the TPM, place the result int the
ESP. sd-stub then picks it up, passes it to the booted
kernel/initrd. The initrd then reads it, decrypts/authenticates it,
and then uses the info to mount the rootfs.
Lennart
-
On Di, 19.07.22 21:16, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Would pre-building the initrds mean all users have to use the same
> partition layout. If that happened, than many people dual boot
> setups will not work
No, it dos not mean that.
Lennart
-
fits: no shell, single process forked, no explicit selinux stuff,
or explicit mkdir, and other MACs will be honoured too if they exist.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
ng on making pre-built initrds for general
purpose distros a reality, i.e. finding a way between keeping things
reasonably modular but also pre-generated, immutable, pre-measurable,
and thus have a tight trust chain at boot. We'll do two talks about
that at Linux Plumbers Conference later this yea
R hashes, so that one can invalidate old kernels if needed, without
having to invalidate signatures as a whole)
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le..
quot; as it can get now, across distros. Still up to each distro
individually if they actually want to implement it though.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to dev
dates every few weeks.
Maybe our os-release docs should mention that this is the latest
*known* support date, and suggest that people refresh the OS to newest
set of relevant package to get newer info.
Lennart
--
Lennart Poettering, Berlin
__
ory itself, and then execute it from there, instead of invoking it
directly from the ESP file system. This matters because if sd-boot is
invoked from a synthetic file in memory we cannot derive the directory
tree of the ESP from it, and thus not find boot loader entries.
Lennart
--
Lennart Poett
t handled particularly nicely
originally. My proposal for addressing this is via documentation, i.e
update the udev and iproute docs to explicitly point to the issue and
how to deal with it, with an example drop-in to make it easy to deal
with it.
Lennart
--
Lennart Poettering, Berlin
__
ested in that at all.
>
> For initrd building or for cloud image building?
initrd building.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedora
What you are doing with the above is a hack that should require
highest privileges to do, and hence it's OK (not just OK, it's *good*)
to disable SecureBoot for that while you make them.
Lennart
--
Lennart Poettering, Berlin
___
devel mai
very new or very exotic hardware, then the
right fix is not to expect users to be technical enough to set a
kernel cmdline, but to fix the kernel to apply the fix automatically
where needed. The kernel has plenty infrastructure for that.
Lennart
--
Lennart Po
gt; you'll see it complain that there is no /bin/login: you just need to
> install util-linux (or possibly busybox) and you'll get a prompt,
> login should work as well.
This smells as a bug in in the package providing getty. getty cannot
work without /
safely after authentication, since we know it was
encoded by someone who had the permission to do so.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
way though once you have two entirely generic partitions and we
thus have no clue which it could be...
But why not just fix the cloud images to just use descriptive type
uuids? that has no drawbacks, just benefits.
Lennart
--
Lennart Poettering, Berlin
__
even in the most locked down mode.
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.fedoraproject.org/en-US/pro
t; a way for the user to use it.
You can enroll multiple certificates for validation, if you
like. i.e. if you want to sign your own modules, then enroll both the
fedora and your own cert. You could use shim for that if you like.
Or alternatively, turn off secureboot if you don't want to set up your
ce
for the initrd in a safe way.
My expectation would be that by default we'd just use the GPT auto
discovery stuff and for "pet" systems maybe also encode the root
device with a credntial, but for "cattle" systems not bother.
Lennart
--
Lennart Poettering, Berlin
_
tems should be
bootable with a single unified kernel images, and that of course
includes all popular virtualizers.
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to deve
On Mo, 04.07.22 04:19, Demi Marie Obenour (demioben...@gmail.com) wrote:
> On 7/4/22 04:13, Lennart Poettering wrote:
> > On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
> >
> >>> I do wonder if it's possible to use multiple initrds, and maybe have
>
a couple of extension
images next to the kernel image, and that's it.
(the extension images would be signed dm-verity squashfs, to ensure
everything is authenticated)
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproj
On Sa, 02.07.22 00:15, Marius Schwarz (fedora...@cloud-foo.de) wrote:
> Hi,
>
> I have some bug reports for PA opening BZ and only one ever got a response.
>
> Is it possible that this is the cause:
>
> You can't ask /Lennart Poettering / because that
> account is disabled
1 - 100 of 1732 matches
Mail list logo
