Date: Tue, 29 Oct 1996 22:52:42 -0800 (PST) From: Doug White <dwhite@gdi.uoregon.edu> To: John Diedrichs <johnd@pristine.com.tw> Cc: questions@freebsd.org Subject: Re: Installation Woes... Message-ID: <Pine.BSI.3.94.961029223321.369Z-100000@gdi.uoregon.edu> In-Reply-To: <199610281053.SAA25151@neptune.pristine.com.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Oct 1996, John Diedrichs wrote:
> ** Note: this message is bound to be long! This is because I'm trying to
> provide you with as much useful detail as possible. I'll try to keep idle
> chit-chat to a minimum, but I'm writing "off-the-cuff", so it may be a bit
> disjointed. My apologies...
That's to say the least :-) It takes up 5 of my 80x56 xterm windows.
> 1. No CD-ROM:
>
> Although Linux CDs are available here (in Taiwan) in all flavors and sizes,
> FreeBSD is simply not to be found, other than on a couple of mirror sites.
> No problem, I just took my Iomega ZIP drive to the office and downloaded
> bin, X, dict, and a few other dist's onto it and then copied all onto my DOS
> partition.
This install may have been better done if installed from a DOS partition
instead of floppies. The procedure for floppy installs from 2.1.5-RELEASE
was not very good, but the DOS instructions are great. If you have a DOS
primary partition then by all means use it.
> I made one mistake in this process, for which I paid dearly in wasted time:
> I neglected to copy the "install.sh" file for the bin dist. I'm a bit
> embarrassed to say that it took several dozen trips through the install
> program to catch that one!
The other one that will bite you is the *.inf files.
> subdirectory on the floppy, e.g.: a:\bin\bin.aa, a:\bin\bin.ab, ..."
>
> Notice, it doesn't say anything in here about the "install.sh" file!!
And bin.inf. The docs are for 2.1.0, sadly. install.sh should go on the
last disk, although it doesn't really matter.
> The point here is that it seems to me that the installation process is
> geared toward a CD installation. I've never tried the CD install, but
> judging from several bits in the docs (eg: "For example, to do a minimal
> installation of FreeBSD from DOS using files copied from the CDROM, you
> might...") I get the idea that one is expected to have the CD, rather than
> downloading files from the Internet.
The order of install preferences are:
1. CDROM
2. DOS
3. FTP (upgrade if you are on a LAN with a supported ethernet card and
direct access to either the Internet or an ftp server with the FreeBSD
distribution on it)
> 2. Documentation of features:
>
> a. Virtual TTYs:
>
> After a *lot* of attempts, I finally discovered the virtual ttys in the
> install program. This was the source of a lot of the debugging info you'll
> find later in this message. This feature does not seem to be documented
> anywhere. I've just done a text-search for "virtual", "tty" and "vty" on
> install.txt, hardware.txt, and readme.txt, and came up blank.
There is a note printed at the bottom of the screen during several phases
of the install, something like "Press Alt-F2 for the debug console".
> There are a couple of points in the install program where a message is
> diplayed saying something like "you might wish to look at the debugging info
> with scroll-lock on VTY1". But that is not explained either. I had to
> figure it out via trial and error.
Er. Bad assumption, bad bad assumption! (the novice install may have
mentioned this, I've never done it so ??)
> In a future release of the install program, you might even think about
> including a "write" feature to copy such info to a text file. It would save
> people like me the trouble of copying everything down by hand. (I reckon
> there might be some way to "snoop" the info via the shell prompt on ttyv3,
> but this is beyond my ken.)
The docs are also in the various CAPITAL files on the top level of the
RELEASE directory.
> b. Editing:
That is true. What does this have to do with 'editing'? :)
> 3. Partitioning above 512MB:
>
> This may be just a superstitious hunch on my part, but I get the idea that
> FreeBSD (in the install mode, at least) may have some trouble mounting
> partitions that straddle the 512MB boundary. In particular, the swap
> partition seemed sensitive to this.
It *will* thanks to legacy BIOS booters. It is a BIOS limitation and
there is nothing FreeBSD can do to fix it at this stage. Swap shouldn't
but the root partition ('a') IS.
Make sure that the 'b' partition is labeled as swap and not a filesystem.
> In any case, as I recall, the docs say only that the "boot" partition must
> *start* before 512MB, due to a limitation in the PC BIOS.
Correct.
> The "install.txt" notes on floppy installation (quoted above) say only that
> the various "splits" of bin.tgz (ie: bin.aa, bin.ab...) have to be copied to
> a "bin" directory on the floppies. However, when I try a floppy install, it
> fails as soon as the prefatory steps (fsck, holographic shell, etc.) are done.
With what error?
>
> Looking at the messages on ttyv1 (Alt+F2) shows that the program is looking
> for "/dist/bin/bin.tgz from fd1 on /dist" (or something like that, I didn't
> bother to write it down). It tries twice, looking for both bin.tgz and
> bin.inf, (total of 4 attempts) and fails on all.
bin.inf will screw you up. The failures on bin.tgz are perfectly OK; it
is sysinstall's way of figuring out just what installation method you are
really using. Make sure bin.inf is on the first disk.
> At that time, I found that the server names listed under the FTP items of
> the Media section are not entirely up to date. Specifically
> ftp.tw.freebsd.org (the fastest such site in my "neighborhood") has its
> files stored under a directory called "OS/FreeBSD/2.1.5-RELEASE". It
> required several tries with varying permutations of the "Release" field in
> "Options" and also of the site name itself to get the thing to work at all.
They may have changed it since August.
> Once it started, it worked great -- downloaded at several hundred Kbps/sec.
> But here again, the documentation could have been a bit more explicit. (As
> I recall, I eventually used the IP address as a URL in the "other" field:
> ftp://140.111.1.10/OS -- or something like that.)
Right. You shouldn't have needed the IP address if your network
connection was properly configured.
> Every time I tried, however, I got a message something like this:
>
> mount /dev/wd0s1 /mnt: /usr/sbin/mount_msdos: no such file or directory
The fixit floppy does not support mounting MSDOS filesystems it appears.
> The file structure in "fixit" mode is not exactly "standard". I gather that
> this is necessary in order to make the thing works from the install program.
> But there is almost no documentation of the fixit mode. Perhaps an
> explanation of how this works could be included in an upcoming release?
> (For instance, why do many files show up with the same *huge* size? If I
> mount a file system in fixit, will it still be available when I "exit" back
> to the install GUI?)
The fixit floppy is supposed to be enough for you to fix your partitions
then mount them.
> Often, I'd reach a dead-end in a "fixit" session and just "exit" back to
> install, and quit. Occasionally, however, the next time through I'd be
> unable to mount the fixit floppy, and would have to make a new one, then
> start all over again. Couldn't an "fsck -y" option be added to the fixit
> startup?
Odd. The fixit floppy can get 'dirty'? You shoudln't be able to 'exit'
back to sysinstall; you should just shutdown the system from the disk.
> I've noticed that if an install fails (eg: because the "bin dist" was not
> found) then I can't just go back to the "Media" section and change a few
> parameters. If I try this, the install program *immediately* says it can't
> find the bin dist, without even trying. Even to change just one parameter,
> I have to start the entire install over from a reboot. Of course, this
> means several minutes for each reboot (going into "-c" mode to select the
> right hardware devices), instead of a few seconds just to change a value
> somewhere. (I noticed this particularly often in the FTP install option.)
*never* repeat failed installs. They are doomed to failure. Delete and
start over.
> It has been my experience (again, not well documented) that no matter what
> option I choose in the "Partition" section of the install program, the first
> HDD (wd0 or sd0) will have its master boot record over-written. Even when I
> choose "Leave MBR untouched", it still happens.
Odd. I've heard of this but it really shouln't do anything.
> I don't wholly discount the possibility that I made a mistake somewhere; but
> I doubt I would have made the same mistake several times (on two different
> systems) unless there was a serious flaw, at least in the documentation.
>
> "Once bitten, twice shy," I was always *extremely*careful* in the partition
> option after the first time, but it still burned me a couple more times.
> I'm quite certain that it disobeyed my direct instruction to "leave the MBR
> untouched" at least twice. Not good!
Use one of your functioning FreeBSd boxes and run 'send-pr' and file a bug
report.
> On those occasions when I've tried installing the "X-User" distribution,
> I've noticed that the install program first unpacks X, dict, and doc
> *before* it starts looking for (and crashing upon) bin. This seems like a
> funny way to run a railroad! ;-)
NEver done that. I always use Custom, mainly because I'm used to
sysinstall and I like being very specific about what's installed.
> Okay, that's all that comes to mind about general problems with the
> installation program. I hope that the above information will prove useful
> in your continuing efforts to maintain a superior operating system.
Screaming in here is good; filing pr's is better since it forces people to
take notice :)
> 2. I put an "install.sh" file in my /dos/freebsd/bin directory, and the
> installation cruises right through the unpacking process right up to a file
> called "HB" somewhere in the depths of the "groff" structure. At this
> point, I find the following info in VTY1:
>
> gunzip: stdin: unexpected end of file
> /stand/cpio: premature end of file
> DEBUG: switching back to VTY1
> awk: cmd. line: 2: for (i = 0; i < 32 i++) {
> awk: cmd. line: 2: ^syntax error
> awk: cmd. line: 2: for (i = 0; i < n; i++) {
> awk: cmd. line: 2: ^syntax error
>
> Switching back to the install program GUI (Alt+F1) I see that the program is
> stuck on the following information dialog: "Fixing Permissions". At this
> point, I have to reboot with a "cold" reset.
If you can get this to repeat then file a pr.
> Both the "install.sh" method and the "bin.tgz" method work up to a point.
> But both methods crash before finishing the unpacking of "bin".
You are having no luck with bin. Perhaps it's corrupted?
> 3. I've also tried running the "tar" command from my existing command
> prompt. First, I chdir to the appropriate directory (either
> /dos/freebsd/bin or /FreeBSD/bin) and run either "cat bin.?? | tar --unlink
> -xpzf - -C /" or "tar --unlink -xpzf bin.tgz -C /". In every case, I get
> the same message as above ("unexpected EOF") except for one time when I got
> the following:
Wow, that shouldn't panic. It didn't like you one bit.
> Seeing this, I suspected a problem in memory. I recently upgraded from 32MB
> to 64MB; and though I tested both new SIMMs thoroughly with QEFA, I pulled
> 'em anyway and tried again. After that, I had a couple more instances of
> the "tar" command stalling on "HB", as above.
I don't know of any HB file.
> 4. As mentioned above, I've got a working kernel, which I copied from a
> machine at the office, and most of the "bin" dist already un-tarred onto my
> system. It almost works. When I boot this kernel, it goes multi-user and
> lets me log in as root, but it can't find a working "terminal type". It
> keeps prompting for the term type, and I've tried various permutations of
> "cons25", "vt100" and such, but the only thing that works is just to hit
> Ctrl+C, which dumps me into an "uncooked" console prompt.
Sounds like the termcap database wasn't extracted properly. Probably a
by-product of your bin problems.
> I suspect that there's a problem in the actual binary files I downloaded
> from ftp.tw.freebsd.org, however, I'd like a second opinion from the
> "experts" on this.
Perhaps. You might try fresh files from ftp.freebsd.org and see if that
helps. Also compare the file sizes of the bin.* components -- they should
all be alike except the last one.
Hope this lengthy reply helps your lenghty message. :)
Doug White | University of Oregon
Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant
http://gladstone.uoregon.edu/~dwhite | Computer Science Major
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.961029223321.369Z-100000>