[PC-BSD Dev] PC-BSD 8 installer (long)

A.Yerenkow yerenkow at uct.ua
Mon May 18 08:55:24 PDT 2009


On 18.05.2009 18:26, Kris Moore wrote:
> This weekend I had a chance to sit down and try to think out how our new
> installer should work for PC-BSD 8.x. Below is kind what I've come up
> with, to meet our requirements, and those suggested by users. Feel free
> to read and send your comments of what you like / don't like, or think
> we should add.
>
> LiveDVD
> ------------------------
> I would like to setup 8.0 to be both a LiveDVD, and installer all rolled
> into one. The idea is that at the FreeBSD boot menu, we'll have various
> options, like "LiveDVD" or "InstallOnly". When running the LiveDVD, we
> can also provide a link on the desktop to the installer, which allows
> the user to install directly from it. Install Only will be much faster
> to boot, and do an install of course, and may work better on systems
> which aren't capable of running KDE4 direct from DVD.
>    
I'd like to see independent tool for making partitions/formatting; let's 
call it ToolP,
available in installer/live/installED versions of PC-BSD.

> CD / USB
> ------------------------
> I would like to get rid of the 3 disk CD installer, and instead make
> just a small "boot-only" CD-ROM, which can then install PC-BSD 8.0 via
> FTP across the net, or local mirror.
We should add ability to point somewhere (not only net/CD/DVD),
maybe user downloaded ISO and placed it on FAT parttition; or have 
needed archives there;

> Ditto with USB, I would like to
> keep the boot-only USB image we use now, and just set it up to install
> via network.
>
> Installation Options
> ------------------------
> I would like to offer 3 types of installation from the installer.
>
> * Desktop - Regular PC-BSD KDE4 desktop
> * Server - PC-BSD which defaults to fluxbox instead of KDE4, and set's
> up SSH / other services
> * FreeBSD - Installs a regular FreeBSD 8.0 system, same as regular
> FreeBSD isos, except done via our nice installer :)
>
>
> Installation Process
> -----------------------
>
> Here's what I'm thinking we should do for the actual installation
> program flow:
>
>     * Locale Selection (We may be able to skip license stuff, since BSD
> license doesn't require us to agree and I can move nvidia license to
> only require user to accept if they use it specifically)
>     * Select install type / options
>         - Desktop, Server, FreeBSD
>         - Fresh, Upgrade, Repair
>    
How about Force Repair
when system couldn't findo out where the files is or if couldn't 
determine where is PCBSD installed.
And this could be used if we want override broken insallation, and have 
a lack of freespace (but all files could be overridden OK)
>         - Install from DVD or Network
>     * Select disk / partition to install to and do any advanced partioning
>    
I'd like to see here ToolP used; it's could be good for not-one-HDD systems;
>     * Select optional components. (Add PBIs, or KDE components, or
> Source/Ports on FreeBSD install)
>     * Setup User / Password (Only on FreeBSD Install, explained below)
>     * Perform Installation
>
> Then after the Desktop / Server installation is performed:
>
>       * Boot to a custom PC-BSD Welcome Screen
>       * Set Locale (If we did OEM-scripted install and skipped this setup)
>       * Ask user to set root-password and setup user accounts
>       * Ask user to set Xorg resolution / drivers, similar to how we do now
>
>
> Installation Guts
> -------------------
>
> Here's were we get down to the guts of the installation itself.
>
> For the new installer, I think we need to approach a backend/frontend
> driven hybrid model.
>
> I.E
>
> The front-end should be able to query the backend for pieces of
> information, such as available disks, partition information, networking
> availability, etc. Then the front-end can use this information to work
> its logic and allow the user to make their selections in any way it sees
> fit. Once the front-end is "ready to install", it then takes the users
> selections, and simply writes a small configuration file for the
> installer backend, such as pcinstall.cfg. Then the backend takes over
> and performs the installation automatically, and only provides
> information to the front-end to display the progress.
>
> I think this model will provide us with several advantages:
>
> First, this gives us great flexibility in the actual installation. We
> can easily tailor our GUI to fit any particular theme / program flow we
> wish. We can re-adjust front-end at any point, without re-writing the
> backend, or we could even add multiple installer front-ends, such as
> ncurses.
>
> Second, This will provide us with an easily script-able installation.
> One of the things people still like about FreeBSD's sysinstall, is that
> its script support is (fairly) easy to work with. This would give us the
> same functionality, and provide a great option for OEM installs. For
> example, an OEM could take a PC-BSD ISO, unpack it, throw in the
> pcinstall.cfg file, repack it and burn for the customer. Then if a
> desktop gets a new hard disk, or the user just wants to restore back to
> the original config, they boot the DVD and the installation takes place
> automatically with no interaction. Then at first boot, they are prompted
> to setup locale, username, and X configuration, just like when the
> received their new PC.
>
>
> Backends
> --------------------
>
> With this type of model, the most important question is going to be how
> we do the backend, since it'll be responsible for the actual
> installation itself. I know we've looked at finstall and bsdinstaller,
> but I'm not 100% certain they could do what I'm talking about without a
> lot of re-writing. I'll let Ivan and Scott answer that respectively,
> since they know those backends far better than I do :)
>
> If necessary I could simply adapt our existing scripts to this format,
> and provide a SVN-like CLI interface, or even a C library which could be
> called. (Our existing installer is almost entirely script driven now)
> The trick will be that we need to keep the backend as small as possible,
> and provide ways for the front-end to "query" the backend for system
> information, and let the backend actually perform the installation via
> front-end generated config file.
>    
>
> Thoughts?
>
>
>    



More information about the Dev mailing list