Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Feb 2009 10:59:57 -0800
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Ulf Lilleengen <ulf.lilleengen@gmail.com>
Cc:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, FreeBSD current mailing list <current@freebsd.org>
Subject:   Re: boot0cfg -s vs. GEOM_PART_*?
Message-ID:  <9FE792C6-8560-4C64-BD74-CD70DF5EBBF5@mac.com>
In-Reply-To: <20090217193759.GA27739@carrot>
References:  <20090217113718.N53478@maildrop.int.zabbadoz.net> <D1292F9E-BF53-443F-9E63-92D527A41A3B@mac.com> <20090217193759.GA27739@carrot>

next in thread | previous in thread | raw e-mail | index | archive | help

On Feb 17, 2009, at 11:38 AM, Ulf Lilleengen wrote:

> On Tue, Feb 17, 2009 at 10:29:10AM -0800, Marcel Moolenaar wrote:
>>
>> On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote:
>>
>>> with a fresh kernel and world from last night I get:
>>>
>>> dopt# boot0cfg -s 3 ad4
>>> boot0cfg: /dev/ad4: ad4
>>> boot0cfg: /dev/ad4: ioctl DIOCSMBR: Inappropriate ioctl for device
>>>
>>> is this GEOM_PART_* fallout and can it be fixed?
>>
>> boot0cfg is not (yet) supported by GPART. It should not
>> be too hard:
>> 1.  We need to expose the current bootcode through
>>     kern.geom.confxml
>> 2.  boot0cfg grabs the bootcode from the XML, makes
>>     the changes in memory and then uses existing
>>     g_part ctlreq to update the bootcode.
> Mhm, this seems to be a good way to do it. Also, fdisk and bsdlabel  
> might
> need a sweep as well.

That won't be as easy as boot0cfg. Both fdisk and bsdlabel
do all partitioning operations in memory and then expect to
dump/write the blob. This is not how gpart works, so there's
a mismatch in paradigm.

With respect to partitioning, I'd rather we focus our
attention to a more user-friendly tool. The geom tool is
really low-level and could use some UI "fodder".

Also, I started writing pe(8) a while back, which is
a ncurses-based partition editor. I think a nice
partitioning tool would be good to have.

For those interested in pe(8), I have diffs here. It's
nowhere near useful, but it should give a first glipse
of what I was thinking of:
	http://people.freebsd.org/~marcel/gpt.diff

Certain aspects of the code show early thinking and has
been implemented differently in gpart nowadays... :-)

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9FE792C6-8560-4C64-BD74-CD70DF5EBBF5>