On 26/07/2011 13:44, Jeremy Chadwick wrote:
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.
I think kernel and world are already out of sync. This machine is a
pre-installed BSD from an ISP, and I have no clues as to how it was
done. But I suspect that world was not built or rebuilt properly.
I of course got the sources that matches my kernel, and plan to
reinstall world just to make sure it is in sync with kernel.
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.
Yes I know the entire compilation chain is in /usr/obj for make kernel.
So I won't touch it until I can see clearer on this box.
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.
Neither one, nor the other. I have a gvinum setup for data disks. After
a forced reboot due to power failure, the box would not come up. Booting
into rescue drive I realized that it refused to boot because it could
not mount the data partition (/dev/gvinum/data), and this in turn
because fsck would not work on the said partition.
So I turned off daemons, removed /dev/gvinum/data from fstab and booted
again.
No problems.
Tried to fsck /dev/gvinum/data and got
fsck: Could not determine filesystem type
fsck_ufs /dev/gvinum/data got stuck on phase 1 for 8 hours before I
hard-canceled it.
trying to mount the drive resulted in
mount: /dev/gvinum/data : Operation not permitted
gvinum list giving the following informations :
3 drives:
D c State: up /dev/ad7 A: 1/1430799 MB (0%)
D a State: up /dev/ad5 A: 1/1430799 MB (0%)
D b State: up /dev/ad6 A: 1/1430799 MB (0%)
1 volume:
V data State: up Plexes: 2 Size: 2095 GB
2 plexes:
P data.p0 S State: up Subdisks: 3 Size: 2095 GB
P data.p1 S State: up Subdisks: 3 Size: 2095 GB
6 subdisks:
S data.p0.s0 State: up D: a Size: 698 GB
S data.p0.s1 State: up D: b Size: 698 GB
S data.p0.s2 State: up D: c Size: 698 GB
S data.p1.s0 State: up D: c Size: 698 GB
S data.p1.s1 State: up D: a Size: 698 GB
S data.p1.s2 State: up D: b Size: 698 GB
The I did a newfs on the drive, which went well, and I was able to mount
it again without any problem.
Still testing I decided to umount the drive and to use fsck on it.
Same problems came back. Unable to fsck simply, fsck_ufs getting stuck
on phase 1 and mount returning "operation not permitted".
Newfs again - no problems. Mount again - no problems.
Destroyed the gvinum drive, made every disk into a standard UFS drive
and fsck on each of them : no problems.
Tried to create FreeBSD partition with gvinum slices instead of using
disk directly : same old, same old.
So here I am starting to think that my disklabel and fsck are not in
sync with my kernel.
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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
