Re: debian-installer: disk partitioner
David Whedon wrote:
>
> > I haven't been able to do concrete work yet. But I'm still interested in it,
> > so we can work together.
> great.
>
> >
> > > I've also seen conflicting info on how it should probably be done. I've seen
> > > libparted and libfdisk suggested, I'm not sure that people came to a conclusion
> > > as to which one to go with.
> > >
> >
> > Yes, that's true. I suggest let's not hurry it too much. What about first
> > looking into the design part of things to set up which one we should be using?
> >
> > I will do the homework, looking at the libs and then let's go on with what
> > exactly the features will be. Then we can code it.
> Definately a good aproach. At first glance libparted would be great if it
> wasn't so large. I like the idea of being able to resize partitions, which I
> think it does, and I don't think libfdisk does. But I do want to be able to
> install off a single floppy.
>
> The approach I'd like to take is to design the partitioner with an eye towards
> making a small udeb that does only the basics (not resizing perhaps), but have
> the option of having a larger udeb that would be fully featured. The smaller
> one goes on the single floppy, the larger on the CD, depending on relative size
> and room.
>
Partitioning udebs dont need t obe core componenets, i.e.e they can be
fetched after boot.
The only catch is that we need space to store and install udebs to
*prior* to installing them.
I think we could use either ramfs or loopfs for most cases for temperary
space
Problem with using either of these methods is that we dont know how much
space we will need prior to partitioning, so its hard to choose between
ramfs and loopfs.
ramfs by default will only use upto 1/2 of physical memory would be the
fastest method, but it wont work on a lot of machines.
loopfs we can use as much free space as is on the partition and would be
a more efficient aproach
Problems with using loopfs prior to partitioning.
1) if there is only one partition, and the loopfs is on that partition
is it possible to resize that partition with the loopfs mounted. Might
need to do somethingtricky here.
2) if there are no partitions we either need a simple partition tool, or
use some random space towards the end of the disk and create partitions
over it and mark the partition that covers the loopfs as unusable
somehow until the loopfs is moved, and the partition formatted. then we
might end up at problem 1.
We could use it as a whole disk device instead of partitions, but thats
going to get us further into the shit i think.
3) There is no local storage, for diskless clients, i guess they dont
need partitioning tools... mute point i guess.
Is the installer going to chroot from the boot media, or mount extra
space as partitions, if we dont chroot then we have to handle the
possibility that the rootfs is on a read only media.
> > - interface with formatter (or should that be in the partitioner?)
> The formatter should be a separate module. The only thing that needs to be
> communicated is /etc/fstab, right? We right it to the RAM disk? And perhaps
> that is how the partitioner's menutest knows it is done, an /etc/fstab exists on
> the RAM disk.
>
I think it should be a series of seperate modules that can all integrate
into main menu, likely candidates could be
partitioning
1) msdos style partitions
2) md (raid) partitions
3) lvm
4) loop
5) mac partitions
6) atari/amiga other arch ?
formatting
1) ext2
2) reiser
3) msdos
4) swap
5) minix ?
6) other trendy fs.
libparted could cover a few of these, but we wont be able to depend on
any one tool, we need to be able to handle multiple tools depending on
the situation.
We can use dependencies, formatting tools depend on partitions, which
partition tools provide.
Glenn
Reply to: