On Mar 20, 2014, at 1:39 PM, Adam Williamson wrote:
> Sigh, for the fourth time, I'm not suggesting it. It's not my idea. I'm
> not going to defend it. I'm relaying a design that was outlined to me by
> the anaconda devs. The motivation is that there have been multiple
> requests to make it poss
On Thu, 2014-03-20 at 20:20 +0100, Lennart Poettering wrote:
> On Wed, 19.03.14 18:51, Adam Williamson (awill...@redhat.com) wrote:
>
> > > More complex than trying to mirror a FAT ESP partition across multiple
> > > boot disks, keeping it properly synchronized, because RAID isn't
> > > supported?
On Wed, 19.03.14 18:51, Adam Williamson (awill...@redhat.com) wrote:
> > More complex than trying to mirror a FAT ESP partition across multiple
> > boot disks, keeping it properly synchronized, because RAID isn't
> > supported?
>
> You can in theory just have a bunch of RAID-1 (mirrored) ESPs, be
On Mar 20, 2014, at 10:32 AM, Przemek Klosowski
wrote:
> It is a darn useful side effect. How else can you implement redundant boot
> that is transparently updated?
For /boot, rather than /boot/efi, use metadata v1.2 and a bootloader that
understands v1.2 metadata. GRUB2 has for some time.
On Thu, 2014-03-20 at 10:07 -0700, Andrew Lutomirski wrote:
> On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson wrote:
> > On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:
> >
> >> Adam's scheme is the only possibility.
> >
> >> Adam's raid1 /boot just seems more
> >> reliable, especial
On Thu, Mar 20, 2014 at 10:07 AM, Andrew Lutomirski wrote:
> On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson wrote:
>> Sure, UEFI has the capability, but it's not going to be used when simply
>> booting the system normally. All the firmware does in that case is mount
>> the partition and execut
On Mar 20, 2014, at 10:56 AM, Adam Williamson wrote:
> On Wed, 2014-03-19 at 23:21 -0600, Chris Murphy wrote:
>
>> Therefore I don't think software RAID is a solution.
>
> Well, this is new: I'm fairly sure you were the one who filed a bug
> requesting it in the first damn place.
Where? I'm f
On Thu, Mar 20, 2014 at 10:01 AM, Adam Williamson wrote:
> On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:
>
>> Adam's scheme is the only possibility.
>
>> Adam's raid1 /boot just seems more
>> reliable, especially if it became a designed feature.
>
> It's not my plan, it's the anacond
On Thu, 2014-03-20 at 09:49 -0700, Andrew Lutomirski wrote:
> Um.
>
> EFI_FILE_PROTOCOL's Write method sounds suspiciously like it writes to
> a filesystem.
Sure, UEFI has the capability, but it's not going to be used when simply
booting the system normally. All the firmware does in that case is
On Wed, 2014-03-19 at 23:21 -0600, Chris Murphy wrote:
> Therefore I don't think software RAID is a solution.
Well, this is new: I'm fairly sure you were the one who filed a bug
requesting it in the first damn place.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedor
On Thu, 2014-03-20 at 12:32 -0400, Przemek Klosowski wrote:
> Adam's scheme is the only possibility.
> Adam's raid1 /boot just seems more
> reliable, especially if it became a designed feature.
It's not my plan, it's the anaconda developers'. I only described it.
Actually it took them like 15 m
On Thu, Mar 20, 2014 at 9:32 AM, Przemek Klosowski
wrote:
> On 03/20/2014 01:21 AM, Chris Murphy wrote:
>> You can in theory just have a bunch of RAID-1 (mirrored) ESPs, because
>> of how RAID-1 works; each individual member can also be mounted as if it
>> was just a plain old partition, which is
On 03/20/2014 01:21 AM, Chris Murphy wrote:
On Mar 19, 2014, at 7:51 PM, Adam Williamson wrote:
On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:
More complex than trying to mirror a FAT ESP partition across multiple
boot disks, keeping it properly synchronized, because RAID isn't
s
On Mar 19, 2014, at 7:51 PM, Adam Williamson wrote:
> On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:
>>
>> More complex than trying to mirror a FAT ESP partition across multiple
>> boot disks, keeping it properly synchronized, because RAID isn't
>> supported?
>
> You can in theory
On Mar 19, 2014, at 4:53 PM, Lennart Poettering wrote:
> On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote:
>
>> I agree, although I go farther. The EFI System partition doesn't
>> scale, isn't resilient, can neither be mirrored nor easily sync'd
>> (multidevice boot). It sho
On Wed, 2014-03-19 at 15:57 -0700, Andrew Lutomirski wrote:
> On Wed, Mar 19, 2014 at 3:53 PM, Lennart Poettering
> wrote:
> > On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> I agree, although I go farther. The EFI System partition doesn't
> >> scale, isn't resilient
On Wed, Mar 19, 2014 at 3:53 PM, Lennart Poettering
wrote:
> On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote:
>
>> I agree, although I go farther. The EFI System partition doesn't
>> scale, isn't resilient, can neither be mirrored nor easily sync'd
>> (multidevice boot). It sh
On Wed, 19.03.14 13:13, Chris Murphy (li...@colorremedies.com) wrote:
> I agree, although I go farther. The EFI System partition doesn't
> scale, isn't resilient, can neither be mirrored nor easily sync'd
> (multidevice boot). It should be considered a pre-boot and OS
> installer domain only.
You
I think dynamically mounted /boot is a separate conversation. It's only
relevant here in that if x-systemd.automount,noauto behavior is desired for
/boot, then for sure that means we need "a better way" for the EFI System
partition because we can't have nested automounts.
As for resources, the
On Mar 19, 2014, at 7:02 AM, Lennart Poettering wrote:
>
>
> It's one of the reasons why I really really dislike the invention of
> /boot/efi as the mount point for the ESP…
I agree, although I go farther. The EFI System partition doesn't scale, isn't
resilient, can neither be mirrored nor e
On Wed, Mar 19, 2014 at 03:01:27PM +1030, William Brown wrote:
> On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote:
>
> > >>> Fedora takes a different approach though, and will mount an explicit
> > >>> boot partition to /boot and the ESP to /boot/efi, and do so
> > >>> unconditionally without
2014-03-19 5:31 GMT+01:00 William Brown :
> On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote:> RFE: Do not
> persistently mount EFI System partition at /boot/efi
> > https://bugzilla.redhat.com/show_bug.cgi?id=1077984
> >
> > It's still better to remove the on-going writing of configuration f
On Wed, 19.03.14 15:01, William Brown (will...@firstyear.id.au) wrote:
> Why not also extend this to /boot also? It's "rarely" used in day to day
> on a system, really only for yum updates that include a kernel.
>
> [root@strawberry ~]# lsof | grep /boot
> [root@strawberry ~]#
To establish the
On Tue, 18.03.14 21:39, Chris Murphy (li...@colorremedies.com) wrote:
> > Combining x-systemd.automount + noauto however is a way to establish a
> > mount point and only lazily triggering it on access. And that's what you
> > want to use here.
>
> That does work. It's automounted on any command I
On Tue, 2014-03-18 at 20:52 -0700, Andrew Lutomirski wrote:
> Exactly. What needs it to automount and why?
Kernel updates.
> Isn't Chris's main
> point that Fedora shouldn't neet to mount the ESP in the first place?
In a perfect world, yes, but right now, the grub config file is on it.
If yo
On Mar 18, 2014, at 10:31 PM, William Brown wrote:
> On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote:
>
> Fedora takes a different approach though, and will mount an explicit
> boot partition to /boot and the ESP to /boot/efi, and do so
> unconditionally without involving auto
On Mar 18, 2014, at 6:27 PM, Andrew Lutomirski wrote:
> On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
> wrote:
>> On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
>>
Fedora takes a different approach though, and will mount an explicit
boot partition to /boo
On Tue, 2014-03-18 at 21:39 -0600, Chris Murphy wrote:
> >>> Fedora takes a different approach though, and will mount an explicit
> >>> boot partition to /boot and the ESP to /boot/efi, and do so
> >>> unconditionally without involving autofs. Fedora could add
> >>> "x-systemd-automount" to the m
On Tue, Mar 18, 2014 at 6:07 PM, Adam Williamson wrote:
> On Tue, 2014-03-18 at 17:27 -0700, Andrew Lutomirski wrote:
>> On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
>> wrote:
>> > On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
>> >
>> >> > Fedora takes a different a
On Mar 18, 2014, at 6:19 PM, Lennart Poettering wrote:
> On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
>
>>> Fedora takes a different approach though, and will mount an explicit
>>> boot partition to /boot and the ESP to /boot/efi, and do so
>>> unconditionally without i
On Tue, 2014-03-18 at 17:27 -0700, Andrew Lutomirski wrote:
> On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
> wrote:
> > On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> > Fedora takes a different approach though, and will mount an explicit
> >> > boot partition
On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
wrote:
> On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
>
>> > Fedora takes a different approach though, and will mount an explicit
>> > boot partition to /boot and the ESP to /boot/efi, and do so
>> > unconditionally witho
On Tue, 18.03.14 15:07, Chris Murphy (li...@colorremedies.com) wrote:
> > Fedora takes a different approach though, and will mount an explicit
> > boot partition to /boot and the ESP to /boot/efi, and do so
> > unconditionally without involving autofs. Fedora could add
> > "x-systemd-automount" t
On Mar 18, 2014, at 10:13 AM, Lennart Poettering wrote:
> On Mon, 17.03.14 23:02, Chris Murphy (li...@colorremedies.com) wrote:
>
>> 1. EFI System partition is being mounted persistently at /boot/efi,
>> and I'd like to put an end to that because there's no good reason to
>> do it. None of the
On Mon, 17.03.14 23:02, Chris Murphy (li...@colorremedies.com) wrote:
> 1. EFI System partition is being mounted persistently at /boot/efi,
> and I'd like to put an end to that because there's no good reason to
> do it. None of the binaries on it are regularly being updated, and if
> they are, the
On 18 March 2014 07:02, Chris Murphy wrote:
>
> 1. EFI System partition is being mounted persistently at /boot/efi, and
> I'd like to put an end to that because there's no good reason to do it.
> None of the binaries on it are regularly being updated, and if they are,
> the volume should be mou
Two feature requests, comments please.
1. EFI System partition is being mounted persistently at /boot/efi, and I'd
like to put an end to that because there's no good reason to do it. None of the
binaries on it are regularly being updated, and if they are, the volume should
be mounted on demand
37 matches
Mail list logo
