Portsnap causes system to reboot

[Weaseal]

Whenever I run portsnap fetch update (edit: it also happens for a simple portsnap fetch), my system reboots unexpectedly. Here's the output:

# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
Fetching snapshot tag from portsnap2.FreeBSD.org... done.
Fetching snapshot metadata... done.
Updating from Wed Sep 24 00:04:04 EEST 2008 to Thu Oct  9 10:28:42 EEST 2008.
Fetching 3 metadata patches.. done.
Applying metadata patches... done.
Fetching 3 metadata files... done.
Fetching 602 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....180....190....200....210....220....230....240....250....260....270....280....290....300....310....320....330....340....350....360....370....380....390....400....410....420....430....440....450....460....470....480....490....500....510....520....530....540....550....560....570....580....590....600. done.
Applying patches... Read from remote host X: Connection reset by peer
Connection to X closed.

And then I can log-in again a few minutes later, and the uptime has gone down to a few seconds, so I know it rebooted. Any ideas why this is happening?

Some background info:

$ uname -mrs
FreeBSD 7.0-RELEASE-p5 i386

And:

$ cat /etc/make.conf
# added by use.perl 2008-07-16 15:32:01
PERL_VER=5.8.8
PERL_VERSION=5.8.8

CFLAGS=-O2 -pipe
COPTFLAGS=-O2 -pipe
CPUTYPE=athlon-xp

NO_PROFILE=true

Since this started happening, I have still successfully updated ports by csup'ing the ports tree. I can also still rebuild the world and kernel without issue.

[graudeejs]

Originally Posted by Weaseal

And then I can log-in again a few minutes later, and the uptime has gone down to a few seconds, so I know it rebooted.

This sentence is confusing....
are you updating remote box?




Have you tried using portsnap from console (without X running)

[Weaseal]

Yes, it's a remote box. And no, I never use X with it, so portsnap was certainly from console.

[graudeejs]

try building
ports-mgmt/portsnap
from ports

[graudeejs]

Originally Posted by Weaseal

$ cat /etc/make.conf
# added by use.perl 2008-07-16 15:32:01
PERL_VER=5.8.8
PERL_VERSION=5.8.8

CFLAGS=-O2 -pipe
COPTFLAGS=-O2 -pipe
CPUTYPE=athlon-xp

NO_PROFILE=true

Why do you ppl use custom flags?????
Don't you know, it ain't nothing but a problem

By default there are more flags specified, than you did, and you only specified few(2) default flags, basically you disabled some, that's all.

remove CFLAGS (and , i'm not sure what is COPTFLAGS, but seams to me that thei are about the same) and recompile what you compiled with these flags

[BSDKaffee]

Originally Posted by killasmurf86

Why do you ppl use custom flags?????
Don't you know, it ain't nothing but a problem

By default there are more flags specified, than you did, and you only specified few(2) default flags, basically you disabled some, that's all.

remove CFLAGS (and , i'm not sure what is COPTFLAGS, but seams to me that thei are about the same) and recompile what you compiled with these flags

There really isn't anything out of the ordinary with that make.conf. Infact it is really quite minimal.

COPTFLAGS are the CFLAGS used for building the kernel only. It is usually best just to keep it at:
COPTFLAGS= -O -pipe

Here is my /etc/make.conf

CPUTYPE?=core2
CFLAGS=-O2 -fno-strict-aliasing -pipe
COPTFLAGS=-O -pipe
WITH_OPENSSL_BASE=yes
WANT_FAM_SYSTEM=gamin
PERL_VER=5.8.8
PERL_VERSION=5.8.8

I don't think this is a problem with make.conf. Weaseal, is this the same box as here: http://www.daemonforums.org/showthread.php?t=2058?

[phoenix]

The lack of -fno-strict-aliasing when specifying -O2 is known to cause problems with FreeBSD systems. All kinds of strange errors will occur with a world and kernel compiled with that set of CFLAGS.

[Weaseal]

Yes, same box as that other post with the panic.
Yes, I know that means the disk may be bad. I'm just hoping it isn't.

[mdh]

I just replied to your -questions post. Do you have any core dumps in /var/crash?
Also, check dmesg for information from the reboot.

This sounds like, as another -questions poster said, a filesystem issue. Unfortunately, it may be one that fsck doesn't fix - I had this happen to me (fsck says all is well, but hitting certain places on the FS causes a kernel panic due to a vfs dup alloc.)
Try running a "dmesg |grep -i vfs" and see if it says anything. If not, check out /var/crash.

[mdh]

One other thing - keep the /var/crash files if you can; you may need to newfs and rebuild the afflicted partition but it'd be nice to actually get a dump submitted to developers to fix this issue. Unfortunately when it happened to me, I had to get things rolling again fast and didn't have a chance to save the files in /var/crash.

[Weaseal]

$ cat /var/crash/
..minfreboundsçinfo.0ç                                                        vmcore.0zinfo.vmcore.1zinfo.vmcore.2zinfo.vmcore.3zinfo.vmcore.4zinfo.vmcore.5zinfo.vmcore.6zinfo.7vmcore.7zÀ

Does that mean anything to anyone?

[mdh]

Originally Posted by Weaseal

$ cat /var/crash/
..minfreboundsçinfo.0ç                                                        vmcore.0zinfo.vmcore.1zinfo.vmcore.2zinfo.vmcore.3zinfo.vmcore.4zinfo.vmcore.5zinfo.vmcore.6zinfo.7vmcore.7zÀ

Does that mean anything to anyone?

/var/crash is a directory... maybe paste the output from "ls -l /var/crash/" please.

Also, let us know when the last time it rebooted this way was. If you can stomach it, run a portsnap fetch to trigger it, then as soon as it comes back up, run a "dmesg" and post the output here, along with output from "ls -l /var/crash/" and "date" so we can compare when it bounced with the vmcore files, etc etc. Thanks!

[Weaseal]

D'oh. I'm a bit tired, clearly.
I found this in vmcore.7:

<118>Checking for core dump on /dev/ad4s1b...
<118>savecore: reboot after panic: ffs_clusteralloc: map mismatch
<118>Oct  9 11:16:26 freebsd savecore: reboot after panic: ffs_clusteralloc: map mismatch
<118>savecore: writing core to vmcore.6

[mdh]

Can you correlate the times of the coredumps to the times that the system rebooted due to the portsnap being run?

Do you have any way to boot into single user mode and run "fsck -y" ? If not, try running "fsck -y" as root anyway in multi-user mode and see if it complains about any errors.

If it doesn't, you've likely stumbled upon the bug I was plagued by. The bad news: I had to newfs parts of my system to get rid of the afflicted filesystems and reinstall. The good news: the reinstall prompted me to try out KDE4, which is a pretty nice upgrade.

[graudeejs]

Originally Posted by BSDKaffee

There really isn't anything out of the ordinary with that make.conf. Infact it is really quite minimal.

COPTFLAGS are the CFLAGS used for building the kernel only. It is usually best just to keep it at:
COPTFLAGS= -O -pipe

It's best to not specify them at all.
Why do you need to write things that are by default as they are in your config (not counting missed flags)?


If it ain't broke, don't fix it

[mdh]

Originally Posted by killasmurf86

It's best to not specify them at all.
Why do you need to write things that are by default as they are in your config (not counting missed flags)?

I've always specified my flags in make.conf, and always specified a cputype. I've never had problems because of it. You can cause gcc to produce better-optimized code for your platform by using it appropriately.

I'd be interested in seeing what sort of problems you've had because of it though - it's possible you pinched a few gcc bugs, which is always interesting and noteworthy - on a seperate thread.

[phoenix]

mdh:

Originally Posted by phoenix

The lack of -fno-strict-aliasing when specifying -O2 is known to cause problems with FreeBSD systems. All kinds of strange errors will occur with a world and kernel compiled with that set of CFLAGS.

Those who muck with CFLAGS and COPTFLAGS be playing with dragons. Best to tread lightly, and carry a big stick.

[Seriously, does anyone actually read the stuff I post, or does everyone just gloss over it?]

[mdh]

Originally Posted by phoenix

Those who muck with CFLAGS and COPTFLAGS be playing with dragons. Best to tread lightly, and carry a big stick.

[Seriously, does anyone actually read the stuff I post, or does everyone just gloss over it?]

The documentation says explicitly that it may break some ports...

# Compiling with -fstrict-aliasing optimization breaks some [notable] ports.
# GCC turns on -fstrict-aliasing optimization at all levels above -O[1], so
# explicitly turn it off when using compiling with the -O2 optimization level.

Therefore, that one caveat should be obvious to anyone who reads the documentation, so I didn't think it worth worrying about. I just don't think it's worthwhile to ignore a potential means of having a more efficient system just because of one well-documented issue that is easily dealt with by using -fno-strict-aliasing.

[phoenix]

Exactly. That's what I said. Mucking about with the default CFLAGS is just asking for trouble. The defaults are -O2 -pipe -fno-strict-aliasing. The CFLAGS presented by the OP explicitly did not include the last option.

Seriously, does anyone actually read what I write?

[richardpl]

Well if OP used these flags from make.conf to build kernel and world ... that is very very bad and ugly idea.

When building kernel remove your make.conf !!!!!

For ports you can put it back if that will make you more happy.