From: Gene Czarcinski <gene@czarc.net>
To: "BTRFS, Linux" <linux-btrfs@vger.kernel.org>
Cc: Chris Murphy <lists@colorremedies.com>
Subject: Re: /boot as a btrfs subvolume
Date: Mon, 07 Jan 2013 10:42:37 -0500 [thread overview]
Message-ID: <50EAECED.8060809@czarc.net> (raw)
In-Reply-To: <795F4F16-84AD-4815-9CCB-B3C34BD33BC6@colorremedies.com>
On 01/06/2013 09:00 PM, Chris Murphy wrote:
> On Jan 6, 2013, at 1:05 PM, Gene Czarcinski <gene@czarc.net> wrote:
>
>> On 01/06/2013 02:17 PM, Swâmi Petaramesh wrote:
>>> Le 06/01/2013 20:11, Chris Murphy a écrit :
>>>> If you use UUID, and you use subvol=, and you don't rename/move your subvolume, it's perfectly safe. Nevertheless, GRUB becoming subvolid aware seems like a good idea to me, but I have no idea what's involved in that.
>>> I actually run several machines on which I have /boot in a separate
>>> BTRFS subvol, without any issue. I have a multiboot between several
>>> different distros (typically Ubuntu, Mint, LMDE, Bodhi... All Ubuntu
>>> derivatives except for LMDE which is Debian-based...) sharing the same
>>> BTRFS container and using different subvols i.e. UBUNTU/@boot,
>>> LMDE/@boot etc...
>>>
>>> Works just great.
>>>
>> I assume you have a "grub partition" (or its equivalent) with a grub.cfg file having menuentry definitions [pointing to the different grub.cfg file for each system ... that seems to work well (at least for me). Currently, os-prober does not support btrfs.
>>
>> I have taken a little look at the grub2 source code and there is some mention of both btrfs and zfs (and also btrfs subvolumes) in the changelogs. However, it is not clear to me (and I have not had the time yet) to explore exactly what the source code is doing or not doing.
> Well, at least with the f18 version of GRUB 2 2.00, whether alternative Btrfs bootable systems are mounted or not, -mkconfig isn't searching/finding for the /etc/fstab and /etc/default/grub of the other system like it appears to do with other file systems. I don't get any additional entries other than the currently booted Btrfs system.
>
> So it looks like I'd need to manually add a configfile menu entry, pointing to each Btrfs bootable system. Chainloading from one grub to another is not useful. Better if they're all on the same GRUB, and use configfile.
>
There appear to be two situations where you have multiple software
systems installed on the same hardware (real or virtual) -- root on a
btrfs subvolume or /boot installed on an LV.
I worked up a patch to os-prober and a small update to grub2 which
addresses the root on a btrfs subvolume -- see
https://bugzilla.redhat.com/show_bug.cgi?id=888341
I have not looked into the /boot in a LV so it may involve os-prober
also and I am also not sure that it will work with /boot on a btrfs
subvolume.
Since developing those patches, I have had second thoughts about how
multiboot should be done and now believe that it should involve a grub
partition with a simple grub.cfg file and os-prober disabled. The simple
grub.cfg file had menuentry definitions which point to the "real"
grub.cfg file for each system.
One of these simple definitions would look like:
menuentry "F18 on BTRFS" {
insmod part_msdos
insmod btrfs
set root='hd0,msdos5'
configfile /boot1/grub2/grub.cfg
}
where /boot is on btrfs subvol boot1
I do not actually use a grub partition but, instead, a minimal system
with grub2 and installation into the MBR.
Gene
next prev parent reply other threads:[~2013-01-07 15:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-05 21:17 /boot as a btrfs subvolume Gene Czarcinski
2013-01-05 21:27 ` Chris Murphy
2013-01-06 14:44 ` Gene Czarcinski
2013-01-06 19:11 ` Chris Murphy
2013-01-06 19:17 ` Swâmi Petaramesh
2013-01-06 20:05 ` Gene Czarcinski
2013-01-07 2:00 ` Chris Murphy
2013-01-07 15:42 ` Gene Czarcinski [this message]
2013-01-07 18:42 ` Chris Murphy
2013-01-07 21:41 ` Gene Czarcinski
2013-01-07 22:04 ` Chris Murphy
2013-01-07 17:48 ` Swâmi Petaramesh
2013-01-07 19:28 ` Chris Murphy
2013-01-05 21:32 ` Chris Murphy
2013-01-06 14:37 ` Gene Czarcinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50EAECED.8060809@czarc.net \
--to=gene@czarc.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).