Re: install to umsdos root?
In article <[🔎] Pine.LNX.3.96.970509205713.241J-100000@apb25.emma.cam.ac.uk>,
Adrian Bridgett <adrian.bridgett@poboxes.com> wrote:
>I think that it would be a good idea to allow users to install to a UMSDOS
>partition. I am sure there are a lot of people who would quite like to try
>out Linux, but are frightened of the install process.
>
>Imagine a future issue of PCW magazine with Debian on the cover CD. People
>could try Linux without repartitioning their hard disks, and fewer would
>trash their computers by installing LILO and then getting confused.
>
>This would make a trial use similar to installing a game demo - but
>probably use up less disk space :-)
>
>Any thoughts?
I agree, however, there are some problems (apart from the poor
performance and disk space taken up by symlinks):
The UMSDOS Kernel stuff has bugs in it:
a) The pseudo-root hack (effectively) does a chroot. When it comes to
{u,re}mount the root fs (during [re]boot), the system call fails
with bad arguments. There is an quick hack to fs/super.c which
fixes this but it is probably too disgusting to be added to the
kernel source.
Another possible way of fixing UMSDOS would be re-write it (!) to
munge the superblock to get pseudo-root functionality instead; most
of the re-write would involve redoing (or removing) the /DOS code
to work with this change. Munging the superblock works for ext2 (I
tried it) but may not work for umsdos (I haven't tried it).
It is possible to hack round this problem in /etc/init.d/[re]boot
(just don't do the remounts), this would preclude fsck.umsdos (see
below) as it would need a read-only fs to work on.
b) A mangled DOS fs can kill the UMSDOS fs code when mounted as umsdos.
I even have a .zip for the interested; any process that scans a
certain directory is killed with SEGV. The mess was created when
dpkg died during an attempted install. Cause unknown.
c) rmdir on a busy file gives the wrong error value (and dpkg fails to
upgrade libc as a result). The UMSDOS author has a patch for this,
I should check to see if it has gone into 2.0.30.
d) There are documented (in the source code, where else :-) problems
with umsdos and hard links. These should not occur often but should
be tidied by fsck.umsdos. Ideally, UMSDOS should have its hard
links done in a way that works better (hard).
e) Under certain circumstances (dpkg -i ...ncurses-term...) a link
system call never returns. This is not funny; it occurs by default
during the first dselect session. Cause unknown.
The user-level UMSDOS stuff is rather lacking.
f) There is no fsck.umsdos. The functionality is mostly there with
dosfsck and umssync but it needs to be put together.
g) I don't think umssync clears up lost hard links.
I've been working on the boot-floppies package to allow UMSDOS install
to pseudo root on and off for some time now. The kernel problems
(particularly those that appear with the use of dpkg) need to be
remedied before anything else is done.
Sorry to sound so pessimistic about all this. However, if it became an
'official' aim of Debian to get UMSDOS Debian working, Jaques Gelinas
(umsdos maintainer) might be prepared to expend some effort into
getting things fixed. I don't think anyone else is interested.
On the other hand, someone may come up with a better solution than
UMSDOS, stranger things have happened.
Giuliano
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . Trouble?
e-mail to templin@bucknell.edu .
Reply to: