Re: GSoC: Sysinst enhancements proposal

[David Laight <david%l8s.co.uk@localhost>]

On Sat, Mar 31, 2012 at 09:45:26PM +0400, Eugene Lozovoy wrote:
> About the project
> -----------------
> 
> The main goal of the project is to add to NetBSD installer (sysinst) ability 
> to install system to GPT-ed, LVM-ed, encrypted disks, RAIDs and to disk images
> (vnconfig). Also there are additional goals: improve sysinst usability and
> rewrite some utilities for more code sharing with sysinst.

Some comments which might be covered elsewhere:

1) Disk partitioning isn't trivial!
   NetBSD's sysinst is a lot more flexible than any? of the Linux
   installers. This is partially historic because it is defining
   layouts for systems that predate the PC and MBR.
   This is why the netbsd 'disklabel' ended up describing the contents
   of a single MBR partition (originally with partition-relative offsets).
   While I was hacking it sysinst I realised that the disklabel has to
   define the layout of the entire disk - but it is kept (on MBR disks)
   in the 2nd sector of every 'type 169' partition.
   For MBR disks you can either use a single 'bios' partition split
   into multiple pieces, or use a separate 'bios' partition for each
   filesystem (like Linux does) I tend to do the latter when splitting
   a disk into a lot of partitions.
   For GPT I suspect you'll use a separate GPT partition for each FS.
   With RAID you get the whole thing over again - do you use a single
   RAID for the disk, or separate ones for each FS?
   Oh - and make sure you tell the user what you are about to do and
   give them an option to change it slightly - rather than blindly
   using a 'default layout', makes it much easier to do a personalised
   install.

2) Installing to raid 1 (mirror)
   A simple method to get this working would be to add the 64 sector
   header before the partition and initialise it as a 'broken mirror'.
   The second disk can be added as a 'raid recovery' at a leter date.
   This avoids needing a lot of raind config options.

3) sysinst cointains code to read parameters from a config file - I'm
   fairly sure this hasn't been used in recent times and has bitrotted.
   Similarly it once attempted to print all the actual commands used
   during the install to a 'log' file. I beleive with a view to rerunning
   them of a second system, this also can't work and will miss things.
   (sysinst used to do everything by fork+exec'ing other programs, this
   makes error recovery far too difficult.)

4) I spent a lot of time on the retry loops during installation - mainly
   ensuring that they went back 'just' far enough to be useful while
   allowing all the silly mistakes to be corrected without restarting.

5) The disk partitioning functions would be useful on an installed
   system. Although you'd probably need to add code somewhere to
   ensure the base of partitions with mounted FS doesn't move.
   (Possibly changing the kernel so that the FS base/limit are prperties
   of the mount - currently (last I looked) they are taken from the
   current bound of the partition!)

6) I'm not sure of the value of trying to have too much in the way of
   automated installs - if you don't have identical hardware, or aren't
   doing a very simple 'use all the disk' install they aren't that much
   use.
   If someone wants to do system cloning, that is a different project!

7) I believe that 'msgc' and 'menuc' are only used by sysinst.
   I didn't worry about changing them (although I did try to maintain
   source compatibility).
   They do make writing dynamic menus a bit 'crufty', but it is the
   logic that gets diddicult, not the menu interface.

Enough rambling for now.

        David

-- 
David Laight: david%l8s.co.uk@localhost