Re: Naming of (bootable) subvolumes
On 2012-10-27 19:22, Chris Murphy 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? I'm fine with current and previous options. More than that seems unnecessary. But then, how does the user choose? What's the UI? Is this properly the domain of GRUB2 or something else? On my computer, when update-grub is called, it scans for all the subvolumes and show them in the menu, allowing the user to switch at boot time. [...] Example. The following are all subvolumes, subvolume set-default 0, fstab uses subvol=home, subvol=root, subvol=boot for mount options. toplevel ├── boot ├── home ├── root ├── fedora18 │ ├── boot │ └── root 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. I don't think so. If a subvolume has a /sbin/int and and /etc it would be suitable to be used as root filesystem. -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
Re: Naming of (bootable) subvolumes
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
Re: Naming of (bootable) subvolumes
On Oct 28, 2012, at 3:25 AM, Goffredo Baroncelli kreij...@inwind.it wrote: On Sun, Oct 28, 2012 at 12:22 AM, Chris Murphy li...@colorremedies.com wrote: On my computer, when update-grub is called, it scans for all the subvolumes and show them in the menu, allowing the user to switch at boot time. If they can go in a snapshots submenu, fine. But UI wise, messy and not inherently a good idea to expose to regular Joe user in the main menu. What's the kernel parameter rootflags= line they're using? Is it a subvol hard path or subvolid? If it were to create entries potentially for every snapshotted system, it would be a very messy grub.cfg indeed. I don't think so. If a subvolume has a /sbin/int and and /etc it would be suitable to be used as root filesystem. I understand it's suitable in that it will work. I'm just saying I don't want to see it by default in a menu. I do want to have to go dig for it, because most people most of the time won't have a need to use them. So in the main menu an option 'Snapshots' or 'Previous Systems' to reveal the snapshot list makes sense. On Oct 28, 2012, at 3:38 AM, Fajar A. Nugraha l...@fajar.net wrote: What's the UI? Grub boot menu. If the UI for switching between subvols is via grub, that means no dependency on 'subvolume set-default'. While you can call the root subvolume absolutely with rootflags=subvol=/hardpath/here/ or rootflags=subvolid=, what about the boot subvol? That's always a relative path as far as I can tell. So is the grub boot menu itself, i.e. t he grub.cfg that's used depends on the set-default. Are Ubuntu snapshots based just on snapshotting the root subvolume and keeping all possible kernels in a boot subvolume? 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. *sigh* two GRUB menus. Twice the pain, three times the mischief. But I understand how this works. 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. Therein lies some confusion to answer the question of how to organize snapshots and boot from them. Various boot managers and boot loaders should be taken into account, and UEFI firmware implication should be taken into account as well. 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. I'm not entirely familiar with how ZFS implements snapshots or grub's support for them. But it sonds like the bootfs pool property supports absolute path names everywhere, including from within the GRUB core.img? So you're suggesting a GRUB2 limitation when it comes to btrfs? Fedora has also a limitation where kernel updates are still using grubby, not grub-mkconfig. That's also a problem IMO. It basically just takes the current entry and makes a kernel modification. If a snapshot is produced with each upgrade, the resulting grub.cfg will not be aware of or point to demoted kernels in snapshots. So if GRUB is a weak link for btrfs support, grubby is a weaker link. Will btrfs send / receive for snapshotting produce large storage requirements isn't it? If I send a current subvol to another subvol as a snapshot, am I not effectively making a copy of that whole sub-filesystem? Whereas 'subvolume snapshot' just does this with metadata, no meaningful additional space required. Only the updated files consume more space, regardless of which snapshot they're applied to. Chris Murphy -- 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
Re: Naming of (bootable) subvolumes
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? I'm fine with current and previous options. More than that seems unnecessary. But then, how does the user choose? What's the UI? Is this properly the domain of GRUB2 or something else? 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). However for this to work, grub (the bootloader, and the userland programs like update-grub) needs to be able to refer to each grub.cfg/kernel/initrd in a global manner regardless of what the current default subvolume is (zfs' grub code uses something like /poolname/dataset_name/@/path/to/file/in/dataset). Example. The following are all subvolumes, subvolume set-default 0, fstab uses subvol=home, subvol=root, subvol=boot for mount options. toplevel ├── boot ├── home ├── root ├── fedora18 │ ├── boot │ └── root 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. 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). For UEFI machines, the plan needs to work with other bootloaders, including the linux kernel's EFISTUB. Chris Murphy -- 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
