grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: booting btrfs


From: Chris Murphy
Subject: Re: booting btrfs
Date: Mon, 14 Oct 2013 21:12:06 -0600

On Oct 14, 2013, at 8:33 PM, Andrey Borzenkov <address@hidden> wrote:

> В Mon, 14 Oct 2013 22:50:10 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:
> 
>> On 14.10.2013 22:45, Chris Murphy wrote:
>>> 
>>> On Oct 14, 2013, at 1:29 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
>>> <address@hidden> wrote:
>>> 
>>>>> So it seems that GRUB is using relative pathnames to the default 
>>>>> subvolume.
>>>> This is not intentional. When this part of code was written there was no
>>>> set-default available at all so this couldn't be tested and I simply
>>>> followed the specification. It told to take root_tree and
>>>> root_dir_objectid from superblock then go to "default" directory. What
>>>> of this needs to be changed? Just remove "default" and make it part of
>>>> path? We would need to change grub-mkrelpath to match runtime behaviour.
>>>> Is there a way to detect that mountinfo gives garbage and somehow get
>>>> where the real root points?
>>> 
>>> Here's the response. It seems similar but not identical to what you 
>>> described above.
>>> 
>>> http://www.mail-archive.com/address@hidden/msg27955.html
>>> 
>> I don't see what is the difference between that and what GRUB currently
>> does. Will look tomorrow morning.
> 
> 
> I have a feeling that there was some misunderstanding about the
> problem. Or btrfs developers do not really intend to have multiple
> "active filesystems" at the same time and see "set-default" as the only
> legal way to switch between filesystem instances.


There are a number of use cases, and already for a while Fedora and openSuse 
leverage it, where boot, root, and home, are each subvolumes and each is 
mounted at the proper mount points. In effect three file systems are mounted at 
the same time.

A possible use of set-default would be as follows, each of the items is a 
subvolume:

[top level 5]
        home ID 274
        Fedora 19 ID 259
                boot ID 260
                root ID 261
                home ID 262
        Fedora 20 ID 270
                boot ID 271
                root ID 272
                home ID 273
        openSuse ID 265
                boot ID 266
                home ID 267
                usr ID 268
                var ID 269


By merely changing the set-default subvolume from 259 to 270, I'm booting a 
different version of Fedora. The same principle can work for making a subvolume 
"Fedora19-snapshot<date>" and then snapshotting the subvolumes in the Fedora 19 
subvolume. Now I can use set-default to rollback to the snapshotted version.

This works because at least Fedora's kernel command line, and fstab use 
relative subvolume  paths. So by changing the default subvolume, the relative 
paths are valid for a different version/snapshot of Fedora. And actually it 
works because of the unintended behavior I've found, where what looks like an 
absolute path for prefix, is relative. If it were followed absolutely 
regardless of default subvolume, prefix= would always point to the exact same 
grub folder and hence the same grub.cfg.

So actually, this is a bit more than somewhat messy, whether the prefix should 
be formatted relative to the default subvolume, or absolute from top level 5 
subvolume. It depends on the use case.

So just like '-o subvol=root' has a different meaning than '-o subvol=/root' 
there is a difference between prefix=(hd0,msdos1)boot/grub/ and 
prefix=(hd0,msdos1)/boot/grub/

Chris Murphy


reply via email to

[Prev in Thread] Current Thread [Next in Thread]