On Sun, Oct 28, 2012 at 12:22 AM, Chris Murphy <li...@colorremedies.com> wrote:
>
> On Oct 26, 2012, at 9:03 PM, Fajar A. Nugraha <l...@fajar.net> wrote:
>
>>
>> So back to the original question, I'd suggest NOT to use either
>> send/receive or set-default. Instead, setup multiple boot environment
>> (e.g. old version, current version) and let user choose which one to
>> boot using a menu.
>
> Is it possible to make a functioning symbolic or hard link of a subvolume?
>
Nope, I don't think so.
> I'm fine with "current" and "previous" options. More than that seems
> unnecessary. But then, how does the user choose?
WIth up and down arrow :)
> What's the UI?
Grub boot menu.
> Is this properly the domain of GRUB2 or something else?
In my setup I use grub2's "configfile" ability. Which basically does a
"go evaluate this other menu config file".
Each boot environment (BE, the term that solaris uses) has a different
entry on the "main" grub.cfg, which loads the BE's corresponding
grub.cfg.
>
> On BIOS machines, perhaps GRUB. On UEFI, I'd say distinctly not GRUB (I think
> it's a distinctly bad idea to have a combined boot manager and bootloader in
> a UEFI context, but that's a separate debate).
I don't use UEFI. But the general idea is to have one bootloader which
can load additional config files. And the location of that additional
config file depends on which BE user wants to boot.
> On this system, grub-mkconfig produces a grub.cfg only for the system I'm
> currently booted from. It does not include any entries for fedora18/boot,
> fedora18/root, even though they are well within the normal search path. And
> the reference used is relative, i.e. the kernel parameter in the grub.cfg is
> rootflags=subvol=root
>
> If it were to create entries potentially for every snapshotted system, it
> would be a very messy grub.cfg indeed.
>
> It stands to reason that each distro will continue to have their own grub.cfg.
>
No arguments there. Even in my setup, when I run "update-grub", it
will only update its own grub.cfg, and leave the "main" grub.cfg
untouched. This is how my "main" grub.cfg looks like:
#===========================
set timeout=2
menuentry 'Ubuntu - 20120905 boot menu' {
configfile /ROOT/precise-5/@/boot/grub/grub.cfg
}
menuentry 'Ubuntu - 20120814 boot menu' {
configfile /ROOT/precise-4/@/boot/grub/grub.cfg
}
#===========================
each BE's grub cfg (e.g. the one under ROOT/precise-5 dataset) is just
your typical Ubuntu's grub.cfg, with only references to kernel/initrd
under that dataser.
> For BIOS machines, it could be useful if a single core.img containing a
> single standardized prefix specifying a grub location could be agreed upon.
> And then merely changing the set-default subvolume would allow different
> distro grub.cfg's to be found, read and workable with the relative references
> now in place, (except for home which likely needs to be mounted using
> subvolid).
IMHO the biggest difference is that grub support for zfsonlinux, even
though it has bootfs pool property, has a way to reference ALL
versions of a file (including grub.cfg/kernel/initrd) during boot
time. This way you don't even need to change bootfs whenever you want
to change to a boot environment, you simply choose (or write) a
different grub stanza to boot.
If we continue to rely on current btrfs grub support, unfortunately we
can't have the same thing. And the closest thing would be
"set-default". Which IMHO is VERY messy.
--
Fajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
