|
Grex > Micros > #199: FreeBSD, Linux, or other PC Unixes? |  |
|
| Author |
Message |
| 25 new of 257 responses total. |
gull
|
|
response 38 of 257:
| 
Feb 5 21:10 UTC 1999 |
> (1) Why was df showing that /var was at 109% capacity?
> Any ideas?
In BSD (and most UNIXes, in fact) there's a certain amount of space on
the filesystem that's reserved for the superuser. This is a sort of
'cushion' to help prevent users from taking down the system by filling up a
filesystem. What you were seeing is a truely full filesystem: all 100% of
the user space was full, plus the 9% of reserved space. The amount of
reserved space can often be adjusted when the filesystem is created, but
generally there's little reason to do this.
|
dang
|
|
response 39 of 257:
|
Feb 5 21:23 UTC 1999 |
re: /boot partition: You don't really need a /boot inside the 1024
limit. Rather, you can install LILO into the MBR, which is below the
1024 limit, and it will then load the kernel. The kerenl itself doesn't
need to be below 1024. (At least, not on any of the four computers that
I run, including a 486, a PI 90, a PPro 266, and a PII30) The only
problem with this is that installing Win9x or NT will delete lilo. (Win
erases the MBR) If you plan on reinstalling Win, keep a boot disk so you
can reinstall lilo.
|
drew
|
|
response 40 of 257:
|
Feb 5 21:27 UTC 1999 |
I have re-installed Win NT several times without the MBR (containing LILO)
being touched.
|
mwg
|
|
response 41 of 257:
|
Feb 5 22:06 UTC 1999 |
Re#39: I can state from firsthand experience that the partition to boot
from has to be entirely within the range that the BIOS of the computer for
the loader to work correctly. The kernel (according to some documentation
I found when researching the problem) is loaded into memory using the
BIOS, unpacked and run, at which point all the nifty protected mode Linux
stuff gets to run.
If you try to use a partition that goes outside of what the BIOS can
handle, your boot up get about to LI and then the speaker will lock on an
endless BEEEEEEEEEEEEEEEEEEE....... I had to rig up a boot disk for the
machine I found this out on. Since the hard disk is not accessed until
the kernel loads from floppy, it works OK even though the BIOS can't
handle the drive.
These days, it is not always the 1024 cylinder limit that is the problem,
a BIOS that can handle larger drives can still get drives too large to
see.
|
pfv
|
|
response 42 of 257:
|
Feb 6 05:49 UTC 1999 |
Had Slackware installed, once-upon-a-time..
Used LILO.
Upgraded the DOS/DOZE partition to win95..
*BZZZZZZZZZZZZZZZZZZZZZZZZTTTTT!!!!!!!!!!!*
Slackware, Lilo & Linux "Go bye-bye".
Lilo writes a bootstrap record to MBR that routes to the lilo
& "which one" compressed kernel.
M$ products couldn't care less wtf you've installed - they will
mangle whateverthehell they want to..
Moral of the story:
Create a Zdisk.. The result can find root and all else
after the MBR has been screwed, blued & tatooed.
Empirical Evidence that the Zdisk doesn't care to work following
creation & reboot: I couldn't boot from the floppy.
Empirical Evidence that the Zdisk DOES work after you give up in
frustration: I got peeved & went to bed - PowerOn the next day
booted precisely the kernel I'd compiled (2.1.1) from the
diskette.
|
scott
|
|
response 43 of 257:
|
Feb 6 12:20 UTC 1999 |
Right. I use System Commander at work for multi-boot. In the manual it warns
about all the evil things Win95 will do when installed. A really funny one
is that if you install MS "plus" (extensions to the Win95, I think all those
are now part of Win98) with default options, it will find any partitions that
exist and turn them into compressed Windows partitions (yup, it will find an
"empty" disk space occupied by non-MS software).
|
dang
|
|
response 44 of 257:
|
Feb 6 22:50 UTC 1999 |
Ouch. That's a bad one. I'm glad I've never used Plus.
|
gull
|
|
response 45 of 257:
|
Feb 8 01:52 UTC 1999 |
Windows also tends to corrupt the boot sectors of older DOS disks it reads.
Friend of mine lost some of his DOS 2.11 boot disks that way.
Linux's boot loader really isn't very smart. I much prefer FreeBSD's,
though it has its own problems. (You can't boot off anything but a primary
partition.) Its best feature is that it understands the filesystem; it
looks for the kernel by name, instead of having a disk location hard-coded
in. This means you don't have to re-install it every time you make a new
kernel, and you can boot any kernel file at will. To be fair, it can be
this smart because it doesn't have to be crammed into the MBR; it sits in
the boot section of the root partition. There's a small 'EasyBoot' loader
in the MBR, which just lets you change the active partition. This,
incidentally, is a neat trick and works with a lot of OS's other than
FreeBSD.
|
dang
|
|
response 46 of 257:
|
Feb 8 21:19 UTC 1999 |
Yes, but it requires a portion in the MBR. The good thing about LILO is
you can install it exclusively in the boot sector of your linux root
partition. Then, when Windows changes itself automatically to be the
boot OS, all you need to do is change the active partition, and you are
back to linux. You can't do that with FreeBSD. FreeBSD and Windows 9x,
in my experience, don't mix as well as Linux and Windows 9x.
|
mwg
|
|
response 47 of 257:
|
Feb 10 19:50 UTC 1999 |
Having been bit by Windows, I use the tactic of setting up Linux on the
first hard drive and putting Lilo in the superblock. Then if I install
something that changes the active partition, I can just change it back...
|
pfv
|
|
response 48 of 257:
|
Feb 11 14:03 UTC 1999 |
rrrhh?
You done lost me with "superblock"..
Best solution that I've had is to start with a small DOS partition
and then create the linux parts - with /boot being one of 'em..
Then, you keep the kernel/boot stuff in /boot and let lilo loose
on the MBR..
If 'Doze whacks the MBR, the only solution I've seen is to have
the bootable "zdisk" around.. I'm fairly sure I could get lilo
to retake the high-ground of the MBR, but <shrug> Not being in the
least concerned with win<pick-a-number>, I doubt it will ever be
an issue again..
Actually, my concerns anymore deal with RH over Debian/TL and
FreeBSD.. And, THAT particular donneybrook is going to get intense
this weekend.
|
toking
|
|
response 49 of 257:
|
Feb 11 15:45 UTC 1999 |
ARGHHHHHHH!!!!!
I discovered last night that while FreeBSD plays exceptionaly well with
others, if you try and make it amuse itself it curls into a little ball
and dies (taking your MBR with it)
AKA I tried to install FreeBSD as the only OS, spent several hours
waiting for it to do its thing...finally got to the part where it said
Exit Installation (blah blah blah) did the reboot thing...looked good, I
was getting excited, the POOF!! Black screen that says NO BOOTABLE
PARTITION had to reformat and reinstall Win 95 to get my HD working
right again (tried installing MS-DOS 5.0 and 6.2, neither of those fixed
it...went to DR-DOS, that missed as well...tried to use FreeDOS but
discovered I'd lost my disk-o-pkzip ...same fate for PsyTechDOS
horrible I tell you
|
pfv
|
|
response 50 of 257:
|
Feb 11 16:47 UTC 1999 |
Crap... That is Not A Good Thing (tm)
You realize, of course, that I did NOT want to hear this...
as I am currently trying to decide twixt FreeBsd, RH 5.2, Debian
and TL as my ONLY Operating System..
Goddamnit... This Bodes Not Well at all.. *sigh*
Well, maybe if I use FIPS and shrink down the DOS partition to the
minimal for Dos 6.0... crapdoodle.. I wanna' be m$ free.
I would point out, to those that ain't experienced it, that trying
to get any sorta' older DOS installed from any of the win9x crap
is a total wash.. And, for the love of Bog - make sure you have a
bootdisk with that old DOS that WORKS before suffering m$ any
further..
|
toking
|
|
response 51 of 257:
|
Feb 11 17:44 UTC 1999 |
resp:50
try
http://www.FreeDOS.org
|
pfv
|
|
response 52 of 257:
|
Feb 11 17:46 UTC 1999 |
Yeah, I recall seeing it long ago and hearing of it..
I have no clue how it is doing, let alone how it "plays well with
others". Certainly win95/98 does NOT play well.
|
toking
|
|
response 53 of 257:
|
Feb 11 18:00 UTC 1999 |
it's probably worth a shot for a minimal DOS, and it's not M$
|
drew
|
|
response 54 of 257:
|
Feb 11 20:45 UTC 1999 |
Is this Win 95/98 specifically that trashes the MBR? I ended up re-installing
the main Windows NT 4.0 partition (attempt to do an XCOPY from CD while in
the auxiliary NT system resulted in BSODs and an invisible system); but the
LILO in the MBR is *still* intact.
|
mwg
|
|
response 55 of 257:
|
Feb 11 21:48 UTC 1999 |
Re: Superblock - One of the Unix types can probably give a much more
detailed answer, but from what I can tell, the superblock of a Unix-type
file system contains some vital bits of information, like fs type, some
inode information, and a few other things I haven't a clear picture of
yet. In the Linux superblock, it is possible to store a copy of LILO, the
Linux Loader, such that if the computer attempts to boot the Linux
partition, LILO gets run. LILO can be told to do several things based on
stored settings and optional interruption and input. It is possible (I do
this) to set the Linux partition as the active bootable partition, and
still boot to DOS by default if you don't interrupt the boot process.
By keeping LILO out of the MBR, I can avoid the problem of an OS trashing
my ability to boot, although I still keep two backup boot disks, just in
case.
|
dang
|
|
response 56 of 257:
|
Feb 12 03:24 UTC 1999 |
The superblock is just the first block of a partition. If there is
nothing in the MBR, such as if you've just gotten a new hard drive or
just installed windows, then the BIOS runs the program in the first
block (read superblock) the the partition marked active. It has the
same kind of space restrictions as the MBR, almost. If the BIOS is
running it, it needs to be withing BIOS addressable space, which is 1024
if you have a brain-dead BIOS. (If so, upgradeing your BIOS will almost
certainly cure it.)
Re: FreeBSD screw-up: I run FreeBSD as the only OS on my computer at
work, and I've installed any number of times, with no problem. From
what you've said, it sounds like no partition was marked as active,
and/or you didn't install the FreeBSD Bootloader. That's optional.
|
mdw
|
|
response 57 of 257:
|
Feb 12 03:47 UTC 1999 |
The superblock is a block near the start of the filesystem that
describes the organization of that filesystem. It includes a magic
number (to say it's a so-so type of filesystem), and various parameters
that the filesystem uses to locate the other data structures on that
filesystem, such as the inode table, free block bitmaps, etc. The
superblock is usually *not* block 0, because block 0 is reserved for the
boot logic. In edition 7 Unix (ca. 1979 technology), the boot block was
512 bytes, and the superblock started in block 1 (blocks then being 512
bytes). In the berkeley filesystem (ca. 1984), multiple copies of the
superblock are written to disk, scattered onto different cylinders of
the disk. This makes it slightly easier to recover from certain kinds
of disk catastrophes (like something that trashes the "real" superblock
at the start of the disk.) 512 bytes is plenty of space for a really
dumb optimized boot strap module in pdp-11 assembler, that is just smart
enough to load "/boot" from the same disk and filesystem. In the
berkeley fast filesystem (variants of which are used in SunOS 4 and
386bsd), 8192 bytes of space at the start of the filesystem are reserved
for boot logic. 8192 bytes makes it easier to port this logic to new
systems, and makes it possible to write the logic in C on many systems.
This logic is "in addition" to the logic in the MBR on 386 systems;
generally, the MBR would invoke the boot block which would load /boot
which would load /vmunix (or /bsd or whatever the kernel is called on
your system). In SunOS, the boot block has the locations of /boot
written into it; a program named "installboot" must be run in order to
write the locations of /boot into the boot block logic.
|
pfv
|
|
response 58 of 257:
|
Feb 12 05:40 UTC 1999 |
Somehow, I think we're talking the same thing w/ different
nomenclature..
yeah, the MBR is supposed to vector the bios to the /boot
partition and it's loading whatever the heck lilo creates from all
the assorted kernels you save as well as other OS's you care to
run.. I'd bet it's a chunk of lilo and either the actual kernel
or a chunk of what HAD been used to load DOS or Doze..
Near as I can tell now, the old slackware system that got
codwalloped was entirely due to my being a total neophyte to
building kernels and writing a zdisk/bootdiskette.. Because I
hadn't prepared said floppy, 95 got away with hammering me and I
had no idea how to get access to either /boot or / - thus ended
a brief flirtation with slackware..
Additionally, having been fried by 95 before, I am not at all
anxious to tempt the fates ever again.. There isn't anything for
Doze I can't live without or substitute something related.
|
toking
|
|
response 59 of 257:
|
Feb 12 17:45 UTC 1999 |
resp:56 well, when I was trying to install freebsd as a second OS I kept
selecting to have the boot manager thing installed, but I'd assumed that
with it being the only system on the HD I could get away with the second
option (standard boot record)
|
mwg
|
|
response 60 of 257:
|
Feb 13 20:13 UTC 1999 |
Re#57: If all else fails, you can boot with your original slackware setup
disks, mount your Linux partitions on the RamDisk file system, then re-run
lilo at the bash prompt, which should regenerate your LILO MBR. (Unless
something has trashed /etc/lilo.conf.) Then issue a shutdown command and
see what happens.
|
mwg
|
|
response 61 of 257:
|
Feb 13 20:14 UTC 1999 |
Frack! I meant #58.
|
dang
|
|
response 62 of 257:
|
Feb 13 22:30 UTC 1999 |
resp:59 No, that won't work. That only works if you have another
intelligent boot loader (such as NT or OS2) already running that you a)
don't want to trash and b) can configure to run FreeBSD. If FreeBSD is
alone, you have to install the bootloader from it, or nothing will boot.
|