[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[fw: Re: kdetect and selectdevices]

meant to cc the list:

----- Forwarded message from David Whedon <dwhedon@gordian.com> -----

From: David Whedon <dwhedon@gordian.com>
Subject: Re: kdetect and selectdevices
To: Glenn McGrath <bug1@optushome.com.au>
Date: Thu, 25 Jan 2001 00:12:36 -0800

Sat, Jan 20, 2001 at 08:53:47PM +1100 wrote:
> I added two directories to cvs.
> kdetect is a library that gathers storage device info from /proc, its
> based loosely on what i sent to the list a while back but its cleaned up
> heaps, i called it kdetect (k for kernel) becasue it doesnt do any
> detection itself, just works out what the kernel has detected.


> selectdevice is a binary that depends in libkdetect and cdebconf, it
> just gets a list of devices that your system has, once a device is
> selected an operation can be selected to perform, e.g. display
> partitions, add partition etc.
> There will likely be a few small udebs like selectdevice
> (selectpartition, createpartition, createfilesystem, mountpartition etc
> etc) to basically be the interface between main-menu and the binaries
> that actually do the work.
I have a different vision here (just discussing, not arguing).  I would suggest
that the partitioning udeb detect all candidate devices (via kdetect), 
prompt for the the device to partition, and then do whatever to the device. I
think that combines 3 of the udebs you describe above into one.  I've written
partkit to do all except offer a choice of devices which you do in selectdevice.
I suggest partkit and selectdevice should be merged.

> So on i386 we should be able to determine what functionality the user
> want through main-menu with these sorts of questions and call libparted
> (or mkfs.ext2, or other mkfs.otherfilesystem, or other partitionign
> tools where libparted wont work) noniniteractively.

Maybe I'm going to describe exactly what you are talking about, we'll see :-)

If we want to call the partitioning udeb non-interactively we can, we just use
debconf.  An auto partitioner would still use the partitioning udeb I have
described above, but it would pre-set all the answers and set the 'seen' flags
to true, here's the sort of thing I'm talking about, a shell script that is run
as part of the autopartitioning udeb:

# This creates a partition on /dev/hdb from 0 to 256
db_set partkit/choose_dev /dev/hdb
db_fset partkit/choose_dev seen true

db_set partkit/choose_operation create
db_fset partkit/choose_operation seen true

db_set partkit/create_start 0
db_fset partkit/choose_start seen true

db_set partkit/create_end 256
db_fset partkit/choose_end seen true

db_set partkit/create_confirm true
db_fset partkit/choose_confirm seen true

This has the bonus of allowing us to automate and replicate installs using the
same techniques.

> Being able to call these tools noninteractively means we should be able
> have heaps of fun with autopartitioning which will make partitioning for
> mass installs easy and customisable. For auto partitioning we could have
> deferent "profiles" as udebs that dictate the rules (or guidlines) to
> how the partitioning is done. End users could build there own profiles
> to suit there needs or use probuilt ones that we make. But thats a way
> of, we have to get manual operation working first. 

I agree, that will be great!

By the way. I finally had the guts to try out partkit.  It wasn't happy because
we have no /dev/.  I went to create /dev/ and found that /sbin/MAKEDEV needs
'tr' from busybox, we'll need that, right?


----- End forwarded message -----

Reply to: