Re: d-i, pulling in fdisk-udeb
On Thu, Oct 02, 2003 at 01:53:22PM +0100, Richard Hirst wrote:
> On Thu, Oct 02, 2003 at 09:51:08AM +0200, Sven Luther wrote:
> > On Wed, Oct 01, 2003 at 12:41:49AM +0100, Richard Hirst wrote:
> > > On Wed, Oct 01, 2003 at 01:38:11AM +0200, Steinar H. Gunderson wrote:
> > > > On Tue, Sep 30, 2003 at 04:32:20PM -0700, Matt Kraai wrote:
> > > > >> Make it depend on "partitioning-program", and make both fdisk-udeb and
> > > > >> parted-udeb "Provide[s]:" that. Should solve the problem.
> > > > > No, it won't. anna could still install just parted-udeb since
> > > > > that would satisfy the dependency. If partitioner depends on a
> > > > > particular udeb, it needs to Depend on the particular udeb.
> > > >
> > > > If parted-udeb is unusable on a particular platform, I'd take it it was never
> > > > built/uploaded for that platform at all...?
> > >
> > > I didn't mean to say that parted was unusable on hppa. It exists
> > > and probably works ok. But parted cannot be used for creating the
> > > 'f0' partition that palo needs.
> >
> > Have you ever considered asking the parted upstream author or filling a
> > bug report against the parted debian package, for this particular
> > feature request.
> >
> > I have been doing some parted work, but know nothing about the hppa
> > specific needs, but if you explain it to me, i may be willing to add the
> > needed support to libparted or something.
>
> I've put quite a bit of effort in on parted in the past too, relating to
> GPT partition tables. The issue is that parted tends to identify
> partition types by their content, and not by the 'type' byte in an msdos
> partition table. This is partly because parted handles many different
> partition table formats, they don't all have a 'type' byte, and parted
> tries to present a uniform interface. GPT tables, for example, have a
> 32 byte GUID instead. So parted lets you say "this partition is for
> linux swapspace", and for msdos tables it knows to set the type to 82
> and for GPT it knows to use some specific GUID. Some special types or
> GUIDs are exposed to the parted interface as 'flags' you can set. e.g.
> if you set the hp_service 'flag', it will write the
> PARTITION_HPSERVICE_GUID in a GPT table.
So, the GPT partition table is for alpha and ia64.
> To fix this issue, I'd need to expose a new flag through the parted i/f,
> so you could "set palo on", or similar. For msdos tables it would know
Adding a flag is almost trivial to do, no ?
> that meant to set type=f0. For other partition table types it would
> have no effect. Alternatively I could introduce a new command
> completely for setting a partition table 'type' to some user-specified
> hex value. But what would that do for non-msdos tables? Having an
> interface where you can type in 32 byte GUIDs seems silly to me.
Notice that libparted already knows how to do that, but does it only
when writing filesystem. There is no way currently to tell libparted to
set a given partition type, and use another tool to create the
filesystem. I have also been playing with the thought of adding some
kind of attribute setting for partitions, which could accept, in
addition to boolean flags, also other kind of values (which are needed
to set the filesystem block type on amiga partition/filesystems for
example, as well as the boot priority).
> As to why I havn't done anything about this.. there really hasn't been
> any incentive as we have cfdisk on hppa which works fine and has a nice
> easy to understand interface. If d-i ends up dictating that I have to
> use parted, or eventually presents a nicer interface to parted than its
> current cli one, then it'll be worth worrying about.
Well, libparted is not only used by parted propper, but also by a bunch
of other tools in d-i.
Friendly,
Sven luther
Reply to: