On 08.11.2011 20:37, Seth Goldberg wrote: > > > Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following > on...: > >> On 08.11.2011 19:16, Seth Goldberg wrote: >>> >>> >>> Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following >>> on...: >>> >>>> Resending because of wrong oi-dev address at first try which caused it >>>> to be rejected from other 2 lists as well >>>> On 08.11.2011 02:19, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>>>> With this patch on top of trunk I was able to compile (using >>>>> GCC+GAS+GNU >>>>> LD), install, generate config and boot OpenIndiana. Some areas are >>>>> grey >>>>> to me. As like: >>>>> 1) Is it better to determine zfs-bootfs parameter on boot or on >>>>> config. >>> >>> (These opinions are based on Oracle Solaris): >>> Some grub entries may not specify a bootfs, in which case, GRUB should >>> derive it from the bootfs property in the pool >>> >> bootfs is an annoying one since on-disk AFAIK only its objnum is stored >> so we need to scan to determine its name. But for me it's only >> backward-compatibility issue. This property shouldn't be necessary with >> new or autodetected config. > > It's true you can get around it by triggering a config file > autogeneration when the bootfs property is changed. > >>>>> GRUB-Legacy does former but it has the problem that rpool may be >>>>> inaccessible to GRUB (it may be that only /boot/grub is accessible >>>>> to it) >>> >>> If the rpool is in accessible, then the top-level dataset should >>> also be inaccessible (unless I'm misunderstanding what you mean). >>> >> You can have a small disk locally holding only GRUB2, kernel and boot >> archive and rpool in a SAN, boot_archive taking care of mounting rpool. > > I'm not aware of any OpenSolaris distro doing that, but it is > possible. In that case, it's up to the administrator to ensure that > the bootfs value used is correct and that the pool is accessible to > GRUB2. > > >>>>> 2) What's the best way to handle "local" keyword? >>> >>> Remove it ;) ? >>> >> I have a patch for it few lines down in this ML. > > LGTM. > >>>>> 3) Does Illumos support* multiple kernels? >>> >>> (For O.S.) This is something that developers would use, IMHO, but not >>> something for production, because the boot environment construct is >>> used to isolate different bootable instances. >> Could you explain better what's boot environment is? Is it separate >> subvolume? How do we discover them. Should it be on runtime or config >> time? > > A boot environment is a child zfs dataset whose name is of a > specific form (<poolname>/ROOT/<BEname>). Each boot environment is a > separate, fully-contained bootable instance of Solaris. As of the > last OpenSolaris release, the only shared state is that state stored > on the top-level dataset of the root pool (that include the Legacy > GRUB menu.lst, boot signature (just a file that can be used to > identify the pool with findroot()), and some other miscellaneous > data). (See the beadm(1M) command for a better explanation). > Sounds like something trivial to scan for at boot time (and we already have everything we need to) thus reducing transition difficulty. > Thanks, > --S > > > _______________________________________________ > Grub-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/grub-devel
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
