On Fri, Dec 23, 2022 at 08:13:49AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Quoting Daniel Berrange from the other part of the thread:
> > This is the same situation we already have in Fedora with
> > libguestfs, where we're building a disk image inside Koji bundling
> > various binaries.
FWIW
On Thu, Jan 05, 2023 at 12:56:31AM -0800, Luya Tshimbalanga wrote:
> An issue with the testing method from the proposal: secure boot prevents the
> resulting unsigned unified kernel to boot.
It is signed, but with the test key.
You can get the x509 ca cert for that using:
certutil -L -d
An issue with the testing method from the proposal: secure boot prevents
the resulting unsigned unified kernel to boot. It will be great to
obtain a scratch-build from koji for users running with enabled secured
boot. My laptop currently uses systemd-boot as default following this
Hi,
> > While being at it: anaconda seems to explicitly call dracut to
> > generate
> > the initrd (according to the messages it prints). What is the reason
> > for this? Shouldn't this already happen as part of the rpm
> > transaction,
> > when the kernel install scripts are running?
> IIRC
On Mon, Jan 2, 2023 at 4:40 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Jan 02, 2023 at 05:59:07PM +0100, mkol...@redhat.com wrote:
> > On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote:
> > > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> > > > Hi all,
> > > >
> > > >
On Monday, 02 January 2023 at 17:25, Gerd Hoffmann wrote:
> On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
> > [...]
> > > Note that uefi http boot can also work with iso images, i.e. you can
> > >
On Mon, Jan 02, 2023 at 05:59:07PM +0100, mkol...@redhat.com wrote:
> On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote:
> > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> > > Hi all,
> > >
> > > > == Benefit to Fedora ==
> > > > * Better secure boot support (specifically
On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote:
> On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> > Hi all,
> >
> > > == Benefit to Fedora ==
> > > * Better secure boot support (specifically the initrd is covered
> > > by
> > > the signature).
> > > * Better confidential
On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
> [...]
> > Note that uefi http boot can also work with iso images, i.e. you can
> > have the dhcp server hand out URLs to the fedora netboot iso. The
> >
On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote:
[...]
> Note that uefi http boot can also work with iso images, i.e. you can
> have the dhcp server hand out URLs to the fedora netboot iso. The
> firmware will fetch the iso, create a ramdisk, add a acpi table for
> it so the OS finds it
On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote:
> Hi all,
>
> > == Benefit to Fedora ==
> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
> > * Better confidential computing support (measurements are much more
> > useful if we know what
On Fri, Dec 23, 2022 at 09:01:52AM +0100, Vitaly Zaitsev via devel wrote:
> I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode
> and vice versa.
Needs installing the signing keys to the shim key database using
mokutil, but should otherwise work just fine.
take care,
Hi,
> A much better approach is to install a TPM-generated key in the TPM’s
> NVRAM, with a policy that only allows the key to be used once a trusted
> operating system has booted. That can be used as a trust anchor even
> without support from buggy UEFI firmware.
Side note: measuring kernel
Lennart Poettering wrote:
> dracut uses fixed offsets for the sections to be placed in memory
> in. The values are simply hardcoded, literally specified address
> offsets, that worked for the original authors. This typically works –
> as long as your sections are not much larger than they were for
> On 12/22/22 15:39, Lennart Poettering wrote:
>
>
>
> Well, the thing with a chain of trust is the fact that the only chain
> the user can trust is the one that he himself or the host device he owns
> and operates generated that trust of chain, from link 0 in that chain. (
> And we all know
On 12/22/22 15:39, Lennart Poettering wrote:
Well, the thing is: a chain of trust is a*chain*, hence you must
ultimately hook validation to what the firmware provides you with as
root. And that ultimately is the SecureBoot db on commodity hardware.
Well, the thing with a chain of trust is
On Do, 22.12.22 11:00, Neal Gompa (ngomp...@gmail.com) wrote:
> > OK, so what's left is exactly one issue you had: you tried to enroll 3
> > UEFI certs via mokutil and what exactly happened then? machine
> > bricked how precisely?
>
> The UEFI environment failed to import without reporting
On Fr, 23.12.22 08:51, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 22/12/2022 21:29, Chris Murphy wrote:
> > This is a rare but real problem.
>
> I don't think so. Power outage is a very common problem in some countries.
>
> I still remember how unreliable FAT32 was in the
On Fr, 23.12.22 09:01, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 22/12/2022 21:18, Chris Murphy wrote:
> > XBOOTLDR in practice needs to be FAT. I don't like it. But I like
> > it better than choosing batshit as the alternative, and having a
> > bunch of signed efifs
> On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote:
> Different architectures have different boot loaders. In particular, s390x and
> ppc64el are very different. The proposal is to add support for UKIs in grub2,
> so
> that we will cover UEFI and non-UEFI machines that use grub2.
> On 22/12/2022 21:29, Chris Murphy wrote:
>
> I don't think so. Power outage is a very common problem in some countries.
>
> I still remember how unreliable FAT32 was in the Windows 9x era. You
> needed to run a scandisk check after every power failure or pressing the
> reset button. And
> On 12/22/22 12:00, Luca Boccassi wrote:
>
> As Neal mentioned earlier, these mechanisms are often broken. Not only
> does some firmware wind up bricking the machine when they are used, they
> also may not support removing the key used to sign Windows. If the
> attacker can boot Windows and
On 12/20/22 21:27, Simo Sorce wrote:
Finally, unless this proposal harms Fedora I do not see why oppose it.
If, as you fear, it won't work ... then it won't and we'll try
something else.
You do realize that the day that Lenovo started to sell it's hardware
with Fedora pre-installed ( as it
On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote:
> On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > In my case, I have Network Manager config files included in my initrd
> >
On 22/12/2022 21:18, Chris Murphy wrote:
XBOOTLDR in practice needs to be FAT. I don't like it. But I like it better
than choosing batshit as the alternative, and having a bunch of signed efifs
drivers on the ESP per distro sounds like batshit to me. And not in the good
way.
I don't think
On 22/12/2022 21:29, Chris Murphy wrote:
This is a rare but real problem.
I don't think so. Power outage is a very common problem in some countries.
I still remember how unreliable FAT32 was in the Windows 9x era. You
needed to run a scandisk check after every power failure or pressing the
On 12/22/22 12:00, Luca Boccassi wrote:
>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>> >
>> Basically, I'm saying that the model of trust is flawed because users
>> are unable to work with it.
>>
>> And besides, each level up is a smaller scope from the previous. A
>> cert trusted by
On 12/22/22 12:33, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi wrote:
>>
>>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>>> >>
>>> Basically, I'm saying that the model of trust is flawed because users
>>> are unable to work with it.
>>>
>>> And besides, each level
On Wed, Dec 21, 2022, at 12:00 PM, Lennart Poettering wrote:
> On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>> For the general case we need some other option. Could be just stick to
>> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
>> and ppc64le).
On Wed, Dec 21, 2022, at 6:53 AM, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
>> Why shouldn't FAT be used for /boot. In an EFI world, /boot
>> is used for the same functional pupose as the ESP, which is
>> already going to use FAT.
>
> Doesn't support
On Wed, Dec 21, 2022, at 6:22 AM, Vitaly Zaitsev via devel wrote:
> On 20/12/2022 19:56, Chris Murphy wrote:
>> Great. The gotcha though is this in effect requires a change in the file
>> system currently mounted at /boot, which is ext4. And ext4 isn't supported
>> by sd-boot or UEFI firmware.
On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> >
> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi
> Your concept only works in *some* enterprise hardware where it's even
> possible to have full control without breaking something. Even in my
> server gear, I can't do that without breaking the network firmware. If
> I can't safely distrust
On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi wrote:
>
> > On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
> > >
> > Basically, I'm saying that the model of trust is flawed because users
> > are unable to work with it.
> >
> > And besides, each level up is a smaller scope from the previous.
On Thu, Dec 22, 2022 at 02:49:37PM +, Daniel P. Berrangé wrote:
> > There are at three ways that are used: 'dracut --uefi', systemd's ukify,
> > and a
> > manual objcopy invocation. The first two are wrappers around objcopy. I'm
> > biased
> > because I wrote 'ukify', but I think that's the
On Thu, Dec 22, 2022 at 10:52:05AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering
> wrote:
> >
> > BTW, you keep talking of "these" problems, and are extremely vague
> > about those. I think I understood that you hit the NVRAM size limits
> > before, by enrolling
> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>
> Basically, I'm saying that the model of trust is flawed because users
> are unable to work with it.
>
> And besides, each level up is a smaller scope from the previous. A
> cert trusted by shim can execute anything the firmware trusts, a
On Thu, Dec 22, 2022 at 04:24:11PM +0100, Lennart Poettering wrote:
> On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > When you say it dooesn't get the offsets right, can you elaborate ?
>
> dracut uses fixed offsets for the sections to be placed in memory
> in. The
On Thu, Dec 22, 2022 at 10:56 AM Lennart Poettering
wrote:
>
> On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote:
> 65;6800;1c
> > > BTW, you keep talking of "these" problems, and are extremely vague
> > > about those. I think I understood that you hit the NVRAM size limits
> > >
On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
wrote:
>
> 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
On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote:
65;6800;1c
> > BTW, you keep talking of "these" problems, and are extremely vague
> > about those. I think I understood that you hit the NVRAM size limits
> > before, by enrolling private certs?
>
> Yes. Specifically for dealing with
Hi all,
Dne 20. 12. 22 v 16:22 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will
On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering
wrote:
>
> On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > I have to think about what happens when the cat is out of the bag.
> > What I want is not necessarily a solution to this now, but a
> > commitment that someone will
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 certificate store for
> > > > Linux (i.e.
On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote:
> I have to think about what happens when the cat is out of the bag.
> What I want is not necessarily a solution to this now, but a
> commitment that someone will actively work on fixing these problems
> *before* proposing the next
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 certificate store for
> > > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > > NVRAM is
On Thu, Dec 22, 2022 at 10:35 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > Hmm, the updated Change is mostly okay. I disagree that you have any
> > real security benefits since all the Secure Boot stuff in Linux is
> > still in a bad place.
>
> It's a step into the right direction, but I agree, it
On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote:
> > I understand the big issue you have is that the certificate store for
> > Linux (i.e. the mokutil db) is limited in size because EFI variable
> > NVRAM is limited in size? If that's the big issue you are having then
> > that's
Hi,
> Hmm, the updated Change is mostly okay. I disagree that you have any
> real security benefits since all the Secure Boot stuff in Linux is
> still in a bad place.
It's a step into the right direction, but I agree, it alone doesn't
improve the situation much. I think we need to overthink
On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote:
> When you say it dooesn't get the offsets right, can you elaborate ?
dracut uses fixed offsets for the sections to be placed in memory
in. The values are simply hardcoded, literally specified address
offsets, that worked for
On Thu, Dec 22, 2022 at 10:58:11AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> > Gerd Hoffmann wrote:
> > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > > And if you chose your HW carefully you may even be able
On Thu, Dec 22, 2022 at 7:32 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > > If something is proposed for bare metal in the future, then raise
> > > the problems at that point. It is unreasonable to demand that we
> > > fix problems for a use case that is not in scope for what is being
> > > proposed.
Hi,
> > If something is proposed for bare metal in the future, then raise
> > the problems at that point. It is unreasonable to demand that we
> > fix problems for a use case that is not in scope for what is being
> > proposed. Anything related to bare metal was explicitly out of
> > scope,
On Thu, Dec 22, 2022 at 7:07 AM Daniel P. Berrangé wrote:
>
> On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote:
> > On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > > In my case, I
On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé
> wrote:
> >
> > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > > In my case, I have Network Manager config files included in my initrd
> > > and
Hi,
> > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
> > the way Linux/shim/mokutil implement the cert db is done the way it is
> > currently done.
Well, UEFI *not* defining some standard way to enroll user certificates
actually is part of the problem. It is one of
On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> > decryption
On Thu, Dec 22, 2022 at 06:38:56AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé
> wrote:
> >
> > On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> > > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering
> > > wrote:
> > > >
> > > > On Di, 20.12.22
On Wed, Dec 21, 2022 at 08:39:25PM +0100, Iñaki Ucar wrote:
> From the point of view of the workstation experience (with a laptop),
> I see no discussion on how this may impact hibernation. Currently, I
> have secure boot disabled essentially because I want my laptop to
> automatically hibernate
On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> In my case, I have Network Manager config files included in my initrd
> and bootargs to bring up the network so that I get automatic disk
> decryption while on my home network, and prompted for a password when
> I am not
On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé wrote:
>
> On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering
> > wrote:
> > >
> > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > > SecureBoot may
On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote:
> On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering
> wrote:
> >
> > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > > SecureBoot may not be to your liking but is what is installed on 99% of
> > > > modern
On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> In my case, I have Network Manager config files included in my initrd
> and bootargs to bring up the network so that I get automatic disk
> decryption while on my home network, and prompted for a password when
> I am not
On Thu, Dec 22, 2022 at 5:58 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> > Gerd Hoffmann wrote:
> > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > > And if you chose your HW carefully you may even be able to
On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote:
> Gerd Hoffmann wrote:
> > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > > And if you chose your HW carefully you may even be able to register
> > > your own public keys, generate and sign your own built UKIs and re-
On Wed, Dec 21, 2022 at 6:13 PM Demi Marie Obenour
wrote:
>
[...]
>
> Does vfat support atomic rename? Is it possible to atomically upgrade
> a bootloader/UKI/etc?
> --
For Linux, renameat2 RENAME_EXCHANGE is supported in vfat since
version v6.0. The relevant commits FYI are:
On Wed, Dec 21, 2022 at 05:44:36PM +0100, Lennart Poettering wrote:
>
> I mean, sure, if you use the Fedora supplied vanilla signed UKI
> without anything else then it won't boot from a network, because that
> would be a security hole. But I see no reason why a network boot UKI
> couldn't be
On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering wrote:
>
> On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > SecureBoot may not be to your liking but is what is installed on 99% of
> > > modern hardware sold, so it is a good idea to first show you can
> > > support it. Then
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
From the point of view of the workstation experience (with a laptop),
I see no discussion on how this may impact hibernation. Currently, I
have secure boot disabled essentially because I want my laptop to
automatically hibernate (and recover from that state) whenever it is
suspended for a number
On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > SecureBoot may not be to your liking but is what is installed on 99% of
> > modern hardware sold, so it is a good idea to first show you can
> > support it. Then if you have interested you can propose "something
> > better".
>
> We
On Di, 20.12.22 21:32, Neal Gompa (ngomp...@gmail.com) wrote:
> As someone whose day job involves working with teams who develop both
> Windows and Linux drivers (and in the past, even macOS drivers!), I
> can categorically say that Windows driver engineering processes are
> way friendlier than
On Di, 20.12.22 11:28, Neal Gompa (ngomp...@gmail.com) wrote:
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact with real users enough to
> understand how much of a problem they actually are.
I presume this is supposed to be a comment
In my case, I have Network Manager config files included in my initrd
and bootargs to bring up the network so that I get automatic disk
decryption while on my home network, and prompted for a password when
I am not at home. I think this a reasonable enough use case it should
be considered in the
On Mi, 21.12.22 12:38, Neal Gompa (ngomp...@gmail.com) wrote:
> > sd-boot implements boot counting by stashing the counter inside the
> > UKI (or bootspec type #1 conf file) file name, so that the counter is
> > impossible to ever get lost, pile up or so.
>
> Because the ESP is intended to be
Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > And if you chose your HW carefully you may even be able to register
> > your own public keys, generate and sign your own built UKIs and re-
> > enable SecureBoot after that... your choice!
>
> And when your
Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > > Switching the whole distro over to unified kernels quickly is not
> > > realistic though. Too many features are depending on the current
> > > workflow with a host-specific initrd (and host-specific kernel
On Mi, 21.12.22 12:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > And similar for server/embedded stuff. If fedora wants to be deployed
> > in such worlds, it's kinda nice if we can automatically recover from
> > hosed updates.
>
> None of those things require us to write data to /boot. Even in
On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really
On Wed, Dec 21, 2022 at 12:33 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > And journaling actually is more a problem than a solution due to
> > > firmware (or grub) filesystem drivers often not having full support for
> > > the journal.
On Wed, Dec 21, 2022 at 12:29 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > > > is used for the same functional pupose as the ESP, which is
> > > > > already going to
On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice because /boot
> > is rarely
On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
> > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > > is used for the same functional pupose as the ESP, which is
> > > > already going to use FAT.
> > >
> > > Doesn't support links, lournaling and ACLs.
> >
> >
On Wed, Dec 21, 2022 at 12:15 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
> > On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > is used for the same
On 12/21/22 12:17, Lennart Poettering wrote:
> On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
>
>>> At least for the systemd stuff, we carefully made sure that our access
>>> patterns to the ESP both from sd-boot/sd-stub and from userspace are
>>> by default as minimal
On Mi, 21.12.22 14:00, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice
On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
> > At least for the systemd stuff, we carefully made sure that our access
> > patterns to the ESP both from sd-boot/sd-stub and from userspace are
> > by default as minimal and robust as we can make them, to minimize
> >
On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
>
On 12/21/22 12:00, Lennart Poettering wrote:
> On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>> For the general case we need some other option. Could be just stick to
>> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
>> and ppc64le). Or drop an ext4
On 12/20/22 16:34, Simo Sorce wrote:
> On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote:
>> How do you plan to handle system recovery? For VMs this is much
>> less of a concern, but on bare metal there needs to be a way for
>> a local, authenticated administrator to obtain a root shell
On Mi, 21.12.22 06:27, Neal Gompa (ngomp...@gmail.com) wrote:
> On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 20/12/2022 19:56, Chris Murphy wrote:
> > > Great. The gotcha though is this in effect requires a change in the file
> > > system currently mounted at
On Mi, 21.12.22 12:22, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 20/12/2022 19:56, Chris Murphy wrote: > Great. The gotcha though
> is this in effect requires a change in the file system currently
> mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot
> or
On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
> For the general case we need some other option. Could be just stick to
> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
> and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
> for
On Mi, 21.12.22 10:16, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
On Di, 20.12.22 13:56, Chris Murphy (li...@colorremedies.com) wrote:
> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
>
> We need to solve the glaring hole that is the initrd. There's no
> question about it. I can't really assess if this feature is the
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
On Di, 20.12.22 20:42, Björn Persson (Bjorn@rombobjörn.se) wrote:
> The root filesystem is also relevant for troubleshooting, when I take a
> storage device out of a broken computer and connect it to another
> computer to inspect it. Suddenly there are two "discoverable" root
> partitions, and
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> Without an initrd we immediately have the following limitations:
> - all kernel modules needed to mount root must be compiled in
> - all that code is always loaded and remains in unswappable memory
> - root= syntax is limited to what the
On Tue, Dec 20, 2022 at 07:22:34PM +, Daniel P. Berrangé wrote:
> On Tue, Dec 20, 2022 at 01:56:57PM -0500, Chris Murphy wrote:
> > Or if we could do enough strict standardization in
> > the boot chain with a possibly larger kernel to avoid
> > needing an initrd, i.e. get to sysroot mount
1 - 100 of 157 matches
Mail list logo
