Feature request: Boot default subvolume in BTRFS

[Thomas]

Hello,

this is the description of my feature request:
Grub is booting the default subvolume in BTRFS w/o any manual
modification in Grub configuration.

Current situation:
Booting a snapshot created with Snapper
 is not possible w/o
modifying the Grub entries.
This is related to the Snapper functionality that creates a ro snapshot
that must be booted and then creates another rw snapshot of the
currently booted ro snapshot. Then Grub configuration must be recreated
to reflect the newly created rw snapshot.

Available solution:
In OpenSuse Grub is always booting the default snapshot and hereby Grub
configuration must not be adjusted.
To my understanding OpenSuse uses a patched Grub.

Regards
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH RFC/RFT 0/3] Add grub loader support for RISC-V Linux

[Atish Patra]

On Mon, Apr 27, 2020 at 3:11 PM Ard Biesheuvel  wrote:
>
> On Mon, 27 Apr 2020 at 23:16, Heinrich Schuchardt  wrote:
> >
> > Am April 27, 2020 8:58:57 PM UTC schrieb Heinrich Schuchardt 
> > :
> > >Am April 27, 2020 8:52:43 PM UTC schrieb Ard Biesheuvel
> > >:
> > >>On Mon, 27 Apr 2020 at 22:47, Ard Biesheuvel  wrote:
> > >>>
> > >>> On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt
> > >> wrote:
> > >>> >
> > >>> > Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel
> > >>:
> > >>> > >On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt
> > >>
> > >>> > >wrote:
> > >>> > >>
> > >>> > >> On 4/27/20 1:01 PM, Daniel Kiper wrote:
> > >>> > >> > On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel
> > >>wrote:
> > >>> > >> >> On Sun, 26 Apr 2020 at 21:40, Atish Patra
> > >>
> > >>> > >wrote:
> > >>> > >> >>>
> > >>> > >> >>> This series adds grub loader support for RISC-V Linux.
> > >>Thanks to
> > >>> > >the awesome
> > >>> > >> >>> initial RISC-V support added by Alex, we just needed a
> > >>loader for
> > >>> > >RISC-V to
> > >>> > >> >>> load and execute Linux using UEFI protocol.
> > >>> > >> >>>
> > >>> > >> >>> Fortunately, ARM64 Linux loader is written in an
> > >>architecture
> > >>> > >agnostic manner
> > >>> > >> >>> so thatgeneric RISC-V can easily reuse the loader code.
> > >>Thus, the
> > >>> > >first patch
> > >>> > >> >>> just moves the ARM64 code to common code. I have compile
> > >>tested
> > >>> > >for
> > >>> > >> >>> ARM64/ARM32. Even though it doesn't introduce any
> > >functional
> > >>> > >change
> > >>> > >> >>> for ARM/ARM64, any real testing will be helpful.
> > >>> > >> >>
> > >>> > >> >> May I suggest that we not blindly adopt the ARM code here,
> > >>but
> > >>> > >> >> instead, use the new initrd loading protocol that removes
> > >the
> > >>need
> > >>> > >for
> > >>> > >> >> GRUB to modify or even know about the device tree at all?
> > >>> > >>
> > >>> > >> Does this protocol exist in EDK2 by now?
> > >>> > >>
> > >>> > >
> > >>> > >Yes. It exists as a shell command, and as a load option for OVMF.
> > >>> > >
> > >>> > >> In U-Boot there is a basic implementation which can provide a
> > >>single
> > >>> > >> initrd image with a hardcoded file name. The file_path argument
> > >>> > >passed
> > >>> > >> to U-Boot is ignored due to Ilias' security concerns when he
> > >>wrote
> > >>> > >the
> > >>> > >> patch.
> > >>> > >>
> > >>> > >> GRUB is only needed if we have multiple kernels to choose from
> > >>with
> > >>> > >> distinct initial ramdisks.
> > >>> > >>
> > >>> > >> Please, describe what you expect the initrd loading protocol to
> > >>do
> > >>> > >when
> > >>> > >> called from GRUB. How will the ramdisk fitting the kernel
> > >chosen
> > >>in
> > >>> > >GRUB
> > >>> > >> be identified?
> > >>> > >>
> > >>> > >
> > >>> > >The same what GRUB's 'initrd' command does. Whichever initrd you
> > >>> > >select with it is the one that gets returned by the protocol.
> > >>> >
> > >>> > Will GRUB provide the absolute device path in parameter file_path?
> > >>> >
> > >>>
> > >>> Which parameter 'file_path" is that?
> > >>
> > >>Ah, I guess you mean the LoadFile2 argument? That is always
> > >>end-of-device-path in this case, since the initrd device path only
> > >>consists of the vendor media GUID.
> > >>
> > >>The thing to keep in mind here is that the OS does not *choose* an
> > >>initrd, it simply loads the one that the bootloader has staged for it.
> > >
> > >How should U-Boot know which initrd fits the kernel chosen by the user
> > >in GRUB? That information exists in grub.cfg only.
> > >
> > >If GRUB cannot provide this information, what is GRUB's added value in
> > >the boot process?
> >
> > Hello Ard,
> >
> > Did I misunderstand you and you want to provide a LOAD_FILE2 implementation 
> > in GRUB and not use the one in the firmware?
> >
>
> Yes. If you use GRUB, it is provided by GRUB. Otherwise, it can be
> provided by U-Boot or EDK2.
>

Thanks for the discussion. I got clarification as well.
I will work on adding LOAD_FILE2 support in GRUB.

> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards,
Atish

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel