On Nov 11, 2013, at 2:57 PM, Nathan Whitehorn wrote: > On 11/11/13 15:51, Teske, Devin wrote: >> On Nov 11, 2013, at 1:43 PM, Nathan Whitehorn wrote: >> >>> On 11/11/13 15:39, Teske, Devin wrote: >>>> On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: >>>> >>>>> On 11/11/13 15:19, Teske, Devin wrote: >>>>>> Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... >>>>>> >>>>>> Should we do the quick patch to change the default >>>>>> from /boot/boot0 to /boot/mbr: >>>>>> >>>>>> Index: zfsboot >>>>>> =================================================================== >>>>>> --- zfsboot (revision 258016) >>>>>> +++ zfsboot (working copy) >>>>>> _at__at_ -764,7 +764,7 _at__at_ zfs_create_diskpart() >>>>>> # >>>>>> f_eval_catch $funcname gpart "$GPART_CREATE" mbr \$disk || >>>>>> return $FAILURE >>>>>> - f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/boot0 \ >>>>>> + f_eval_catch $funcname gpart "$GPART_BOOTCODE" /boot/mbr \ >>>>>> \$disk || return $FAILURE >>>>>> >>>>>> # >>>>>> >>>>>> That would fix things for Lenovo laptops for the next >>>>>> release until I finish up the bootcode selection menu. >>>>>> I'd like to take my time in making sure Allan and I design >>>>>> a worthy bootcode selection menu. >>>>> This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. >>>>> >>>>> On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: >>>>> 1. ZFS boot code >>>>> 2. UFS boot code >>>>> 3. boot0 >>>>> >>>>> Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step ("Install FreeBSD boot manager" or something), which also means it works for UFS systems. >>>> Well, I'm sensitive to the fact that sysinstall offered "none" and >>>> even explained why in an F1 dialog that brought up "drives.hlp" >>>> to explain that you might want to keep whatever (alternate) boot >>>> manager you may be using already. >>>> >>>> In a proposed selector, the full breadth of options that I was >>>> envisioning was: >>>> >>>> GPT + gptboot >>>> GPT + none (use your existing boot manager... syslinux?) >>>> MBR + mbr >>>> MBR + boot0 >>>> MBR + none (again, BYOBM) >>>> >>>> Hadn't got around to zfsboot yet. Where would that go? at the top? >>>> >>>> GPT + zfsboot ? >>>> >>>> (and of course, this is x86 specific... I was gleaning from sysinstall >>>> that for systems like pc98, they call it an IPL and there's only two >>>> options... a standard IPL or bring your own boot manager, aka "none"). >>>> >>>> I imagine that there would be architectures that are like the ol' pc98, >>>> wherein they don't have all these options (is, for example? sparc64 >>>> GPT only?) >>> This would be super-unportable. SPARC uses VTOC8, for example, and doesn't support GPT at all. PC98 has the differences you mentioned. PowerPC uses MBR sometimes, sometimes APM, sometimes GPT. You never have a choice. No platforms except x86 have any analog to boot0. Etc, etc. This is why I'd like to pull ZFS into partedit, which already knows how to set up everything and does the right thing everywhere. For the only system (x86) where there is a real choice (do you want to replace whatever you have already with boot0?), it makes sense to do this as a post-install config. >> Two migration paths before us, and I do rather like the idea of >> benefiting from all your work there. >> >> My biggest concern is how to maximize functionality in the >> migration of the ZFS stuff to partedit. >> >> You know the code better there better than I, ... have you given >> much thought to how you might integrate what we've done? > > Some, though not as much as it deserves. The general idea would be to treat ZFS as a kind of partitioning. I don't think we can realistically expose all ZFS features through the installer. > >> It's sad that we would be giving up i18n, X11, and discrete >> scripting (surely there are more parts to ZFS than what partedit >> supports now -- e.g., datasets, etc.). >> >> Naturally, the scripting can be solved. i18n is a bit harder to >> solve as it's a "start from the bottom" venture. And I fear X11 is >> a lost cause in its current state for partedit. > > This is a pity. I'm not sure what to do there. Would be nice to have something libdialog-alike for X, but that leaves all these other issues too. No matter which way I look at it, that sounds like a lot of work. One way is that it would just fork-exec Xdialog and return the results. Another way would be interfacing with an actual UI library like Tk, Gtk, Gtk2 or your favorite. But then, do we risk the app not looking like the rest of the functions if they use Xdialog(1)? But I'm thinking... We'd have to use dlopen(3) for conditional support anyway, because whatever dependency-chain we choose for X11, we can't link the binary (which will go into base) against the port dependency. Has to be runtime value-add. > One option would be to factor out the important bits of partedit longer-term, similar to the way to the scripting interface exists now (e.g. format this disk with these partitions, make the first one bootable, I don't care how it's done) and then call that from something prettier. Factor which part out how? Sounds good, but what were you envisioning? > Interactivity and the complexity of the things you can do with GEOM makes doing that fully hard, however (even the existing functionality ended up requiring kernel patches). I've struggled many times to think (on the fly) of a good clean way to make the UI, but I have come up with some ideas. When I think about the person that wants to do everything manually (but also wants the value-add of the UI, so doesn't necessarily want to do things with commands): NB: Based on $work deployments, currently done by hand + should be able to visit a menu for legacy partitioning + in that menu, request an MBR layout on mfid0 + in that MBR layout on mfid0, request part 1 of 4 to be FreeBSD (taking the entire disk) NB: bootcode requested to be written to this layout + in that FreeBSD part, add index 1 freebsd-ufs (taking 512G) + add index 2 freebsd-ufs taking up the rest + write requested changes and then go back to the previous menu + visit a gmultipath menu + write a multipath label with components da0 and da2 + write a multipath label with components da1 and da3 + return to the previous menu + visit a GPT menu + request GPT layout for multipath label based on da0/da2 + add a freebsd-ufs part to the GPT layout taking the entire disk NB: No bootcode to be written to this layout + write requested changes and then go back to the previous menu + visit a ZFS menu + request a new pool consisting of mfid0s1g and mfid1 + write requested changes and then go back to the previous menu + proceed with install (shakes head) Yeah... we do that. It's complicated, but there's reasoning behind it. But I'm envisioning a menu of compartmentalized partitioning menus. Allowing you to visit each one in any particular order. The gmultipath one is critical to our setup. NB: We have more complicated setups that require visiting the proposed menus in precisely the right order. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.Received on Tue Nov 12 2013 - 00:30:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC