On Thu, Aug 13, 2009 at 03:58:33PM -0400, PJ wrote:
> Roland Smith wrote:
> > On Thu, Aug 13, 2009 at 09:53:06AM -0400, PJ wrote:
> >   
> >> I apologize for the lengthy explanation below, but perhaps it will give
> >> some insight on what is see from this end:
> >>
> >> Ok, I've had all night to (subliminally) think about all this and
> >> actually, I am tending more toward problems in FreeBSD... (this is not
> >> an apology or a defense of my lack of knowledge or capacities, just a
> >> clarification so you know what kind of a dummy you're dealing with)
> >> First, let me explain that everything that we have been talking about -
> >> the recovery methods, installation, hardware problems, etc. are all
> >> extremely, and I mean extremely, subject to an awful lot of variables.
> >>     
> >
> > I don't understand?
> >
> > I must confess that I find your explanations sometimes a bit vague. You're
> > sitting in front of the machine with the problems. We (on the mailing list)
> > see only what you say. It is difficult for me at least to piece together 
> > what
> > exactly happened.
> >
> > If you are reporting errors, try to be as specific as possible. E.g. don't 
> > say
> > "I updated the machine and it doesn't boot anymore". Start with something 
> > like:
> > "After running freebsd-update with the options blabla" or "after updating 
> > the
> > machine from the 7.2 CD making the following choices...". And then say "I 
> > got
> > stuck in the FreeBSD logo screen", or "I got stuck on a screen showing the
> > lines 'Default: 0:ad(0,a)/boot/loader' and 'boot:'". That gives us at
> > least a chance to see what has gone wrong.
> >
> > I must say that I have never used the method of updating from CD. I tend to
> > update the system sources with csup(8), and then rebuild the kernel and
> > applications from source as explained in the Handbook. This hase never 
> > failed
> > me yet.
> >
> >   
> 1. Reporting the errors is a little difficult because more often than
> not, the errors fly by too fast to be fully understandable.

Error messages that have happened after the kernel has booted are still saved
inside the kernel message buffer. With the 'dmesg' command you can have a good
look at them.

Additionally, a snapshot of this message buffer is written to
/var/run/dmesg.boot after the filesystems are mounted.

> 2. I usually and never (since way, way back) do not update from a CD,
> except to boot up; I do the rest over ftp from the main source at
> freebsd.org. and I use cvsup-without-gui. :-)

I got the impression from one of your previous mails that you tried updating
from CD.

> > Insert a USB thumbdrive and mount it. Copy the files to it, unmount. The
> > GENERIC kernel on the CD should have all the necessary drivers for this to 
> > work.
> > Assuming that you're logged in as root, and that your USB drive is 
> > recognized
> > as /dev/da0s1:
> >
> > mkdir /usbdrive
> > mount_msdosfs -m 644 -M 755 -l -o noatime -o sync /dev/da0s1 /usbdrive
> > # copy the files you need...
> > umount /usbdrive
> >   
> I'll try that; oddly, I was able to use my SanDisk 4gb cruzer before.
> Chuck it into usb, mount /dev/cd0 to /mnt and go to it. But now, for
> some strange reason it just wont mount. I'm getting messages that it's
> not readable - "g_vfs_done input output error" and attempt to query
> device size failed, medium may have changed. But the stick is fully
> insertable, readable, removable from XP; as it was on FBSD. Weird.

You shouldn't be using the /dev/cd0 device. It is a virtual CD and should be
> > I don't understand what you mean by that? What do you mean by "doesn't act 
> > the
> > same"? 
> >   
> When turning on the computer, hit del and the bios setup comes on almost
> immediately on the 3ghz machine. On the 2.4 machine it takes much, much
> longer to start up (the monitor is Hitachi superScan Elite 812 on the
> 3ghz machine, hitachi CM751 on the 2.4ghz) and when del is pressed the
> bios goes through the entire scanniing process and then restarts before
> finally going into the bios... and the versions of the bios and the
> setup are both identical in nubers but, if I recall correctly, there are
> some minor differences in some of the more arcane options that I never
> even look at. And in general it always ran a bit sluggish.

If the battery keeping the CMOS memory of the 2.4ghz machine has run out, the
bios won remember its settings and e.g. has to scan for harddisks etc.

And settings like boot sequence, memory timing etc. can have a lot of
influence on boot time.

> > I don't want to be rude, but you could have made a mistake somewhere. If
> > you're futzing around with disks and partitions it is quite easy to screw
> > something up. Even for people with lots of experience it is sometimes a case
> > of PEBKAC. :-)
> >
> >   
> I understand what you are saying and I don't take it to be rude at
> all... actually, I don't screw around with the disks and the
> partitions... I only try to read them to recover any files I may have
> lost. So far, I have had 100% success on recovering lost data that was
> important.
> Up to now, when I had problems with crashes, I just reinstalled
> everything, the OS, the programs loaded up the files that were recoverd
> and whoopie... keep on chugging along. I did exactly that on this last
> great effort - actually, it took a great deal of patience and
> application to install the 64bit FBSD with flashplugin on the portable
> and it took extreme patience to wait for all the updates and upgrades
> and the searching and figuring out just how to configure and set up the
> i386 on the 2.4ghz machine - and it all worked beautifully; 

This is _exactly_ why you need good backups. So that you don't have to reinstall
everything again if something goes wrong. Blindly reinstalling is a windows

For your systems that are running well, get an external harddisk that is at
least as big as the one in the machine. On my website I have explained how to
prepare this disk in somewhat greater detail:

Then use the dump(8) command to make
backups of the internal harddisk partitions and write them to the external
harddisk. Say that you have mounted the external harddisk at /mnt/backups. The
following command makes a backup of the entire root partition, and compresses
it to save space:

        dump -0 -a -C 8 -L -u -f - / |gzip -1 >/mnt/backups/root-20090813.gz

If you have /usr, /var or /home set up as seperate partitions (which is a good
idea), make dumps of those in the same way. Make new dumps regularly, so you
don't loose too much data if you have to restore a broken system. You can use
the restore(8) program to restore individual files or up to the whole nine
yards from the backup.

> I was really
> happy that my ordeal was over and now I could get on with it. Not a nice
> way to wake up in the morning with the box sputtering out ...
> No, do not "futz around" - I have been doing my updates with portupgrade
> - compilin the ports is long and terribly boring - that's usually when I
> can write long e-mails ;-)  and now I'm trying portmaster - but it is
> giving me a bit of heartburn - it seems to stumble over itself - the
> updates dont work too well. It seems, that when the updates span several
> releases, portmaster does not know what it's doing - I caught it
> upgrading to an older version when it aborted; and the dependencies seem
> to suffer from the same kind of behavious. 

If you are switching between major versions of FreeBSD (like from 6.x->7.2),
the upgrade tools like portmaster and portupgrade don't always work perfectly,
for technical reasons that I won't go in to. The only foolproof method in that
case is to delete all ports and reinstall them.

For normal port updates, even between minor versions of FreeBSD it works very
well, _provided_ that you read /usr/ports/UPDATING and follow any special
instructions given there pertaining to ports that you use. Ignore those at
your peril.

> Make deinstall, make reinstall seems to be the best way... and then sit
> there and watch the screen expecting to suddenly have the compiling be
> interrruptted by the configuration scree. And that is often a pain... there
> are so many options that mostly have no direct meaning for me of use, for
> that matter. For example, ghostscript - do I really need it? I'm only using
> 1 printer and that is a postscript Xerox Phaser 8200 that has no driver in
> the ghostscript files.

Being a postscript printer it doesn't need a ghostscript driver... But
ghostscript is required by CUPS (the cups-base port, to be precise). Among
other things to convert PDF to postscript. Note that you can configure
cups-base not to use ghostscript.

> And the same for gutenberg... and other
> dependencies - I suppose that some are needed for various
> implementations of different programs that call them... but that should
> really be default settings. And who uses the the new ipv6 stuff?

Nobody is forcing you to change them. You can use portmaster's -G option to
prevent 'make config' from running.

R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)

Attachment: pgphSWHUAltet.pgp
Description: PGP signature

Reply via email to