Re: Bug#260763: [powerpc] Problems with logical volume setup during installation
On Mon, Jan 10, 2005 at 12:49:45PM +0100, Michael Schmitz wrote:
> > > Why? Because we don't know how MockOS will react to a partition _type_ set
> >
> > I don't know any MockOS, please provide real examples.
>
> s/MockOS/MacOS/g
>
> > > to anything but Apple_Bootstrap, Apple_HFS, Apple_UNIX_SVR2 or Apple_Free.
> > > If you're sure (or just reasonably confident) Linux_LVM will be ignored by
> >
> > Just give it a try and enlighten us.
>
> Just as soon as I get another spare disk. BTW anyone can try that, so the
> call goes to the Mac users in general.
>
> > > Apple boot and disk mount code, go ahead. I can only test this for a
> > > fairly narrow range of OS X versions, and maybe a resurrected 8.6. Since
> > > there's always the partition name (for Apple_UNIX_SVR2 partitions which
> > > MacOS ignores since prehistoric times), I didn't really want to bother
> > > testing this.
> >
> > Yeah, but imagine that the user wants to use the partition name for something
> > sensible, and all this goes down.
>
> The user can still name the partition anything (s)he wants as long as LVM
> is part of the name.
Yeah.
> > > And libfdisk (for example) used to look at the partition _name_ field in
> > > Mac partition tables for clues where to find swap. What's the problem with
> > > that?
> >
> > well, suppose that a french user wants to name it "echange" instead of swap ?
>
> Too bad really. Suppose a french user is even unhappy with the Linux_Swap
> type setting. Same thing. With respect to computers, broken english
> is lingua franca.
Ah, no, that is not the case. The partition type is something which is used by
the system, and the user should not directly interfer with. The partition name
is something else.
> > > though, let's just try with 'Linux_RAID' and 'Linux_LVM' partition _type_
> > > fields in Mac partition tables, maybe add Linux_Swap later and keep plain
> > > data partitons as before. That should keep the comaptibility code to a
> > > minimum (look for 'swap' in type and name fields) and get the scheme some
> > > limited testing.
> >
> > Ok, but as said, Colin Watson vetoed me on that, and as we already have a
> > parted in experimental, ...
>
> Which does this, so unstable parted we shouldn't bother about?
Nope. the version in unstable is the same as the version in testing, which is
imposed to us by the debian-installer development model. This is why the
version which should have gone in unstable resulted in experimental, and we
can't also not to much hack it, since it will be in unstable as soon as d-i is
released or whatever.
> > > A mac-fdisk user can change either at will. Linux always reserves your
> >
> > The future belongs to libparted frontends though. And this is not linux, but
> > the new user-friendly debian-installer partman, so ...
>
> I don't care if it has super cow powers. You can't count on the partition
> table to be created by Linux tools, much less parted.
I can most assuredly count on each new debian/sarge install which is done on
RAID or LVM partition to use partmam, which is d-i's libparted frontend.
I doubt you could do it in another way without extensive d-i hacking, and we
won't support those users which do so.
> > > right to shoot yourself into the foot. But for the sake of saving users
> > > from their own stupidity, go ahead with the scheme you suggested.
> >
> > I would have for ages, but Colin Watson vetoed it without larger consensus,
> > and since he is one of the RMs, ... And beside i sort of agree with his
> > arguments about compatibility problems.
>
> So who is the LVM tools maintainer, and which committee do we have to
> address this across distros?
No idea, the lvm-tools and mdadm-tools maintainers would be a good start.
Like said, all go ahead and reach a consensus, and i will implement it not
only in debian's parted package, but also in upstream parted. And since all or
most distro's out there use a libparted frontend to their installer ...
Friendly,
Sven Luther
Reply to: