Date: Wed, 23 Apr 2014 14:12:36 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Allan Jude <freebsd@allanjude.com>, freebsd-sysinstall@freebsd.org Subject: Re: bin/164281: bsdinstall(8): please allow sysinstall as installer option Message-ID: <53582CC4.2080808@freebsd.org> In-Reply-To: <535827AC.3040503@allanjude.com> References: <201404151630.s3FGU0Zg026166@freefall.freebsd.org> <CAM9wqY8Bn9yQvMbpMdg1wcVhx5AGgK6rP1tkh9qccDhWZaU9Kw@mail.gmail.com> <012501cf5f1f$c5e7c740$51b755c0$@FreeBSD.org> <5358223B.1090408@gmail.com> <535827AC.3040503@allanjude.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/23/14 13:50, Allan Jude wrote: > On 2014-04-23 16:27, Allen Landsidel wrote: >> On 4/23/2014 14:13, dteske@FreeBSD.org wrote: >>> As I continue the lay the ground-work for a bsdinstall that is superior >>> to sysinstall, do I split my time amongst that task and provision a new >>> task of migrating sysinstall toward resurrection with the afore- >>> mentioned fixes? >> I think it depends on whichever path gets us to a 'nice' installer the >> quickest. The end result should be the same and I can't see how it >> matters which one is used as a base. Splitting coding time between >> the two just sounds silly unless the goal is to keep both alive >> indefinitely. >> >> My gut says to start with sysinstall and refactor it to abstract out >> interfaces to the stuff that needs replaced, then do the underlying >> replacement. I only say this because getting 100% feature coverage >> (and testing of those features) into bsdinstall is going to be pretty >> labor intensive vs. refactoring sysinstall and leaving all the >> features in place. >> >> Of course that undermines all the work you've already done on bsdinstall. >> >> The UX is one of the things that's really terrible in bsdinstall vs. >> sysinstall, and if that's libdialogs fault, I'm skeptical that this is >> the right path to begin with. A simple example is the disk >> partitioning interface, which seems to have taken a step backwards >> even in bsdinstall itself from FreeBSD 9 to 10. The break between >> when you use the tab key vs. arrow keys is obnoxious. For that >> matter, so is the removal of the historical default partitioning >> scheme for a new linuxy "one big root" default, but I'm getting a bit >> off topic and may even predate bsdinstall. I can't remember. >> >>> So to help answer the question of prioritization (given that demand >>> still exists for sysinstall), I think the best way to guide us is a >>> Wiki. >>> >>> I recommend that we develop a f.o Wiki that we can all edit to >>> contain our partiticular misgiving of bsdinstall versus sysinstall. >> It's worth a shot. If you want to set it up, send a link and I'll >> find some time to rant into it. >> >>> That being said... with respect to the actual PR of bringing back >>> sysinstall >>> as an option... I'm not against it. In fact, seeing that someone >>> posted on >>> the PR to check-up on me, I think it's time (once 9.3 comes out) to >>> roll a >>> new Druid disk. For those that don't know... I serve sysinstall based >>> media >>> from druidbsd.sf.net for 9.x releases (albeit I haven't cut one since >>> 9.0). >> I didn't realize that was you. I used druid for all my 9.x installs >> and the only reason I responded to the PR is because there wasn't one >> for 10.0, and when I installed it, I was seeing red over bsdinstall >> all over again. I'd forgotten about it entirely until being >> confronted with it again. >> >>> I'll make sure to cut one for 9.3 so that people wanting sysinstall >>> can not >>> only have it, but can have the one I developed for $work which has many >>> MANY enhancements -- *cough* including the ability to install from a USB >>> thumb drive *cough*. (smiles) >> Very nice. >> >> I'm in a fully virtualized environment, so once I get a base system >> set up, I just clone it repeatedly and make changes to that. This >> means I rarely am reminded of the user-unfriendly fiasco that >> installing FreeBSD has become. Sysinstall was of course nice for >> other reasons, not least of which was a quick way to look for ports >> without digging through the freebsd.org web interface or make >> find+grep etc. >> _______________________________________________ >> freebsd-sysinstall@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-sysinstall >> To unsubscribe, send any mail to >> "freebsd-sysinstall-unsubscribe@freebsd.org" > sysinstall does not support GPT either. sysinstall's disk editor was atrocious, error-prone, buggy, and supported only a tiny subset of configurations. You couldn't even install to multiple disks, never mind GPT. Where we are now, with runtime system configuration (bsdconfig) separated from the installer (bsdinstall) is much better. Hopefully, we'll be able to rip out the limited system configuration in bsdinstall and replace it with calling bsdconfig in a chroot very soon, which will reduce the installer to (as it should be) nothing more than a disk editor and tar. > The change to the default partitioning scheme is kind of unrelated to > the installer. Offering a button for each might be useful, but > especially in a virtualized environment, 'one big root' is better, > because you can easily grow the disk, which isn't always possible with > the many partitions setup. > > What I would like to see bsdinstall get, is support for making gmirror > and geli UFS installs, it seems like a logical step after we added ZFS > (stripe, mirror, raid) with optional GELI. This would not be bad at all. The existing code supports mirrors and geli already, just through GEOM, but doesn't have a UI to make them. Adding one shouldn't be hard, at least from a code standpoint. If you look at the partition editor code, the interface to gpart is modular -- that is meant to be extended for other GEOM classes like geli etc. or ZFS. Designing a useful TUI for it might be harder. > I had big ideas for the ZFS part of the installer, to extend it further > to allow multi-way mirrors and customizing the dataset layout. That's nice to hear. Hopefully you can integrate it into the regular partition editor too. It's about to grow support for setting EFI systems and duplicating that logic around would be unfortunate. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53582CC4.2080808>