Making world but no kernel

[Jeremy Chadwick]

On Tue, Jul 26, 2011 at 01:04:04PM +0200, Jerome Herman wrote:
> I would like to know if it is possible to rebuild world, but without
> upgrading or even compiling the kernel.
> 
> The problem is such : I am presently working on a FreeBSD station
> that seems to have quite a lot of problem, notably with fsck. I am
> starting to wonder whether this BSD station was properly installed,
> or if some of the system tools were pasted from older FreeBSD setup.
> Since the machine is in a remote location, I would prefer to avoid
> full reinstall if possible. Among other things, single user mode is
> not available.
> 
> So I was wondering, if I get the full sources with sysinstall, can I
> make buildworld and then installworld without going through the
> kernel phase or would this be a bad idea ?

Is it possible?  Yes.  Is it a bad idea?  Generally yes.  World and
kernel effectively need to be "in sync"; some kernel binary structures
(particularly for things like libkvm) need to be what userland binaries
expect them to be.  Nobody will be able to provide any support for this
configuration.

If you're trying to do things ""in phases"" because of this "fsck
problem" (see below for more on that), then please be sure that after
you rebuild world and reinstall world, that you DO NOT empty out
/usr/obj before rebuilding kernel/reinstalling kernel.  The kernel build
does refer to things in /usr/obj which were built as a result of
buildworld.

All that said: can we please get some deeper insight as to this
"problems with fsck" you're referring to?  I'm of the strong opinion
that it's better to try and solve the root cause of an issue than do
"hackish stuff" like the above (though it's not that hackish, you get
what I mean I hope).  I don't understand how fsck would cause you a
problem unless the machine is constantly losing power or has serious
issues with its storage.

Are you sure the problem, for example, isn't with the underlying storage
device (disk)?  If you aren't sure, would you like to verify that's
not the problem piece?  If so, please post some details like:

* dmesg
* Contents of /etc/fstab
* sysctl kern.disks

If the disks are backed by ata(4):

* atacontrol list
* atacontrol cap XXX   (where XXX = each disk shown in kern.disks)

If the disks are backed by ada(4) or are SCSI (da(4)):

* camcontrol devlist
* For ada(4) disks only: camcontrol identify XXX
* For da(4) disks only:  camcontrol inquiry XXX

And regardless of if ata(4), ada(4), or da(4):

* smartctl -a /dev/XXX (where XXX = each disk shown in kern.disks; this
  will require you install ports/sysutils/smartmontools first)

I can assist with the disk analysis portion in particular.

And with regards to smartctl, please try to ensure the output doesn't
get munged (forced line wrapping, newlines injected, etc.).  It makes it
more difficult to read.  Put the output up on the web if you're worried
about this.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |