Newsgroups: comp.os.linux
Path: sparky!uunet!elroy.jpl.nasa.gov!decwrl!csus.edu!netcomsv!mork!genie
From: ge...@netcom.com (Gene Choi)
Subject: Linux installation .96a?
Message-ID: <3ndltdd.genie@netcom.com>
Date: Sat, 13 Jun 92 07:52:08 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Lines: 17
Well, I was successful in installing Linux boot and root into
my IBM 386 33! I installed version 0.95c+. I wanted to
install 0.96a (the newest version?) but was only able
to find the boot image disk to .96a... I was unsuccessful
in finding the root (utility) image in any of the ftp sites.
Can someone please tell me what I'm doing wrong?
I ran into a problem when installing 0.95c+. I have a 114 meg Conner
IDE, and partioned it using fdisk 30 megs DOS, 40 megs Linux
primary, and 44 megs extended. I divided the extended into 2 logical
drives, and used a 10 meg logical drive as the swap drive. However,
what command must I type for Linux to use the 34 megs left in the
extended drive? (I mkfs'ed it normally during the installation).
Gene
Newsgroups: comp.os.linux
Path: sparky!uunet!elroy.jpl.nasa.gov!news.claremont.edu!
jarthur.claremont.edu!jwinstea
From: jwin...@jarthur.claremont.edu (Jim Winstead Jr.)
Subject: Re: Linux installation .96a?
Message-ID: <1992Jun13.173914.24222@muddcs.claremont.edu>
Sender: ne...@muddcs.claremont.edu (The News System)
Organization: Harvey Mudd College, WIBSTR
References: <3ndltdd.genie@netcom.com>
Date: Sat, 13 Jun 1992 17:39:14 GMT
Lines: 42
In article <3ndltd...@netcom.com> ge...@netcom.com (Gene Choi) writes:
>
>Well, I was successful in installing Linux boot and root into
>my IBM 386 33! I installed version 0.95c+. I wanted to
>install 0.96a (the newest version?) but was only able
>to find the boot image disk to .96a... I was unsuccessful
>in finding the root (utility) image in any of the ftp sites.
>Can someone please tell me what I'm doing wrong?
>
The reason you're not able to find the root image for 0.96 is because
it hasn't been released yet. I apologize greatly for this, but the
shift from school to home was a little rougher than I expected, and I
haven't had the resources to put together the 0.96 root disk.
This will change this next week, however, as I will be getting an
account on a University of Minnesota machine, and will be able to
telnet over to my account here and also have ftp access again.
Because of this, I hope to have the 0.96 root disk released by the end
of next week. It will use shared libraries (hopefully from the gcc
2.2.1 release) and not contain the horrid tar/compress from the 0.95a
root disk.
Also, sometime after I release the 0.96 root disk, I will be releasing
a 'supplemental' disk, with some of what I, and others, consider the
essential utilities for Lnux. This will include, but not be limited
to, kermit, pcomm, an editor or two, mtools, the GNU shell and text
utilities, and whatever else people suggest.
Again, I apologize for being so late on all this. I did not expect
moving back home for the summer would be so traumatic....
One last thing, I have made the offer in several places (Compu$erve
and RIME) to send Linux itself and many utilities on disk or QIC-40
tape. If you'd be interested in such a thing please send me email at
the address below. (Oh, this is a summer-only type of deal....)
--
+ Jim Winstead Jr. (CSci '95)
| Harvey Mudd College
| jwin...@jarthur.Claremont.EDU
+ This is all my words. Honest!
Newsgroups: comp.os.linux
Path: sparky!uunet!nuchat!kevin
From: ke...@nuchat.sccsi.com (Kevin Brown)
Subject: Re: Linux installation .96a?
Message-ID: <1992Jun15.231850.28347@nuchat.sccsi.com>
Organization: Teenage Mutant Ninja NiceGuys(tm)
References: <3ndltdd.genie@netcom.com>
<1992Jun13.173914.24222@muddcs.claremont.edu>
Date: Mon, 15 Jun 1992 23:18:50 GMT
Lines: 90
In article <1992Jun13.1...@muddcs.claremont.edu>
jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>In article <3ndltd...@netcom.com> ge...@netcom.com (Gene Choi) writes:
>>Well, I was successful in installing Linux boot and root into
>>my IBM 386 33! I installed version 0.95c+. I wanted to
>>install 0.96a (the newest version?) but was only able
>>to find the boot image disk to .96a... I was unsuccessful
>>in finding the root (utility) image in any of the ftp sites.
>>Can someone please tell me what I'm doing wrong?
>>
>
>The reason you're not able to find the root image for 0.96 is because
>it hasn't been released yet. I apologize greatly for this, but the
>shift from school to home was a little rougher than I expected, and I
>haven't had the resources to put together the 0.96 root disk.
>
>This will change this next week, however, as I will be getting an
>account on a University of Minnesota machine, and will be able to
>telnet over to my account here and also have ftp access again.
>
>Because of this, I hope to have the 0.96 root disk released by the end
>of next week.
So far so good...
>It will use shared libraries (hopefully from the gcc
>2.2.1 release) and not contain the horrid tar/compress from the 0.95a
>root disk.
This is probably a mistake. Having the root disk binaries depend on the
shared libs will cause *everything* to break horribly if the shared
libraries die for any reason. This will make the root disk unsafe for
the purposes of restoring a crashed system.
The benefits are clear, of course (more space on the root disk) but I
think the danger of having everything in the system depend on one file
easily outweighs any advantages of having more binaries on the root disk.
My opinion is this: the root disk distributed with the system should contain
the minimum number of binaries necessary to get the system installed and
running. Things like tar, compress, ash, ed (or some other very small editor,
perhaps something like joe), pfdisk, mtools, etc., fall into the category of
necessary tools. Things like vi, gcc, fdisk (since it doesn't function
properly with all configurations), bash, etc., are unnecessary for
installation of linux *if* you know what you're doing.
The space that is taken up by what spurious and unnecessary utilities that
currently exist on the root disk can more effectively be used for
documentation that will give the person installing the system a better
understanding of what's going on and how to use the tools that have been
made available to him. A rudimentary set of man pages on the root disk
might be a better use of space (particularly since they can be compressed)
than a few more utilities.
>Also, sometime after I release the 0.96 root disk, I will be releasing
>a 'supplemental' disk, with some of what I, and others, consider the
>essential utilities for Lnux. This will include, but not be limited
>to, kermit, pcomm, an editor or two, mtools, the GNU shell and text
>utilities, and whatever else people suggest.
See above. Some of these, such as mtools, should be put on the root disk,
IMHO.
Mtools in particular should be on the root disk. The reason is that most
of the people who install Linux will have DOS on their machines, and a good
many of them will have various pieces of linux on their DOS partitions. If
mtools is not available to them, it will be much more difficult for them to
access the things they left on their DOS partition. Since various comm
programs exist under DOS, it's much easier to grab things under DOS and
access them from Linux when needed, than it is to attempt to get a working
kermit (or some other comm program) going under Linux, particularly since
some have trouble with their serial ports dropping characters and such.
> + Jim Winstead Jr. (CSci '95)
> | Harvey Mudd College
> | jwin...@jarthur.Claremont.EDU
> + This is all my words. Honest!
Other than a few nits here and there, good work!
--
Kevin Brown
ke...@nuchat.sccsi.com
ke...@taronga.taronga.com
--
Kevin Brown
ke...@nuchat.sccsi.com
ke...@taronga.taronga.com
Newsgroups: comp.os.linux
Path: sparky!uunet!elroy.jpl.nasa.gov!news.claremont.edu!
jarthur.claremont.edu!jwinstea
From: jwin...@jarthur.claremont.edu (Jim Winstead Jr.)
Subject: Re: Linux installation .96a?
Message-ID: <1992Jun16.044415.11348@muddcs.claremont.edu>
Sender: ne...@muddcs.claremont.edu (The News System)
Organization: Harvey Mudd College, WIBSTR
References: <3ndltdd.genie@netcom.com>
<1992Jun13.173914.24222@muddcs.claremont.edu>
<1992Jun15.231850.28347@nuchat.sccsi.com>
Date: Tue, 16 Jun 1992 04:44:15 GMT
Lines: 78
In article <1992Jun15.2...@nuchat.sccsi.com> ke...@nuchat.sccsi.com
(Kevin Brown) writes:
>In article <1992Jun13.1...@muddcs.claremont.edu>
>jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>>It will use shared libraries (hopefully from the gcc
>>2.2.1 release) and not contain the horrid tar/compress from the 0.95a
>>root disk.
>
>This is probably a mistake. Having the root disk binaries depend on the
>shared libs will cause *everything* to break horribly if the shared
>libraries die for any reason. This will make the root disk unsafe for
>the purposes of restoring a crashed system.
Aigh! I wish I had a nickel for everyone that has tried to argue this
case - that way I could afford to have someone repeat me. :)
The root disk is completely self-contained. Whether it uses shared
libraries or not is of no consequence - the binaries and libraries
are *together* on the *same disk*.
Besides, who care if the root disk breaks? Remember that copy of the
root image you saved? Write out a new image! Remember that backup of
the root image? :) The root disk is first a foremost designed for
the installation and repair of Linux systems - if it would work that
way, I would recommend write protecting it. (Unfortunately, it
wouldn't work - darn.)
>The benefits are clear, of course (more space on the root disk) but I
>think the danger of having everything in the system depend on one file
>easily outweighs any advantages of having more binaries on the root disk.
It already depends on one file - rootimage-0.96.Z. :) The odds of
that being corrupt are greater than that of lib-2.2.2 (or whatever),
since it's bigger.
>My opinion is this: the root disk distributed with the system should contain
>the minimum number of binaries necessary to get the system installed and
>running. Things like tar, compress, ash, ed (or some other very small editor,
>perhaps something like joe), pfdisk, mtools, etc., fall into the category of
>necessary tools. Things like vi, gcc, fdisk (since it doesn't function
>properly with all configurations), bash, etc., are unnecessary for
>installation of linux *if* you know what you're doing.
mtools also isn't necessary if you know what you're doing.
>The space that is taken up by what spurious and unnecessary utilities that
>currently exist on the root disk can more effectively be used for
>documentation that will give the person installing the system a better
>understanding of what's going on and how to use the tools that have been
>made available to him. A rudimentary set of man pages on the root disk
>might be a better use of space (particularly since they can be compressed)
>than a few more utilities.
Um, should I try and fit 'man' on the disk, too? But that seems kind
of spurious and of limited necessity. :) Really, I think
documentation should be seperate from the root disk - the idea is to
pack maximum utility there so things can get done. How do people
print out documentation under Linux if they aren't familiar with Linux?
>Mtools in particular should be on the root disk. The reason is that most
>of the people who install Linux will have DOS on their machines, and a good
>many of them will have various pieces of linux on their DOS partitions.
This discussion was had before the 0.95a root disk was released, and
due to space constraints, mtools was not on that root disk. It will
be on the 0.96 supplemental image at the very least, and the 0.96 root
image if it fits. I have mixed feelings about mtools - it's handy,
but is not absolutely necessary. (More of a luxury than a necessity,
that is.)
>Other than a few nits here and there, good work!
Thanks, the kinds words let me fight the insanity back. :) I'm sorry
if I sound harsh, but you caught me at a bad time with two familiar
(and distasteful) issues.
--
+ Jim Winstead Jr. (CSci '95)
| Harvey Mudd College
| jwin...@jarthur.Claremont.EDU
+ This is all my words. Honest!
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: RE: not using shared libs on root disk.
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria, BC, CANADA
Date: Tue, 16 Jun 92 07:28:09 GMT
Saying "Don't use shared libs on the root disk because then you will be
relying on one file" kinda misses the point. Linux already depends on
certain key files. What would you do if sh/bash were deleted (keep in mind
Linux demand pages from the executable). How about the /dev directory. Or
shoelace/Image. Really, any of these will cause a system failure, as can
an fs corruption.
None of this prevents booting from the shared lib root floppy and
cp /lib/lib* /hd??/lib.
As an ounce of prevention, you should chmod ugo-w /lib/lib*.
I do wish people would stop railing against the use of shared libs. Shared
libs are a good idea. They help keep hd reqs down, and reduce network
bandwidth for postings. We can also link small images like login, etc
with -N, to eliminate the headers. And images should be posted as .a's.
Examples of bad ideas, however, are alternate shells and editors, like ash
and joe. God, one of the things I hate about SUN/OS is the two shells,
csh and sh (quick now, which is it, for i or foreach).
By all means, use whatever shell etc you want on your system. But lets
at least keep the distribution simple.
Of course, I am one of those individuals who beleive it is silly to use
MGR when X is around :-)
Peter.
pmacdona@tadpole.bcsc.gov.bc.ca
Path: sparky!uunet!mcsun!uknet!mucs!mccuts!zlsiial
From: zls...@uts.mcc.ac.uk (A. V. Le Blanc)
Newsgroups: comp.os.linux
Subject: Shared libraries on root disk (Re: Linux installation .96a?)
Message-ID: <5188@mccuts.uts.mcc.ac.uk>
Date: 16 Jun 92 09:36:34 GMT
References: <3ndltdd.genie@netcom.com>
<1992Jun13.173914.24222@muddcs.claremont.edu>
<1992Jun15.231850.28347@nuchat.sccsi.com>
Organization: Computing Centre, University of Manchester
Lines: 84
In article <1992Jun15.2...@nuchat.sccsi.com>
ke...@nuchat.sccsi.com (Kevin Brown) writes:
>>It will use shared libraries (hopefully from the gcc
>>2.2.1 release) and not contain the horrid tar/compress from the 0.95a
>>root disk.
>
>This is probably a mistake. Having the root disk binaries depend on the
>shared libs will cause *everything* to break horribly if the shared
>libraries die for any reason. This will make the root disk unsafe for
>the purposes of restoring a crashed system.
I'm not certain what you mean by die. If the shared library is corrupt,
everything will of course fail, but this also happens if the boot disk
is corrupt, or if some crucial utility (e.g., /bin/sh) is corrupt.
Obviously you need to keep a backup copy of the disks. But Linux,
because it can boot from floppies, is not in a bad a condition as
most mainframes. I feel that both the floppy and the hard disk system
should make as much use of shared libraries as possible, and that
this makes it possible for an emergency floppy-resident recovery
system to be much more powerful.
>My opinion is this: the root disk distributed with the system should contain
>the minimum number of binaries necessary to get the system installed and
>running. Things like tar, compress, ash, ed (or some other very small editor,
>perhaps something like joe), pfdisk, mtools, etc., fall into the category of
>necessary tools. Things like vi, gcc, fdisk (since it doesn't function
>properly with all configurations), bash, etc., are unnecessary for
>installation of linux *if* you know what you're doing.
Many of us would probably be unhappy with your list in different ways.
I have the following problems:
(ash) I don't think ash should be included at all.
(ed) I don't think any root disk yet has included an editor. It's
a nice idea, but not necessary. I'd prefer to see ed or sed,
even though I am a joe fan.
(pfdisk, fdisk) I'd prefer to see a working fdisk designed for Linux.
I tried to write such a beast, and I'm trying to take into account
what people have reported. Have you reported all your problems?
(mtools) It seems to me the installation disk or whatever need not
contain mtools; it should simply be able to install a working
version on a hard disk, which would then be accessible.
(bash) The advantage of having bash on your installation disk is that
you wouldn't need to have two shells. The only other shells I
feel you could make a strong argument for are tcsh and perhaps
rc, but so many install/configure/makefile jobs require a fairly
standard /bin/sh that I think bash (or perhaps rc) is best.
>The space that is taken up by what spurious and unnecessary utilities that
>currently exist on the root disk can more effectively be used for
>documentation that will give the person installing the system a better
>understanding of what's going on and how to use the tools that have been
>made available to him. A rudimentary set of man pages on the root disk
>might be a better use of space (particularly since they can be compressed)
>than a few more utilities.
Several people have complained to me about the presence of documentation
on the standard root disks; they take up some space, and they are
inaccessible until you have the system booted and the disk mounted.
I have some sympathy with the idea of a set of simple man pages,
though it seems inconsistent with the earlier goal of having the
disk(s) designed with experts in mind. On the other hand, most
commands these days print a list of options if you type 'xname -xXzZ'
or something of the sort. And bash has the advantage of its 'help'
command, which gives details about each builtin.
>Mtools in particular should be on the root disk. The reason is that most
>of the people who install Linux will have DOS on their machines, and a good
>many of them will have various pieces of linux on their DOS partitions.
But if the root disk does not contain mtools, but gives you the ability
to install it elsewhere, surely this is better? It works and it takes
up less space.
> Kevin Brown
>
> ke...@nuchat.sccsi.com
> ke...@taronga.taronga.com
I don't intend to start a flame war, or even to say you are
necessarily wrong, but I would not like an unchallenged statement
to appear to have universal acceptance.
-- Owen
LeB...@mcc.ac.uk
Newsgroups: comp.os.linux
Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!
lobster!nuchat!kevin
From: ke...@nuchat.sccsi.com (Kevin Brown)
Subject: Re: Linux installation .96a?
Message-ID: <1992Jun16.194902.4013@nuchat.sccsi.com>
Organization: Teenage Mutant Ninja NiceGuys(tm)
References: <1992Jun13.173914.24222@muddcs.claremont.edu>
<1992Jun15.231850.28347@nuchat.sccsi.com>
<1992Jun16.044415.11348@muddcs.claremont.edu>
Date: Tue, 16 Jun 1992 19:49:02 GMT
Lines: 132
In article <1992Jun16.0...@muddcs.claremont.edu>
jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>In article <1992Jun15.2...@nuchat.sccsi.com>
>ke...@nuchat.sccsi.com (Kevin Brown) writes:
>>In article <1992Jun13.1...@muddcs.claremont.edu>
>>jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>>>It will use shared libraries (hopefully from the gcc
>>>2.2.1 release) and not contain the horrid tar/compress from the 0.95a
>>>root disk.
>>
>>This is probably a mistake. Having the root disk binaries depend on the
>>shared libs will cause *everything* to break horribly if the shared
>>libraries die for any reason. This will make the root disk unsafe for
>>the purposes of restoring a crashed system.
>
>Aigh! I wish I had a nickel for everyone that has tried to argue this
>case - that way I could afford to have someone repeat me. :)
>
>The root disk is completely self-contained. Whether it uses shared
>libraries or not is of no consequence - the binaries and libraries
>are *together* on the *same disk*.
I realize this. To me, it's a question of robustness. If you have all the
binaries in the system depend on the shared library file, then (as I said)
*everything* will break if the shared library file is damaged in any way.
That means that you'll have to drop back a level (possibly all the way back
to DOS) in order to recover from that mistake *alone*.
>Besides, who care if the root disk breaks? Remember that copy of the
>root image you saved? Write out a new image! Remember that backup of
>the root image? :) The root disk is first a foremost designed for
>the installation and repair of Linux systems - if it would work that
>way, I would recommend write protecting it. (Unfortunately, it
>wouldn't work - darn.)
Minix gives you the option of loading the root file system into a ramdisk.
It might be useful to give linux the ability to do the same. That way, if
you're in the process of attempting to recover from a crash, the only
damage you can do is to the image of the root file system in RAM. It also
means that you can have a real small root file system on your hard drive
that you don't use for anything but recovery. I do this all the time on
my Minix system (don't have Linux up yet because I'm waiting for my Bustek,
and weird things happen with my Seagate) and it works like a charm. Loading
the RAM image from the hard drive is much faster than loading it from
floppy.
As for breaking the root disk...while I agree that it's something you should
be able to recover from, it's enough of a pain to recover from that it should
be necessary only when major damage has been done to it. Removal of the
shared library file is *not* what I consider to be major damage. Damage to
the superblock is more in line with what I'm thinking of...
>>The benefits are clear, of course (more space on the root disk) but I
>>think the danger of having everything in the system depend on one file
>>easily outweighs any advantages of having more binaries on the root disk.
>
>It already depends on one file - rootimage-0.96.Z. :) The odds of
>that being corrupt are greater than that of lib-2.2.2 (or whatever),
>since it's bigger.
Except that it's pretty easy to accidentally remove the shared library
image from the file system (or to move it, or what have you). Or to damage
it.
You're constantly working with the shared lib file, and damage to it can happen
at any time. The same is not (or should not be) true for the root image.
The danger is much smaller to the root image, so the fact that you ultimately
depend on it isn't that big a deal.
>mtools also isn't necessary if you know what you're doing.
This is true, but at this point it's a question of convenience. I think that
having mtools on the root file system is a big enough win relative to a number
of other possible utilities that it's worth having.
It's a *real* pain to have to reboot the system every time you want to move
a file from DOS to Linux, when mtools would fix that problem.
>Um, should I try and fit 'man' on the disk, too? But that seems kind
>of spurious and of limited necessity. :)
If you arrange for the login message to tell you where to look for the
documentation for commands (/usr/man/cat1/<command>.1, for example), then
the man program is probably unnecessary.
In any case, the man program can easily be written as a shell script, assuming
you have the right tools (e.g., sed) on the disk, so it's not like it (in that
form) would take up any real space. The support tools would, though. You
could arrange the whatis database in such a way that the only tools you'd need
are grep and sed, though...
>Really, I think
>documentation should be seperate from the root disk - the idea is to
>pack maximum utility there so things can get done. How do people
>print out documentation under Linux if they aren't familiar with Linux?
Who needs to print the documentation out? You have multiple virtual consoles.
You bring up the documentation on one console with something like "more" and
do all your work in the other consoles. The login message should tell you how
to switch consoles.
>>Mtools in particular should be on the root disk. The reason is that most
>>of the people who install Linux will have DOS on their machines, and a good
>>many of them will have various pieces of linux on their DOS partitions.
>
>This discussion was had before the 0.95a root disk was released, and
>due to space constraints, mtools was not on that root disk. It will
>be on the 0.96 supplemental image at the very least, and the 0.96 root
>image if it fits. I have mixed feelings about mtools - it's handy,
>but is not absolutely necessary. (More of a luxury than a necessity,
>that is.)
Agreed. I happen to think that for most people, it's a big enough win to
warrant being included on the root disk, but your mileage may vary. One
of the primary reasons I think it's a win is that Linux combined with mtools
is a much better environment for messing around with DOS files than DOS
itself. :-)
>>Other than a few nits here and there, good work!
>
>Thanks, the kinds words let me fight the insanity back. :) I'm sorry
>if I sound harsh, but you caught me at a bad time with two familiar
>(and distasteful) issues.
Heh. No problem. I've been reading this group on and off for a while, but
I apparently missed the bulk of such discussion. Apologies for the redundancy.
> + Jim Winstead Jr. (CSci '95)
--
Kevin Brown
ke...@nuchat.sccsi.com
ke...@taronga.taronga.co
Path: sparky!uunet!spool.mu.edu!agate!boulder!ophelia.cs.colorado.edu!drew
From: dr...@ophelia.cs.colorado.edu (Drew Eckhardt)
Newsgroups: comp.os.linux
Subject: Re: Linux installation .96a?
Message-ID: <1992Jun17.025009.11975@colorado.edu>
Date: 17 Jun 92 02:50:09 GMT
Article-I.D.: colorado.1992Jun17.025009.11975
References: <1992Jun15.231850.28347@nuchat.sccsi.com>
<1992Jun16.044415.11348@muddcs.claremont.edu>
<1992Jun16.194902.4013@nuchat.sccsi.com>
Sender: ne...@colorado.edu (The Daily Planet)
Organization: University of Colorado at Boulder
Lines: 150
Nntp-Posting-Host: ophelia.cs.colorado.edu
In article <1992Jun16....@nuchat.sccsi.com>
ke...@nuchat.sccsi.com (Kevin Brown) writes:
>In article <1992Jun16.0...@muddcs.claremont.edu>
>jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>>In article <1992Jun15.2...@nuchat.sccsi.com>
>>ke...@nuchat.sccsi.com (Kevin Brown) writes:
>>>In article <1992Jun13.1...@muddcs.claremont.edu>
>>>jwin...@jarthur.claremont.edu (Jim Winstead Jr.) writes:
>>>>It will use shared libraries (hopefully from the gcc
>>>>2.2.1 release) and not contain the horrid tar/compress from the 0.95a
>>>>root disk.
>>>
>>>This is probably a mistake. Having the root disk binaries depend on the
>>>shared libs will cause *everything* to break horribly if the shared
>>>libraries die for any reason. This will make the root disk unsafe for
>>>the purposes of restoring a crashed system.
>>
>>Aigh! I wish I had a nickel for everyone that has tried to argue this
>>case - that way I could afford to have someone repeat me. :)
>>
>>The root disk is completely self-contained. Whether it uses shared
>>libraries or not is of no consequence - the binaries and libraries
>>are *together* on the *same disk*.
>
>I realize this. To me, it's a question of robustness. If you have all the
>binaries in the system depend on the shared library file, then (as I said)
>*everything* will break if the shared library file is damaged in any way.
>That means that you'll have to drop back a level (possibly all the way back
>to DOS) in order to recover from that mistake *alone*.
>
If /vmunix breaks on a normal system, everything breaks. If
init breaks and dumps core on Linux, you can't login in either single
or multi user mode. Without a way to overide multi-user mode,
if /etc/passwd is corrupted you won't be able to do anything either.
We already have files on the root file system that are just as critical
as a shared library would be. I don't see how one more file added
to this list will hurt much.
Shared libraries could give us enough
space to put a real shell, and some more documentation on the
distribution root file system. I'd rather have these added features,
and take the chance that something will go wrong.
>>Besides, who care if the root disk breaks? Remember that copy of the
>>root image you saved? Write out a new image! Remember that backup of
>>the root image? :) The root disk is first a foremost designed for
>>the installation and repair of Linux systems - if it would work that
>>way, I would recommend write protecting it. (Unfortunately, it
>>wouldn't work - darn.)
>
>Minix gives you the option of loading the root file system into a ramdisk.
>It might be useful to give linux the ability to do the same. That way, if
>you're in the process of attempting to recover from a crash, the only
>damage you can do is to the image of the root file system in RAM. It also
>means that you can have a real small root file system on your hard drive
>that you don't use for anything but recovery. I do this all the time on
>my Minix system (don't have Linux up yet because I'm waiting for my Bustek,
>and weird things happen with my Seagate) and it works like a charm. Loading
>the RAM image from the hard drive is much faster than loading it from
>floppy.
>
Most people can't spare the memory for a real RAM disk (loosing
a single megabyte in a 4M machine will mean that GCC starts paging
much sooner, which can reduce performance by orders of
magnitude) and no one has implemented a pageable MFS (ie, 4.3 Reno and later).
So, at this time, a root file system in memory is impractical.
>As for breaking the root disk...while I agree that it's something you should
>be able to recover from, it's enough of a pain to recover from that it should
>be necessary only when major damage has been done to it. Removal of the
>shared library file is *not* what I consider to be major damage. Damage to
>the superblock is more in line with what I'm thinking of...
Removing the shared library binary is a user mistake. If you are
diciplined, and follow some common sense (ie, don't log in as root
when you can log in as a normal user), this won't happen.
Corruption of the shared library binary itself is far less likely
than file system corruption, because the shared library is
not written to. Ruling out user mistakes,
the only thing that can cause a shared library failure is a disk failure.
>>>The benefits are clear, of course (more space on the root disk) but I
>>>think the danger of having everything in the system depend on one file
>>>easily outweighs any advantages of having more binaries on the root disk.
With a corrupt init, the kernel will not drop to single user mode,
gettys will not be spawned, and no one can log in. With a corrupt
/etc/passwd, you might not be able to log in. Linux already
depends on both of these files.
Maybe we should have the distribution system come up in single user mode?
This would prevent problems arising from init and passwd corruption,
as well as opening up more disk space.
>>It already depends on one file - rootimage-0.96.Z. :) The odds of
>>that being corrupt are greater than that of lib-2.2.2 (or whatever),
>>since it's bigger.
>
>Except that it's pretty easy to accidentally remove the shared library
>image from the file system (or to move it, or what have you). Or to damage
>it.
How can I remove or damage /lib/* as a normal user? Additional
safe guards can be added, such as aliasing rm to rm -i
in root's . files, etc.
>You're constantly working with the shared lib file, and damage to it can happen
>at any time. The same is not (or should not be) true for the root image.
>The danger is much smaller to the root image, so the fact that you ultimately
>depend on it isn't that big a deal.
When file system corruption occurs, it occurs during a write,
when not all of the necessary pieces of the file system get
sync'd to disk. You never write to the shared library binary,
so this won't happen. The only real danger to the shared library
is disk corruption, arising from a kernel bug, or the disk
developing bad blocks. Either of these can hit the super block,
or do other comprable dammage. Both will be very rare.
>>mtools also isn't necessary if you know what you're doing.
>
>This is true, but at this point it's a question of convenience. I think that
>having mtools on the root file system is a big enough win relative to a number
>of other possible utilities that it's worth having.
>
>It's a *real* pain to have to reboot the system every time you want to move
>a file from DOS to Linux, when mtools would fix that problem.
A better alternative would be to write a DOS file system under VFS, eliminating
the need for Mtools altogether.
>>Um, should I try and fit 'man' on the disk, too? But that seems kind
>>of spurious and of limited necessity. :)
>
>If you arrange for the login message to tell you where to look for the
>documentation for commands (/usr/man/cat1/<command>.1, for example), then
>the man program is probably unnecessary.
>
>In any case, the man program can easily be written as a shell script, assuming
>you have the right tools (e.g., sed) on the disk, so it's not like it (in that
>form) would take up any real space. The support tools would, though. You
>could arrange the whatis database in such a way that the only tools you'd need
>are grep and sed, though...
>
A step by step guide for setting the system up that you could view
in one virtual console, while commands run on another
could be nice.
<deleted>
Path: sparky!uunet!mcsun!uknet!mucs!mccuts!zlsiial
From: zls...@uts.mcc.ac.uk (A. V. Le Blanc)
Newsgroups: comp.os.linux
Subject: root disk contents (Re: Linux installation .96a?)
Message-ID: <5201@mccuts.uts.mcc.ac.uk>
Date: 18 Jun 92 10:23:01 GMT
References: <1992Jun15.231850.28347@nuchat.sccsi.com>
<5188@mccuts.uts.mcc.ac.uk> <1992Jun17.051935.19692@nuchat.sccsi.com>
<1992Jun16.044415.11348@muddcs.claremont.edu>
<1992Jun16.194902.4013@nuchat.sccsi.com> <1992Jun17.025009.11975@colorado.edu>
Followup-To: LeB...@mcc.ac.uk
Organization: Computing Centre, University of Manchester
Lines: 185
In article <1992Jun17.0...@colorado.edu>
dr...@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
>In article <1992Jun16....@nuchat.sccsi.com>
>ke...@nuchat.sccsi.com (Kevin Brown) writes:
>>Minix gives you the option of loading the root file system into a ramdisk.
>>It might be useful to give linux the ability to do the same.
>
>Most people can't spare the memory for a real RAM disk (loosing
>a single megabyte in a 4M machine will mean that GCC starts paging
>much sooner, which can reduce performance by orders of
>magnitude) and no one has implemented a pageable MFS (ie, 4.3 Reno and later).
>So, at this time, a root file system in memory is impractical.
Actually, Linux already has the ability to put a root file system on a
ramdisk, which is precisely how the latest MCC interim versions of Linux
work. This is, however, not a very good idea for ordinary use. The
ramdisk is not the most efficient way of using memory.
>Maybe we should have the distribution system come up in single user mode?
>This would prevent problems arising from init and passwd corruption,
>as well as opening up more disk space.
Again, this is what I did in the MCC stuff. init and login are too
much of a luxury to have on the installation disk, in my view.
In article <1992Jun17.0...@nuchat.sccsi.com> ke...@nuchat.sccsi.com (Kevin Brown) writes:
>Since the hard drive is what will be used in the everyday system, it makes
>much more sense to have the shared libraries there than on the root floppy.
>IMHO, of course.
This seems to be a misunderstanding. What I suggested, and what I did
in the latest MCC releases, is to have the shared libraries on the root
floppy, then copy them to the hard disk. This means the root and utilities
disk can use the shared libraries, and you can copy them from there to
the hard disk if the hard disk ones get corrupted.
>>(ash) I don't think ash should be included at all.
>
>Reasoning? If it is buggy, or if there is some shell (rc, perhaps) which has
>the basic functionality of a Bourne shell but is smaller than ash, then I would
>agree with your assessment.
>There is a difference between necessary functionality (e.g., handling
>the basic Bourne shell semantics right, which ash hopefully does) and
>extraneous functionality (e.g., command history and line editing). The
>shell on the root floppy needs as much of the former as it can get, and
>as little of the latter as it can get away with.
My reasoning was, and is, this: it is necessary to have one solid, Bourne
shell like, shell on a Linux system. Someone else has pointed out that
/etc/rc and other such files assume it, and I pointed out that many
configuration, compilation, and installation procedures assume it.
Ash is not adequate for these purposes. And if we have one Bourne-like
shell, it seems excessive to have two. If you use a ramdisk, as I did
in the last two MCC versions of Linux, you can fit an amazing amount
onto the mounted floppy.
In any case, ash does not get the basic Bourne shell semantics right
(unless your interpretation of 'basic' is more restricted than mine).
The line editing part of bash is not in fact very large; but when you
add job control and other features, the result is still larger than
rc.
>An editor is almost mandatory for customization purposes, at least in my
>experience. It doesn't need to be fancy (the only reason I suggested joe
>is that it's small, but ed will do just as well. Sed, while probably
>necessary for other things, probably won't work nearly as well as a
>general-purpose simple editor due to its design. Again, IMHO).
I agree with many of your points. Still installation from floppies
ought not to require an editor, at least if the configuration,
customisation, and installation is written properly. If you can get
a bootable system set up somehow, it doesn't really matter.
In my MCC versions, I had both mtools and sed (and elvis and joe) in
tar archives on the mounted floppy. This means that you can
(following the instructions) install them on a hard disk from the
floppy. I believe vi would still require symbolic links from /etc
to /root/etc (not described in the documentation) before it would
work properly, and joe as well, at least if you wanted interactive help.
Mtools requires an /etc/mtools file, but I still see no use for mtools
that could not be postponed until after you reboot. If it is absolutely
necessary, you could cat an /etc/mtools file (if you remember the format
correctly).
>>(pfdisk, fdisk) I'd prefer to see a working fdisk designed for Linux.
>> I tried to write such a beast, and I'm trying to take into account
>> what people have reported. Have you reported all your problems?
>
>The problems I had with it are the same as the problems everyone else had
>with it: it doesn't function *at all* with the SCSI driver.
>For installation purposes, tools like fdisk need to work with as generic a
>setup as possible, even setups that use some new hacked-in device driver.
I pointed out to Drew that, if fdisk is to work at all sensibly, it
MUST get the hard disk geometry, and this requires expanding the ioctl
call. You can in fact enter the geometry interactively, as described
in the README file. I was not terribly concerned about this, however,
since my boot disk contained no code for SCSI systems. I don't have
a SCSI system or access to a SCSI system. Moreover, noone wrote to me
to make ANY suggestions about making it work on a SCSI system.
I am a little puzzled by your assuming that 'everyone else' has a
SCSI system, but you seem a bit emotional on this point. Please don't
start a flame war; contribute code instead.
>Pfdisk, on the other hand, is designed to work with *any* block device, and
>so fits the general-purpose nature of installation tools...
Pfdisk, on the other hand, requires the user to know his own disk
geometry; moreover, it doesn't allow you to create extended partitions,
which fdisk does. Naturally, this means nothing to SCSI users, as the
current SCSI patches don't support extended partitions either.
>>Several people have complained to me about the presence of documentation
>>on the standard root disks; they take up some space, and they are
>>inaccessible until you have the system booted and the disk mounted.
>
>Right. But for bringing the system up, you have to get this far *anyway*.
>Everything past this is more or less optional. And it's at this point in
>time that you really have to know what you're doing, because it's at this
>point that you start configuring the system.
Not if the configuring utilities are properly written -- as pfdisk, for
example, is not. I don't claim that fdisk is properly written YET, but
I hope it's going in the right direction.
>It's *after* this point that things get interesting. It's where you have
>to prep your hard disks for the system (which varies depending on what kind
>of hard drive subsystem you have), copy the files, fix /etc/rc to do the
>right thing, change the boot disk's default boot device major and minor
>numbers, etc. These are the things that take some knowledge, and are where
>the online documentation really becomes useful.
I don't know what you mean by 'prepping' your drives. If /etc/rc is
properly written, it should allow you to boot up any basic system
with no changes; then you can edit it as you please. My system comes
up with a little note about creating a boot disk with the proper device.
>The problem, of course, is that if the disks are designed with experts in
>mind, only experts will be able to install the system without any problems.
>The end result is *a lot* of what you see here on the newsgroup: novices
>asking novice questions because there isn't enough there to tell them
>what's going on (particularly with respect to things like the SCSI
>installation).
On the other hand, I repeat, if the disks are properly designed with
novice users in mind, novice users should be able to install the system
without any problems. I would be delighted to have some information
about the SCSI installation so that I could make my own release easier
for SCSI owners to use, and I'm sure Jim feels the same about the
standard boot disk.
>>On the other hand, most
>>commands these days print a list of options if you type 'xname -xXzZ'
>>or something of the sort. And bash has the advantage of its 'help'
>>command, which gives details about each builtin.
>
>Except that for each of these, you have to know how to get at the help.
>A list of options generally isn't particularly useful unless you know
>what the options mean, and I guarantee that most novices (particularly
>those with no real Unix experience) won't.
I agree, but I still wonder whether it is practically possible to include
much in the way of man pages on the ROOT FLOPPY, which is what the
original discussion was about.
>>But if the root disk does not contain mtools, but gives you the ability
>>to install it elsewhere, surely this is better? It works and it takes
>>up less space.
>
>See above. This works only if what is on your DOS partition isn't itself
>necessary for installation. For instance, what if mtools is on your
>DOS partition?
In the case of my versions, DOS is competely unnecessary for installation.
Mtools is in a tar file on the utilities disk (which is the one mounted
at boot time; the root disk is on the boot disk). The installation
procedure uncompresses and untars the various mtools commands onto
the hard disk. As I said above, you should be able to use this if
you create an /etc/mtools file (using cat, for example).
Where we differ, we may simply agree to differ, but I would very much
like to have information about the SCSI installation so as to
accomodate it in the current MCC version. And I would be delighted
to recommend your version instead of mine when you come out with it!
-- Owen
LeB...@mcc.ac.uk