AARRRRGH!!! (was RE: Linux Install error)

[gaf at blu.org (Jerry Feldman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 18 Dec 2003 08:41:14 -0500
"Don Levey" <lug at the-leveys.us> wrote:

> Well, I think I found the problem.
> I thought I had it, but found things were getting very slow.  Trying
> to get a root login at the console showed me massive numbers of I/O
> errors on hdb. When I installed this last time, I had accepted the
> formatting already on the disk in the hopes of bypassing the previous
> problems; I tried to reinstall formatting everything from scratch. 
> Same errors.  When I rebooted(warm or cold) the BIOS gave me a SMART
> error indicating that drive failure was imminent.  I'm arranging for
> an exchange now; hopefully that is the cause of all the problems.
That could be it. Also, you will be better off when you have the 2 disks
as masters on separate IDE channels. It appears that you have a
master/slave (Note that in California, it is now illegal to use those
terms). 

> I was using a boot partition, not because of the 1024-block problem,
> but because I had been told that the /boot partition must be on the
> same physical drive as the MBR.  I've been able to do an XP/RH9 dual
> boot on my wife's laptop without issue, but that's one drive only.
Not true. It does not hurt, but I tend to prefer them being on the same
drive. Normally the way I like to partition a system:
1. / partition
2. (swap) - you can have multiple swap partitions.
3. /home - you don't want to clobber this when installing a new release.
4. /usr/local - same reason as /home
Optionally, /var - the /var file system is a very active system with
logs and spools. On many commercial systems, /var is separate because of
backup strategies. Also, /tmp, /var/tmp, /var/spool are all on separate
file systems on many large systems, but I don't recommend this on most
smaller installations. as I mentioned, I never allocate a separate
/boot. While the separate /boot can be unmounted except when installing
a new kernel, the argument regarding corruption, while valid, IMHO, is
not a very strong argument.  
- -- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/4bqK+wA+1cUGHqkRAi4/AJ4t7+b2JMg47T+bAtfR9EVYEhOsZACfbVTM
gYFnUF4IP4uiPZow7aYhx+Y=
=0Pl5
-----END PGP SIGNATURE-----