On Tuesday, July 14, 2020 12:39:01 AM MST Lennart Poettering wrote:
> > Why at boot time? Well if your default subvolume contains a recent
> > update that for some reason renders it unbootable, it might be nice to
> > be able to pick a prior snapshot. That's how they do this. It isn't
> > how we
On Tue, Jul 14, 2020 at 7:45 AM Lennart Poettering wrote:
>
> On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > > Why at boot time? Well if your default subvolume contains a recent
> > > > update that for some reason renders it unbootable, it might be nice to
> > > > be
On Tue, Jul 14, 2020 at 1:45 AM Lennart Poettering wrote:
>
> On Mo, 13.07.20 19:16, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > Yes, because you have to propagate it everywhere, and if you omit it
> > > things break, since it's a secondary place you store information about
> > > the
On Tue, Jul 14, 2020, at 3:44 AM, Lennart Poettering wrote:
> If however they share the same kernel/boot menu item between multiple
> versions of the OS tree, then I'd always embedd which version to boot
> in the fs itself by default,
Yep, that's how it works today - ostree only touches the
On Tue, Jul 14, 2020 at 2:45 PM Lennart Poettering wrote:
>
> On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > > Why at boot time? Well if your default subvolume contains a recent
> > > > update that for some reason renders it unbootable, it might be nice to
> > > > be
On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) wrote:
> > > Why at boot time? Well if your default subvolume contains a recent
> > > update that for some reason renders it unbootable, it might be nice to
> > > be able to pick a prior snapshot. That's how they do this. It isn't
> >
On Tue, Jul 14, 2020 at 1:39 AM Lennart Poettering wrote:
>
> On Mo, 13.07.20 19:07, Chris Murphy (li...@colorremedies.com) wrote:
>
> Yes, the kernel also supports an initrd-less mode, where it's the
> kernel itself that parses root=/rootflags=, but we don't use that in
> Fedora (and because
On Tue, Jul 14, 2020 at 5:31 AM Lennart Poettering wrote:
>
> On Di, 14.07.20 04:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > > Nah, this kind of selection you do in the initrd, not in the boot loader.
> >
> > Yes. SUSE does this at the bootloader time. A *huge* part of the code
> > they added
On Di, 14.07.20 04:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > Nah, this kind of selection you do in the initrd, not in the boot loader.
>
> Yes. SUSE does this at the bootloader time. A *huge* part of the code
> they added to GRUB is to automatically discover all this and populate
> the menu
On Tue, Jul 14, 2020 at 3:39 AM Lennart Poettering wrote:
>
> On Mo, 13.07.20 19:07, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
> > wrote:
> >
> > > Quite frankly, I don't see why the boot loader should care about the
> > > btrfs
On Mo, 13.07.20 19:16, Chris Murphy (li...@colorremedies.com) wrote:
> > Yes, because you have to propagate it everywhere, and if you omit it
> > things break, since it's a secondary place you store information about
> > the root disk in that you strictly need to have to be able to make
> > sense
On Mo, 13.07.20 19:07, Chris Murphy (li...@colorremedies.com) wrote:
> On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
> wrote:
>
> > Quite frankly, I don't see why the boot loader should care about the
> > btrfs subvolume the initrd later picks at all.
>
> As far as I'm aware, rootflags= is
On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
wrote:
>
> On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote:
>
> > Since it's mostly bootloader domain, and relates to a snapshot and
> > rollback paradigm as well, I think it's properly addressed in design
> > and planning
On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering
wrote:
> Quite frankly, I don't see why the boot loader should care about the
> btrfs subvolume the initrd later picks at all.
As far as I'm aware, rootflags= is a kernel boot parameter, and it
informs the kernel of mount options for the file
On Monday, July 13, 2020 11:13:50 AM MST Lennart Poettering wrote:
> On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> > I offer it to contradict the assertion that the current arrangement is
> > "pushing btrfsisms". It is originally Fedora. And having to use btrfs
> >
On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote:
> I offer it to contradict the assertion that the current arrangement is
> "pushing btrfsisms". It is originally Fedora. And having to use btrfs
> specific commands to set/get the default, as you propose, is the
> "btrfsism" -
On Monday, July 13, 2020 3:12:22 AM MST Lennart Poettering wrote:
> On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> > > There's really no need to complicate things by pushing btrfsisms into
> > > user-visible concepts needlessly.
> >
> >
> >
> > It's been this way in
On Mon, Jul 13, 2020 at 4:12 AM Lennart Poettering wrote:
>
> On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > There's really no need to complicate things by pushing btrfsisms into
> > > user-visible concepts needlessly.
> >
> > It's been this way in Fedora for a
On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote:
> > There's really no need to complicate things by pushing btrfsisms into
> > user-visible concepts needlessly.
>
> It's been this way in Fedora for a decade.
Well, that's an argument one could also use against btrfs. We are
On Fri, Jul 10, 2020 at 12:16 PM Lennart Poettering
wrote:
>
> On Fr, 10.07.20 09:34, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > That makes things a lot more robust, as btrfs will then just work like
> > > any other fs even if you insert the root subvol in between like
> > > anaconda
On Fr, 10.07.20 09:34, Chris Murphy (li...@colorremedies.com) wrote:
> > That makes things a lot more robust, as btrfs will then just work like
> > any other fs even if you insert the root subvol in between like
> > anaconda apparently does.
> >
> > I think there's big value in allowing short
:
> > > >
> > > > I haven't seen any mention of Silverblue in the Btrfs discussions.
> > Will Silverblue also switch to Btrfs if the change is approved?
> > > >
> > > > I've tested installing Silverblue 32 and Rawhide with the default
> >
On Fri, Jul 10, 2020, 6:07 AM Lennart Poettering
wrote:
> On Fr, 10.07.20 06:50, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek
> wrote:
> > >
> > > I haven't seen any mention of Silverblue in the Btrfs discussio
On Fr, 10.07.20 06:50, Neal Gompa (ngomp...@gmail.com) wrote:
> On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek wrote:
> >
> > I haven't seen any mention of Silverblue in the Btrfs discussions. Will
> > Silverblue also switch to Btrfs if the change is approved?
> >
On Fri, Jul 10, 2020 at 6:57 AM Marek Suchánek wrote:
>
> That's perfect, thanks.
>
> So for reference, the fix is to add an option to the kernel command line:
>
> rootflags=subvol=$(root_device.name)
>
Yes, essentially it's the label of the root subvolume.
--
真実はいつも一つ！/ Always, there's only
:
> On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek
> wrote:
> >
> > I haven't seen any mention of Silverblue in the Btrfs discussions. Will
> Silverblue also switch to Btrfs if the change is approved?
> >
> > I've tested installing Silverblue 32 and Rawhide with
On Fri, Jul 10, 2020 at 6:45 AM Marek Suchánek wrote:
>
> I haven't seen any mention of Silverblue in the Btrfs discussions. Will
> Silverblue also switch to Btrfs if the change is approved?
>
> I've tested installing Silverblue 32 and Rawhide with the default Btrfs
> part
I haven't seen any mention of Silverblue in the Btrfs discussions. Will
Silverblue also switch to Btrfs if the change is approved?
I've tested installing Silverblue 32 and Rawhide with the default Btrfs
partitioning suggested by Anaconda, and in both cases the system failed to
boot after
28 matches
Mail list logo
