On 06/30/2018 10:11 AM, Lennart Poettering wrote:
> On Fr, 29.06.18 17:26, Kyle Marek (pspps...@gmail.com) wrote:
>
>> Kernel updates are different. You *have* to reboot in order to run the
>> new kernel (except for security updates applied with kpatch) and a
>> broken kernel has the potential to
On Fr, 29.06.18 17:26, Kyle Marek (pspps...@gmail.com) wrote:
> Kernel updates are different. You *have* to reboot in order to run the
> new kernel (except for security updates applied with kpatch) and a
> broken kernel has the potential to simply lock up without even launching
> /sbin/init, for
On Fri, Jun 29, 2018 at 05:26:37PM -0400, Kyle Marek wrote:
> Kernel updates are different. You *have* to reboot in order to run the
> new kernel (except for security updates applied with kpatch) and a
> broken kernel has the potential to simply lock up without even launching
> /sbin/init, for
On 06/29/2018 04:33 PM, Lars Seipel wrote:
> On Mon, Jun 25, 2018 at 03:17:53PM -0400, Kyle Marek wrote:
>> On 06/25/2018 02:49 PM, Lennart Poettering wrote:
>>> But it's useful for unattended systems in general, be it servers or
>>> appliances: if a boot fails there generally should be a way to
On Mon, Jun 25, 2018 at 03:17:53PM -0400, Kyle Marek wrote:
> On 06/25/2018 02:49 PM, Lennart Poettering wrote:
> > But it's useful for unattended systems in general, be it servers or
> > appliances: if a boot fails there generally should be a way to recover
> > the system through rebooting
On Thu, Jun 28, 2018 at 3:34 AM, Dennis Gilmore wrote:
> El jue, 14-06-2018 a las 12:06 +0200, Jan Kurik escribió:
>> = Proposed System Wide Change: Make BootLoaderSpec the default =
>> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
[snip]
>> Fedora already has a lot of
El jue, 14-06-2018 a las 12:06 +0200, Jan Kurik escribió:
> = Proposed System Wide Change: Make BootLoaderSpec the default =
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
>
>
> Owner(s):
> * Javier Martinez Canillas
> * Peter Jones
>
>
> Use BootLoaderSpec fragment
On Tue, Jun 26, 2018 at 10:38 PM, Javier Martinez Canillas
wrote:
> On Tue, Jun 26, 2018 at 5:36 PM, Javier Martinez Canillas
> wrote:
>> On Tue, Jun 26, 2018 at 4:33 PM, Peter Jones wrote:
>
> [snip]
>
>>>
It attempts to sort using the id field, and if this isn't defined
other fields
On Tue, Jun 26, 2018 at 1:47 PM, Lennart Poettering
wrote:
> The logic I am working on is built as an add-on to the boot loader
> spec: I simply encode the counter in the file name of the snippet, so
> that counting down and marking an entry as good is a simple rename
> operation, which has a
On Tue, Jun 26, 2018 at 5:36 PM, Javier Martinez Canillas
wrote:
> On Tue, Jun 26, 2018 at 4:33 PM, Peter Jones wrote:
[snip]
>>
>>> It attempts to sort using the id field, and if this isn't defined
>>> other fields are used as fallback in the following order: version,
>>> title, linux.
>>
>>
On Di, 26.06.18 10:33, Peter Jones (pjo...@redhat.com) wrote:
> On Tue, Jun 26, 2018 at 03:46:59PM +0200, Javier Martinez Canillas wrote:
> > > That raises two questions:
> > > 1. Why isn't just the bls-snippet filename used as the key? It's
> > >necessarily unique and should be usable for
On Di, 26.06.18 12:51, Chris Murphy (li...@colorremedies.com) wrote:
> I'm making it about systemd-boot because it is literally the only
> bootloader that can't read any file system that the firmware can't
> already read; it's a UEFI only bootloader and it definitely sounds
> like the spec is
On Tue, Jun 26, 2018 at 1:33 PM, Peter Jones wrote:
>> > There's a lot of clouds going to uEFI now
>>
>> [citation needed]
> ...
>> I got sort of lost in Azure versus Hyper-V and gen1/gen2 - apparently
>> Hyper-V likes
>> UEFI and supports secure boot but Azure may not or something?
>
> Ignoring
> > There's a lot of clouds going to uEFI now
>
> [citation needed]
...
> I got sort of lost in Azure versus Hyper-V and gen1/gen2 - apparently Hyper-V
> likes
> UEFI and supports secure boot but Azure may not or something?
Ignoring the question of how many is a lot, I think you may just be
On Tue, Jun 26, 2018, at 11:48 AM, Peter Robinson wrote:
> There's a lot of clouds going to uEFI now
[citation needed]
In my brief google searches:
AWS: https://forums.aws.amazon.com/thread.jspa?threadID=155626
GCE: https://groups.google.com/forum/#!topic/gce-discussion/OD_Zd_6YVbw
DO:
On Mon, Jun 25, 2018 at 11:22 AM, Kyle Marek wrote:
>
> /boot is already ext on Fedora. Why does anyone *need* to implement XFS
> for GRUB?
The use case is an XFS root filesystem, and /boot is just a directory.
There is no separate boot volume.
ext4 is default for a volume mounted at /boot;
On Mon, Jun 25, 2018 at 10:09 AM, Andrew Lutomirski wrote:
> (d) It is useful to write to $BOOT from the bootloader to indicate
> that we're trying to boot and again from the booted system to indicate
> that the boot succeeded.
> (g) The bootloader's driver for $BOOT should implement at least
On Mon, Jun 25, 2018 at 4:40 AM, Lennart Poettering
wrote:
> I am not sure why you are making this about systemd-boot. Let's just
> focus on why (or why not) vfat is the best option for $BOOT.
I'm making it about systemd-boot because it is literally the only
bootloader that can't read any file
>> > And in my opinion, it's not simple to say: OK if you have this size
>> > ESP to start, you get this layout, and if it's bigger you get this
>> > other layout, and if it's BIOS you have this 3rd layout.
>
> Chris, I have to say I'm glad you're part of the Fedora community - your
> input on
On Tue, Jun 26, 2018 at 4:33 PM, Peter Jones wrote:
> On Tue, Jun 26, 2018 at 03:46:59PM +0200, Javier Martinez Canillas wrote:
>> > That raises two questions:
>> > 1. Why isn't just the bls-snippet filename used as the key? It's
>> >necessarily unique and should be usable for the purpose of
On Tue, Jun 26, 2018 at 03:46:59PM +0200, Javier Martinez Canillas wrote:
> > That raises two questions:
> > 1. Why isn't just the bls-snippet filename used as the key? It's
> >necessarily unique and should be usable for the purpose of uniquely
> >identifying the boot entry without
On Mon, Jun 25, 2018 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jun 18, 2018 at 04:40:41PM +0200, Ondřej Lysoněk wrote:
>> On 14.6.2018 12:06, Jan Kurik wrote:
>> I noticed the official spec defines a field named "machine-id". AFAICS,
>> GRUB2 doesn't implement that option, but it
Hi,
> (f) The scheme should function without UEFI. There are plenty of
> non-UEFI systems out there. This means that the bootloader might need
> to live in a BIOS boot partition, or in flash, or in ROM, or in other
> strange places.
> Now let's think this through. You're proposing that
On 06/25/2018 02:49 PM, Lennart Poettering wrote:
> On Mo, 25.06.18 13:22, Kyle Marek (pspps...@gmail.com) wrote:
>
>>> So think about this one bit ahead. Right now it's clear that even with
>>> Grub's relatively large contributor base it'shard to impossible to
>>> support modern Linux file
On Mo, 25.06.18 13:22, Kyle Marek (pspps...@gmail.com) wrote:
> > So think about this one bit ahead. Right now it's clear that even with
> > Grub's relatively large contributor base it'shard to impossible to
> > support modern Linux file systems properly — even just for
> > read-only. See the the
On Mo, 25.06.18 09:09, Andrew Lutomirski (l...@mit.edu) wrote:
> Now let's think this through. You're proposing that $BOOT be the
> ESP.
Yes, I think that's wise, but the boot loader spec allows $BOOT to be
separate from the ESP, so I am not sure why you are warming this up
again.
You can
On 06/25/2018 06:40 AM, Lennart Poettering wrote:
> On Fr, 22.06.18 14:17, Chris Murphy (li...@colorremedies.com) wrote:
>
>> On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering
>> wrote:
>>> On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
>>>
> Whereas
On Mon, Jun 18, 2018 at 04:40:41PM +0200, Ondřej Lysoněk wrote:
> On 14.6.2018 12:06, Jan Kurik wrote:
> I noticed the official spec defines a field named "machine-id". AFAICS,
> GRUB2 doesn't implement that option, but it supports a field named "id".
> Are these used for the same thing? If they
> On Jun 25, 2018, at 3:40 AM, Lennart Poettering wrote:
>
>> On Fr, 22.06.18 14:17, Chris Murphy (li...@colorremedies.com) wrote:
>>
>> On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering
>> wrote:
>>> On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
>>>
>
> On Jun 25, 2018, at 3:54 AM, Daniel P. Berrangé wrote:
>
>> On Mon, Jun 25, 2018 at 12:47:35PM +0200, Lennart Poettering wrote:
>>> On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
>>>
>>> That would break applications like libguestfs which run as non-root and
>>> have
On Mon, Jun 25, 2018 at 01:48:12PM +0200, Gerd Hoffmann wrote:
> On Mon, Jun 25, 2018 at 12:14:36PM +0200, Lennart Poettering wrote:
> > On Fr, 22.06.18 13:35, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > $BOOT being non-vfat is a fairly substantial departure from either
> > >
On Tue, Jun 19, 2018 at 11:42:33AM +0200, Lennart Poettering wrote:
> On Mo, 18.06.18 16:50, Ondřej Lysoněk (olyso...@redhat.com) wrote:
>
> > Hi,
> >
> > On 18.6.2018 15:27, Lennart Poettering wrote:
> > > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> > >
> > >> The
On Mo, 25.06.18 13:46, Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > > > Which file system do you have in mind even for this?
> > >
> > > Unspecified for now. i.e. no change. It would remain ext4 by default I
> > > expect, but ultimately whatever anaconda allows.
>
> IMHO the only
On Mon, Jun 25, 2018 at 12:14:36PM +0200, Lennart Poettering wrote:
> On Fr, 22.06.18 13:35, Chris Murphy (li...@colorremedies.com) wrote:
>
> > $BOOT being non-vfat is a fairly substantial departure from either
> > BootLoaderSpec, the original requires $BOOT be vfat, the mjg59 version
> >
Hi,
> > > Which file system do you have in mind even for this?
> >
> > Unspecified for now. i.e. no change. It would remain ext4 by default I
> > expect, but ultimately whatever anaconda allows.
IMHO the only thing which is reasonable here would be something simple
with posix semantics, which
On Mon, Jun 25, 2018 at 12:57:28PM +0200, Lennart Poettering wrote:
> On Mo, 25.06.18 11:54, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > On Mon, Jun 25, 2018 at 12:47:35PM +0200, Lennart Poettering wrote:
> > > On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
> > >
On Mo, 25.06.18 11:54, Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Jun 25, 2018 at 12:47:35PM +0200, Lennart Poettering wrote:
> > On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
> >
> > > That would break applications like libguestfs which run as non-root
On Mon, Jun 25, 2018 at 12:47:35PM +0200, Lennart Poettering wrote:
> On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > That would break applications like libguestfs which run as non-root and
> > have valid need to access /boot/vmlinuz*
>
> Hmm, can you elaborate on
On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
> That would break applications like libguestfs which run as non-root and
> have valid need to access /boot/vmlinuz*
Hmm, can you elaborate on that? What precisely do they need there?
If it's just the kernel image itself
On Fr, 22.06.18 14:26, Chris Murphy (li...@colorremedies.com) wrote:
> On Fri, Jun 22, 2018 at 1:30 PM, Kyle Marek wrote:
>
> > Anaconda in F28 currently claims /boot cannot be vfat. However, this appears
> > to be an artificial limitation, because `grub2-install` works and makes a
> > bootable
On Fr, 22.06.18 14:17, Chris Murphy (li...@colorremedies.com) wrote:
> On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering
> wrote:
> > On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
> >
> >> > Whereas constantly changing the ESP, means we need some way to
> >> >
On Mon, Jun 25, 2018 at 06:04:54AM -0400, Simo Sorce wrote:
> On Fri, 2018-06-22 at 16:30 -0500, Chris Adams wrote:
> > Once upon a time, Kyle Marek said:
> > > On 06/22/2018 05:15 PM, Chris Adams wrote:
> > > > And basic Unix permissions... because there can be privileged
> > > > content in
> >
On Fr, 22.06.18 15:54, Kyle Marek (pspps...@gmail.com) wrote:
> What is the benefit to sharing $BOOT between different operating
> systems/distros?
>
> I'd like to point out that $BOOT doesn't have to be shared to dual-boot
> multiple distros or benefit from other details of BLS.
But it's an
On Fr, 22.06.18 13:35, Chris Murphy (li...@colorremedies.com) wrote:
> $BOOT being non-vfat is a fairly substantial departure from either
> BootLoaderSpec, the original requires $BOOT be vfat, the mjg59 version
> require $BOOT be firmware readable. That is not a complaint, I'm just
> making an
On Fri, 2018-06-22 at 16:30 -0500, Chris Adams wrote:
> Once upon a time, Kyle Marek said:
> > On 06/22/2018 05:15 PM, Chris Adams wrote:
> > > And basic Unix permissions... because there can be privileged
> > > content in
> > > GRUB config and even initramfs.
> >
> > That's interesting. I
Once upon a time, Kyle Marek said:
> On 06/22/2018 05:15 PM, Chris Adams wrote:
> > And basic Unix permissions... because there can be privileged content in
> > GRUB config and even initramfs.
>
> That's interesting. I generally don't see /boot as something that normal
> users shouldn't be able
On 06/22/2018 05:15 PM, Chris Adams wrote:
> Once upon a time, Matthew Miller said:
>> On Fri, Jun 22, 2018 at 03:30:23PM -0400, Kyle Marek wrote:
>>> Anaconda in F28 currently claims /boot cannot be vfat. However, this
>>> appears to be an artificial limitation, because `grub2-install` works
>>>
Once upon a time, Matthew Miller said:
> On Fri, Jun 22, 2018 at 03:30:23PM -0400, Kyle Marek wrote:
> > Anaconda in F28 currently claims /boot cannot be vfat. However, this
> > appears to be an artificial limitation, because `grub2-install` works
> > and makes a bootable GRUB with a vfat-typed
On Fri, Jun 22, 2018 at 1:54 PM, Kyle Marek wrote:
> On 06/22/2018 03:35 PM, Chris Murphy wrote:
>
> What is the benefit to sharing $BOOT between different operating
> systems/distros?
Some of this is argued in the two BootLoaderSpecs. Mainly to avoid
stomping on each other's installations and
On Fri, Jun 22, 2018 at 1:30 PM, Kyle Marek wrote:
> Anaconda in F28 currently claims /boot cannot be vfat. However, this appears
> to be an artificial limitation, because `grub2-install` works and makes a
> bootable GRUB with a vfat-typed --boot-directory.
> I'm not sure why there would be an
On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering
wrote:
> On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
>
>> > Whereas constantly changing the ESP, means we need some way to
>> > establish a master and rsync to the extras.
>>
>> So the consensus seems to be to
On 06/22/2018 03:35 PM, Chris Murphy wrote:
> On Fri, Jun 22, 2018 at 11:01 AM, Javier Martinez Canillas
> wrote:
>> On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy
>> wrote:
>>
>> [snip]
>>
> OK anyway, I don't see broad BLS consensus forming yet, but I do see
> two items that aren't
On Fri, Jun 22, 2018 at 03:30:23PM -0400, Kyle Marek wrote:
> Anaconda in F28 currently claims /boot cannot be vfat. However, this
> appears to be an artificial limitation, because `grub2-install` works
> and makes a bootable GRUB with a vfat-typed --boot-directory.
> I'm not sure why there would
On Fri, Jun 22, 2018 at 11:01 AM, Javier Martinez Canillas
wrote:
> On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy
> wrote:
>
> [snip]
>
>>>
OK anyway, I don't see broad BLS consensus forming yet, but I do see
two items that aren't controversial and could move forward as part of
On 06/22/2018 02:57 PM, Lennart Poettering wrote:
> On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
>
>>> Whereas constantly changing the ESP, means we need some way to
>>> establish a master and rsync to the extras.
>> So the consensus seems to be to have the BLS
On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
> > Whereas constantly changing the ESP, means we need some way to
> > establish a master and rsync to the extras.
>
> So the consensus seems to be to have the BLS fragments in
> $BOOT/loader/entries even on EFI, where
On Mon, Jun 18, 2018 at 02:42:40PM -0700, Andrew Lutomirski wrote:
> > On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas
> > wrote:
> >
> >> On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy
> >> wrote:
> >> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson
> >> wrote a monolithic config
>
On Mon, Jun 18, 2018 at 11:55:28PM +0100, Tom Hughes wrote:
> On 18/06/18 23:46, Javier Martinez Canillas wrote:
> > On Mon, Jun 18, 2018 at 11:54 PM, Tom Hughes wrote:
> > > On 18/06/18 18:15, Peter Jones wrote:
> > >
> > > > That's true - though we actually shipped nearly all of the code to
>
On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy wrote:
[snip]
>>
>>> OK anyway, I don't see broad BLS consensus forming yet, but I do see
>>> two items that aren't controversial and could move forward as part of
>>> this feature proposal:
>>>
>>> a. Consistent $BOOT/loader/entries for UEFI and
On Thu, Jun 21, 2018 at 8:53 PM, Kyle Marek wrote:
> I've noticed that Windows 10 does MBR installs on BIOS, as well. I've
> always found that interesting because I have also found several laptops
> (I think most of them were HP) where the OEM installed a BIOS bootloader
> in addition to the EFI
On 06/21/2018 10:28 PM, Chris Murphy wrote:
> On Thu, Jun 21, 2018 at 3:59 PM, Kyle Marek wrote:
>
>> If it helps, I've only ever used GRUB on GPT when installing to BIOS
>> systems. I haven't encountered *any* issues so far.
> It was always model specific. Maybe 1/2 dozen models were affected.
>
On Thu, Jun 21, 2018 at 3:59 PM, Kyle Marek wrote:
> If it helps, I've only ever used GRUB on GPT when installing to BIOS
> systems. I haven't encountered *any* issues so far.
It was always model specific. Maybe 1/2 dozen models were affected.
https://bugzilla.redhat.com/show_bug.cgi?id=755226
On 06/21/2018 05:19 PM, Chris Murphy wrote:
> On Thu, Jun 21, 2018 at 2:28 PM, Kyle Marek wrote:
>> On 06/21/2018 03:07 PM, Chris Murphy wrote:
>>> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek wrote:
>>>
I would greatly appreciate a move to a uniform GPT+EF02+EF00
partitioning default
On Thu, Jun 21, 2018 at 2:28 PM, Kyle Marek wrote:
> On 06/21/2018 03:07 PM, Chris Murphy wrote:
>> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek wrote:
>>
>>> I would greatly appreciate a move to a uniform GPT+EF02+EF00
>>> partitioning default with a shared boot loader config.
>> An ESP on BIOS
On 06/21/2018 03:07 PM, Chris Murphy wrote:
> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek wrote:
>
>> I would greatly appreciate a move to a uniform GPT+EF02+EF00
>> partitioning default with a shared boot loader config.
> An ESP on BIOS is perhaps weird when making so much of this booting
> and
On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek wrote:
> I would greatly appreciate a move to a uniform GPT+EF02+EF00
> partitioning default with a shared boot loader config.
An ESP on BIOS is perhaps weird when making so much of this booting
and startup stuff user facing; but it's actually
On 06/21/2018 09:41 AM, Gerd Hoffmann wrote:
> Hi,
>
>> From my perspective (Fedora CoreOS developer) that straddles
>> both physical and cloud for the server case, the problem is that
>> the virtualized case, and in particular public cloud, and really
>> specifically EC2 - no one really cares
On Thu, Jun 21, 2018 at 10:04:03AM -0400, Colin Walters wrote:
>
>
> On Thu, Jun 21, 2018, at 9:41 AM, Gerd Hoffmann wrote:
> >
> > Well, as *additional* variant it doesn't provide that much value. More
> > interesting would be to create all x86 cloud images that way, so they
> > boot just fine
On Thu, Jun 21, 2018, at 9:41 AM, Gerd Hoffmann wrote:
>
> Well, as *additional* variant it doesn't provide that much value. More
> interesting would be to create all x86 cloud images that way, so they
> boot just fine on both bios and efi, and we don't have to bother
> creating two image
Hi,
> From my perspective (Fedora CoreOS developer) that straddles
> both physical and cloud for the server case, the problem is that
> the virtualized case, and in particular public cloud, and really
> specifically EC2 - no one really cares about EFI to boot their VMs.
Indeed. And it sucks.
On Thu, Jun 21, 2018, at 3:30 AM, Gerd Hoffmann wrote:
> Hi,
>
> > And in my opinion, it's not simple to say: OK if you have this size
> > ESP to start, you get this layout, and if it's bigger you get this
> > other layout, and if it's BIOS you have this 3rd layout.
Chris, I have to say I'm
On Mi, 20.06.18 19:28, Chris Murphy (li...@colorremedies.com) wrote:
> >> Except, it's not simple for installers to migrate to a new bigger ESP
> >> in the dual boot case. And having different layouts for UEFI and BIOS
> >> and whether there's dual boot or single boot, isn't simpler.
> >
> >
On Mi, 20.06.18 19:40, Chris Murphy (li...@colorremedies.com) wrote:
> > What's going on? What is this? Why is this called "Boot loader spec"
> > if it implements an entirely different logic, and misses the entire
> > point of the boot loader spec?
> >
> > Quite frankly, I am really surprised by
Hi,
> Therefore, Option #2 will be extremely common. What percent of Fedora
> users dual boot? I have no empirical data. I'd guess 1/2.
Sure? I would expect in the age of virtualization people prefer
virtual machines, because you can run fedora and $someotheros at the
same time then.
The
Hi,
> And in my opinion, it's not simple to say: OK if you have this size
> ESP to start, you get this layout, and if it's bigger you get this
> other layout, and if it's BIOS you have this 3rd layout.
Well, for fresh installs[1] there is no reason to have efi and bios use
different layouts.
On Wed, Jun 20, 2018 at 8:46 AM, Lennart Poettering
wrote:
> On Do, 14.06.18 12:06, Jan Kurik (jku...@redhat.com) wrote:
>
>> The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
>> Boot Loader Specification (BLS)] defines a scheme and file format to
>
> So, it appears the
On Wed, Jun 20, 2018 at 8:35 AM, Lennart Poettering
wrote:
> On Di, 19.06.18 11:17, Chris Murphy (li...@colorremedies.com) wrote:
>
>> > Today, systemd has this generator that will automatically find the ESP
>> > for you and mount it to /efi or /boot. The idea behind that is that
>> > installers
On Do, 14.06.18 12:06, Jan Kurik (jku...@redhat.com) wrote:
> The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> Boot Loader Specification (BLS)] defines a scheme and file format to
So, it appears the suggested implementation of this uses
/EFI/fedora/loader/entries/ instead
On Di, 19.06.18 11:17, Chris Murphy (li...@colorremedies.com) wrote:
> > Today, systemd has this generator that will automatically find the ESP
> > for you and mount it to /efi or /boot. The idea behind that is that
> > installers can choose whether they want to merge $BOOT and the ESP or
> >
On Tue, Jun 19, 2018 at 3:40 AM, Lennart Poettering
wrote:
> The boot loader spec suggests that $BOOT and the ESP are the same
> thing, and I am very sure this is the best and simplest approach for
> all images that have no explicit reason to depart from that. However,
> the spec does not
On Mon, Jun 18, 2018 at 5:37 PM, Andrew Lutomirski wrote:
>> On Jun 18, 2018, at 3:54 PM, Chris Murphy wrote:
>> Getting journal support in the bootloader isn't going to happen. I've
>> already talked to the various fs upstreams about it.
>>
>
> Why are you talking to the fs upstreams? The
On Di, 19.06.18 11:14, Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Jun 19, 2018 at 11:48:39AM +0200, Lennart Poettering wrote:
> > On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
> >
> > > On Mon, 18 Jun 2018, Lennart Poettering wrote:
> > >
> > > > On Do,
On Tue, Jun 19, 2018 at 11:48:39AM +0200, Lennart Poettering wrote:
> On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
>
> > On Mon, 18 Jun 2018, Lennart Poettering wrote:
> >
> > > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> > >
> > > > The cited BLS
On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
> On Mon, 18 Jun 2018, Lennart Poettering wrote:
>
> > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > The cited BLS spec is the original one, [1]
>
> ... later: L.P.:
> > [reduce] the size of the
On Mo, 18.06.18 16:50, Ondřej Lysoněk (olyso...@redhat.com) wrote:
> Hi,
>
> On 18.6.2018 15:27, Lennart Poettering wrote:
> > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> The cited BLS spec is the original one, not the more thoroughly
> >> discussed and thought
On Mo, 18.06.18 10:30, Chris Murphy (li...@colorremedies.com) wrote:
> >> The cited BLS spec requires $BOOT be VFAT, are we doing that?
> >
> > Why would we? I mean the idea is that $BOOT can be shared among
> > multiple OSes installed. Which means one really should settle on a
> > format anyone
On 06/18/2018 07:37 PM, Andrew Lutomirski wrote:
>> On Jun 18, 2018, at 3:54 PM, Chris Murphy wrote:
>>
>> On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski wrote:
>>> As an extra plus, upgrading a kernel doesn’t require mounting the ESP,
>>> which means that the bootloader installation can
On Mon, Jun 18, 2018 at 3:54 PM, Tom Hughes wrote:
> On 18/06/18 18:15, Peter Jones wrote:
>
>> That's true - though we actually shipped nearly all of the code to
>> implement this stuff f28, minus some parts of the upgrade story and the
>> anaconda bits to enable it by default. You can go run
> On Jun 18, 2018, at 3:54 PM, Chris Murphy wrote:
>
> On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski wrote:
>>> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas
>>> wrote:
>
>>> Yes for EFI systems but no otherwise. On EFI the BLS snippets are in
>>>
On 18/06/18 23:46, Javier Martinez Canillas wrote:
On Mon, Jun 18, 2018 at 11:54 PM, Tom Hughes wrote:
On 18/06/18 18:15, Peter Jones wrote:
That's true - though we actually shipped nearly all of the code to
implement this stuff f28, minus some parts of the upgrade story and the
anaconda
On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski wrote:
>> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas
>> wrote:
>> Yes for EFI systems but no otherwise. On EFI the BLS snippets are in
>> /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in
>> /boot/loader/entries.
>>
On Mon, Jun 18, 2018 at 11:54 PM, Tom Hughes wrote:
> On 18/06/18 18:15, Peter Jones wrote:
>
>> That's true - though we actually shipped nearly all of the code to
>> implement this stuff f28, minus some parts of the upgrade story and the
>> anaconda bits to enable it by default. You can go run
On 18/06/18 18:15, Peter Jones wrote:
That's true - though we actually shipped nearly all of the code to
implement this stuff f28, minus some parts of the upgrade story and the
anaconda bits to enable it by default. You can go run
grub2-switch-to-blscfg today, and it will work. I hope :)
> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas
> wrote:
>
>> On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy
>> wrote:
>> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson
>> wrote a monolithic config
>
>
>> The cited BLS spec requires $BOOT be VFAT, are we doing that?
>>
>
> Yes
On Mon, 18 Jun 2018, Lennart Poettering wrote:
> On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
>
> > The cited BLS spec is the original one, [1]
... later: L.P.:
> [reduce] the size of the spec if possible, and drop as many
> bits of it as we can, i.e. the stuff noone
On Mon, Jun 18, 2018 at 12:14:31PM -0600, Chris Murphy wrote:
> Thanks for the reply.
>
> I think the proposal title is misleading. The BLS file format is,
> depending on one's point of view, 5% of the spec. A bulk of the
> proposal isn't going to follow the spec at all. And even with regards
>
On Mon, Jun 18, 2018 at 12:14 PM, Chris Murphy wrote:
> My summary of the change for most users (x86_64)
> - users will no longer modify /etc/default/grub, they will duplicate
> (?) and modify BLS scripts directly if they need to make permanent
> changes to menu entries
I assumed wrong. I'm
On Mon, Jun 18, 2018 at 11:02 AM, Javier Martinez Canillas
wrote:
> On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy
> wrote:
>> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson
>> wrote:
>>> On Thu, 2018-06-14 at 12:06 +0200, Jan Kurik wrote:
== Scope ==
* Proposal owners:
**
On 2018-06-18 12:39, Chris Murphy wrote:
kdump is
enabled by default on RHEL (and maybe CentOS, not sure).
I can confirm it is on CentOS.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Mon, Jun 18, 2018 at 03:29:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 18, 2018 at 11:17:50AM -0400, Peter Jones wrote:
> > On Thu, Jun 14, 2018 at 12:40:50PM -0700, Adam Williamson wrote:
> > > On Thu, 2018-06-14 at 15:10 -0400, Matthew Miller wrote:
> > > > On Thu, Jun 14,
1 - 100 of 115 matches
Mail list logo
