On Thu, Dec 27, 2001 at 05:08:35PM -0800, John H. Robinson, IV wrote:
>
> it seems that i have resolved, either through accident or design, most
> of the /instmnt problems.
>
> the only issue left is the Live CD.
and, of course, after putting the code down for a night, i came up with
some possibly better ideas:
1) if someone mounts a partition on /instmnt, they should be able to
access it via the menu. the ``mounted'' option did that. but that
seems to conflict with the mindset that mounted = part of /target.
we don't want to take that away, which my patches currently would.
2) the cdrom method will mount a cdrom, no worries about that. we
can safely ignore it.
3) LiveCD overloads (or seems to) the use of /instmnt. if true, this was
probably a hack in order to maximise utilage of existing methods.
now the issues are:
a) partitions mounted under /target,
b) LiveCD,
c) partitions hand mounted under /instmnt (via a shell)
d) mounting a previously unmounted partition
my proposal:
a) add a new method, ``target'' that specifically looks under /target
b) look to see if we are a LiveCD, add a method ``LiveCD'' or whatever,
that looks under some #define'd variable, so we can change it at will
to meet the whims of the LiveCD people. (with some trickery, and if
the LiveCD people say they want this, we can override the compiled in
default via some bootargs variables)
c) have ``mounted'' only available if there is a partition mounted on
/instmnt
d) same as it ever was
so b) and c) would be new, on demand, methods, similar in nature to the
``cdrom'' method.
this seems to leave everything as robust as possible, while making
things seem a bit more natural.
problems: the ``hard disk'' method first looks to see if anything is
mounted on /instmnt, and immediately umounts it. however, the
select_not_mounted() never sees this newly umounted partition.
if i go back to the main menu, then mack into ``hard disk'' (via install
kernel and modules) then it will see the umounted partition. there is
some other function that is resetting dbootstrap's idea of what
partitions are mounted or not. if you know, please tell me which one it
is, so i can see if i can insert it cleanly between the umount() and
select_not_mounted() calls.
otherwise, i will have to look on my own - and i hate searching for
needles in haystacks!
-john
erratta:
in discussing this with adam on irc (btw, my /nick is jaqque), he said
that he did not like the ``target'' method idea. he thinks that having
people wander about the real / (the RAM disk) is acceptable.
justification: power users (the assumed majority of people installing
debian) will be spawning a shell, and may mount something anywhere on
the RAM disk. first-time installers will be using a CDROM, so would not
be touching ``mounted'' anyway.
my counter-argument: unless you go outside the installer (such as
spawning a shell), the only places something will get mounted is /target
or /insmnt. i don't want the ``mounted'' method to overload to mean
/target or /instmnt, and a power user will be able to escape the /target
or /instmnt jail by using ``/..'' as a directory. this is ugly, but it
is functional, and i don't care about making things beautiful for people
that are doing things they should not be, anyway!
to add even more, i was given a boxes.c patch, that allows to escape the
/intmnt or /target jail. no trickery. this should not confuse newbies
too much, and gives power users the chance to wander all about the RAM
disk willy nilly. (the drawback? it gives newbies the power to easily
escape the /target or /instmnt, either by accident or design)
thoughts? (i'm not going to think about this for a couple of hours, so i
can let all this coalesce somewhat)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
