On Oct 26, 2012, at 9:03 PM, Fajar A. Nugraha <list@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
