On Thu, Oct 31, 2019, at 12:26 PM, Lennart Poettering wrote:
> Well, what I proposed is a file. OSTree can cover files on disk, no?
Yes...we can try to figure out an extension to version them.
> I doubt on AWS you want to configure keymaps though, do you?
No, but there are similar server case
On Di, 01.10.19 15:33, Colin Walters (walt...@verbum.org) wrote:
> On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote:
>
> > i.e maybe write down a spec, that declares how to store settings
> > shared between host OS, boot loader and early-boot kernel environment
> > on systems that have n
On Mo, 07.10.19 10:32, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> Colin Walters wrote on 01/10/2019 20:33:
> > On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote:
> >
> >> i.e maybe write down a spec, that declares how to store settings
> >> shared between host OS, boot loader and early
On Mo, 30.09.19 16:07, Hans de Goede (hdego...@redhat.com) wrote:
> > So what you are arguing for is replacing the overlay initramfs
> > with a key-value config file which gets used by both the bootloader
> > and the OS.
> >
> > That is an interesting concept, esp. since it limits (as you advocate
On Mo, 30.09.19 13:23, Hans de Goede (hdego...@redhat.com) wrote:
> > i.e. generating initrd images with cpio and so on is hacky, gluey,
> > Linux-specific. If you just use plain simple, standardized config
> > files at clearly defined locations, then reading and writing them is
> > simple, they c
Colin Walters wrote on 01/10/2019 20:33:
> On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote:
>
>> i.e maybe write down a spec, that declares how to store settings
>> shared between host OS, boot loader and early-boot kernel environment
>> on systems that have no EFI NVRAM, and then we ca
On Sun, Sep 29, 2019, at 6:08 AM, Lennart Poettering wrote:
> i.e maybe write down a spec, that declares how to store settings
> shared between host OS, boot loader and early-boot kernel environment
> on systems that have no EFI NVRAM, and then we can make use of
> that. i.e. come up with semantic
Hi,
On 30-09-2019 13:23, Hans de Goede wrote:
Hi,
On 29-09-2019 12:08, Lennart Poettering wrote:
On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote:
Anyway, even if you insist that the Fedora desktop should care about
non-EFI, which I can accept, isn't the lesson to learn to
Hi,
On 29-09-2019 12:08, Lennart Poettering wrote:
On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote:
Anyway, even if you insist that the Fedora desktop should care about
non-EFI, which I can accept, isn't the lesson to learn to add some
concept like EFI vars to those archs t
Am 29.09.19 um 12:08 schrieb Lennart Poettering:
> Who are you designing this for anyway? I mean, isn't Fedora dropping
> i386 support even these days, so that in particular the Fedora
> *desktop* becomes an x86-64 only thing (and thus an EFI-only thing)
seriously?
what has x86_64 only to do wi
On Fr, 27.09.19 16:16, Hans de Goede (hdego...@redhat.com) wrote:
>
>
> > Secondly, the boot loader specification (the original one, not the
> > weird templating/macro language fedora grub adopted) allows multiple
> > initrds to be specified, with any path you like (as long as it's
> > relative t
On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote:
> Well until we make sure nothing ever writes outside of the user
> homedir security conscious users will likely still want to use
I am pretty sure the security conscious users should not run an OS
that writes user stuff all over t
Hi,
On 9/27/19 1:59 PM, Lennart Poettering wrote:
On Fr, 27.09.19 10:20, Hans de Goede (hdego...@redhat.com) wrote:
"So my plan for regular Fedora for this is as follows:
1. Have a /boot/initramfs-config.img which for now will just contain
/etc/vconsole.conf (chances are this will get more
Hi,
On 9/27/19 1:49 PM, Lennart Poettering wrote:
On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote:
Hi all,
Currently, at least in Fedora, but I do not believe that this problem is
unique to Fedora, there are 2 problems with keymap handling in the
initrd.
Hmm, why do you nee
пт, 27 сент. 2019 г. в 16:50, Lennart Poettering :
>
> 1. full disk encryption with the user typing in the password on the
>kbd. But isn't the answer to this to link the root OS to the tpm
>instead, and use user-keyed crypto only for $HOME? The OS itself
>doesn't need to be protected a
Am 27.09.19 um 14:33 schrieb Lennart Poettering:
> I mean, this sounds like needless complexity, no? As long as you can
> still access your $HOME the OS shouldn't need to be saved. I mean,
> that's the idea of Atomic OS that it is immutable, and everywhere
> identical and thus can be downloaded a
On Fri, Sep 27, 2019 at 3:18 PM Alberto Ruiz wrote:
>
>
> On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering
> wrote:
>
>> On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote:
>>
>> > Hi all,
>> >
>> > Currently, at least in Fedora, but I do not believe that this problem is
>> > un
On Fr, 27.09.19 13:17, Alberto Ruiz (ar...@redhat.com) wrote:
> > Hmm, why do you need a correct initrd in the early boot? I can see two
> > reasons:
> >
> > 1. full disk encryption with the user typing in the password on the
> >kbd. But isn't the answer to this to link the root OS to the tpm
On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering
wrote:
> On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote:
>
> > Hi all,
> >
> > Currently, at least in Fedora, but I do not believe that this problem is
> > unique to Fedora, there are 2 problems with keymap handling in the
> >
Am 27.09.19 um 13:49 schrieb Lennart Poettering:
> 1. full disk encryption with the user typing in the password on the
>kbd. But isn't the answer to this to link the root OS to the tpm
>instead, and use user-keyed crypto only for $HOME? The OS itself
>doesn't need to be protected afte
On Fr, 27.09.19 10:20, Hans de Goede (hdego...@redhat.com) wrote:
> Hi,
>
> On 26-09-2019 14:13, Alberto Ruiz wrote:
> > Hello Hans,
> >
> > Thanks for starting this discussion.
> >
> > Looking at this from a Fedora/Dracut POV, I think we should look at this as
> > the start of implementing a con
On Mi, 25.09.19 16:50, Hans de Goede (hdego...@redhat.com) wrote:
> Hi all,
>
> Currently, at least in Fedora, but I do not believe that this problem is
> unique to Fedora, there are 2 problems with keymap handling in the
> initrd.
Hmm, why do you need a correct initrd in the early boot? I can se
Hello Hans,
On 9/27/19 10:20 AM, Hans de Goede wrote:
> Hi,
>
> On 26-09-2019 14:13, Alberto Ruiz wrote:
>> Hello Hans,
>>
>> Thanks for starting this discussion.
>>
>> Looking at this from a Fedora/Dracut POV, I think we should look at this as
>> the start of implementing a configuration-only i
Hi,
On 26-09-2019 14:13, Alberto Ruiz wrote:
Hello Hans,
Thanks for starting this discussion.
Looking at this from a Fedora/Dracut POV, I think we should look at this as the
start of implementing a configuration-only initramfs, (something Matthew Garret
has been advocating for a while) rathe
Hello Hans,
Thanks for starting this discussion.
Looking at this from a Fedora/Dracut POV, I think we should look at this as
the start of implementing a configuration-only initramfs, (something
Matthew Garret has been advocating for a while) rather than making this a
vconsole.conf/plymouth specif
Hi,
On 26-09-2019 11:53, Michael Chapman wrote:
On Thu, 26 Sep 2019, Hans de Goede wrote:
Hi,
On 26-09-2019 11:10, Michael Chapman wrote:
On Thu, 26 Sep 2019, Hans de Goede wrote:
[...]
I believe that the best alternative is to have localed append / update
a rd.vconsole.keymap=foo argument t
On Thu, 26 Sep 2019, Hans de Goede wrote:
> Hi,
>
> On 26-09-2019 11:10, Michael Chapman wrote:
> > On Thu, 26 Sep 2019, Hans de Goede wrote:
> > [...]
> >> I believe that the best alternative is to have localed append / update
> >> a rd.vconsole.keymap=foo argument to the kernel commandline, to o
Hi,
On 26-09-2019 11:10, Michael Chapman wrote:
On Thu, 26 Sep 2019, Hans de Goede wrote:
[...]
I believe that the best alternative is to have localed append / update
a rd.vconsole.keymap=foo argument to the kernel commandline, to override
the vconsole.conf KEYMAP setting, but only in the initr
On Thu, 26 Sep 2019, Hans de Goede wrote:
[...]
> I believe that the best alternative is to have localed append / update
> a rd.vconsole.keymap=foo argument to the kernel commandline, to override
> the vconsole.conf KEYMAP setting, but only in the initrd (so that later
> runtime changes when booted
Hello Hans,
On 9/25/19 4:50 PM, Hans de Goede wrote:
> Hi all,
>
> Currently, at least in Fedora, but I do not believe that this problem is
> unique to Fedora, there are 2 problems with keymap handling in the initrd.
>
> 1: If the keymap in vconsole.conf is changed then this does not apply to th
Hi all,
Currently, at least in Fedora, but I do not believe that this problem is
unique to Fedora, there are 2 problems with keymap handling in the initrd.
1: If the keymap in vconsole.conf is changed then this does not apply to the
initrd without rebuilding it. This means that any changes are o
31 matches
Mail list logo
