-mno-align-long-strings
-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
-ffreestanding -fstack-protector -Werror vers.c
linking kernel.debug
ld: kernel.debug: Not enough room for program headers (allocated 5, need 6)
ld: final link failed: Bad value
*** Error code
-strings
-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2
-mno-sse3 -ffreestanding -fstack-protector -Werror vers.c
linking kernel.debug
ld: kernel.debug: Not enough room for program headers (allocated 5, need 6)
ld: final link failed: Bad value
*** Error code 1
I'm
On Thu, 12 Apr 2007 20:21:17 -0700 Jon wrote:
Intel P III 933, 1/2 gig ram, plain old P3 box
Ok, installed 5.5 release.
setup X gnome
cvsuped the 5 stable branch
Ran make buildworld make buildkernel make installkernel
reboot
ran mergemaster -p in the /usr/src/ dir
then after i run
Boris Samorodov [EMAIL PROTECTED] writes:
On Thu, 12 Apr 2007 20:21:17 -0700 Jon wrote:
Intel P III 933, 1/2 gig ram, plain old P3 box
Ok, installed 5.5 release.
setup X gnome
cvsuped the 5 stable branch
Ran make buildworld make buildkernel make installkernel
reboot
ran mergemaster
Intel P III 933, 1/2 gig ram, plain old P3 box
Ok, installed 5.5 release.
setup X gnome
cvsuped the 5 stable branch
Ran
make buildworld make buildkernel make installkernel reboot
ran mergemaster -p in the /usr/src/ dir
then after i run make installworld I get the below error
same thing if
On Mon, Oct 23, 2006 at 10:05:30PM -0700, Doug Barton wrote:
Andrew Reilly wrote:
So: my two cents: it can work, but it's possible for it not to
work, and care is required.
That's always true, but worth a reminder nonetheless. :)
[*] The production server is using a software RAID mirror
Andrew Reilly wrote:
On Mon, Oct 23, 2006 at 10:05:30PM -0700, Doug Barton wrote:
Andrew Reilly wrote:
So: my two cents: it can work, but it's possible for it not to
work, and care is required.
That's always true, but worth a reminder nonetheless. :)
[*] The production server is using a
On Thu, Oct 26, 2006 at 04:14:53PM +1000, Tony Maher wrote:
dumpfs / | more
magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006
Thanks for the tip. Same on this system, so I must have given
it a proper clean install when I moved to 5.3.
The dumpfs output seems to say a lot of interesting
Andrew Reilly wrote:
On Thu, Oct 26, 2006 at 04:14:53PM +1000, Tony Maher wrote:
dumpfs / | more
magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006
Thanks for the tip. Same on this system, so I must have given
it a proper clean install when I moved to 5.3.
The dumpfs output
Hello!
On Thu, 26 Oct 2006, Andrew Reilly wrote:
How would I be able to tell? tunefs -p lists ACLs and MAC
[EMAIL PROTECTED] dumpfs /|head -1
magic 11954 (UFS1)timeThu Oct 26 17:53:53 2006
Yes, this is for RELENG_4 compatibility.
multlabel and soft updates, but of those only
On Fri, Oct 20, 2006 at 12:56:58AM +0100, Robert Watson wrote:
On Thu, 19 Oct 2006, Randy Bush wrote:
do folk actually successfully upgrade
to RELENG_6 *safely* on a many-user production system using the
instructions in UPDATING?
I've done that successfully on two single-user workstations,
On Oct 19, 2006, at 1:19 PM, Kevin Oberman wrote:
I delete rc.d/* isdn/* bluetooth/* defaults/* gnats/* mtree/*
periodic/*
and security/* as well as most other stuff in /etc that I know I have
not modified and won't need for a single-user boot. But be VERY
careful
about this!
I do this
Andrew Reilly wrote:
[*] The production server is using a software RAID mirror on
a pair of SATA drives on a low-end Intel P4/ICH6 motherboard,
using ar(4), configured by atacontrol. Fsck on 6.x can't find
any superblocks on /usr, but 5.5 is fine.
It's a horrible hack, and you should
Andrew Reilly wrote:
So: my two cents: it can work, but it's possible for it not to
work, and care is required.
That's always true, but worth a reminder nonetheless. :)
[*] The production server is using a software RAID mirror on
a pair of SATA drives on a low-end Intel P4/ICH6 motherboard,
On Sat, 21 Oct 2006, Randy Bush wrote:
for the record, i followed the recipe in UPDATING and it worked.
randy
Another for the record ...
I upgraded my production box from 5.3 to 6.2BETA2 without incident as
well. I was surprised that all my services started properly on the first
boot
for the record, i followed the recipe in UPDATING and it worked.
randy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Randy Bush wrote:
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386
to RELENG_6 *safely* on a many-user production system using the
instructions
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386
to RELENG_6 *safely* on a many-user production system using the
instructions in UPDATING?
randy
the
instructions in UPDATING?
Certainly. My definition of *safely* means having a full backup of
the system to which I can go back to if the OS version upgrade
doesn't work; if you don't have a good backup, well, you can probably
update from 5 to 6 just fine, but I would not consider doing
From: Randy Bush [EMAIL PROTECTED]
Date: Thu, 19 Oct 2006 11:39:18 -0500
Sender: [EMAIL PROTECTED]
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386
to
On Thursday 19 October 2006 19:39, Randy Bush wrote:
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386
to RELENG_6 *safely* on a many-user production system
Randy Bush wrote:
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386
to RELENG_6 *safely* on a many-user production system using the
instructions in
From: Patrick Okui [EMAIL PROTECTED]
Date: Thu, 19 Oct 2006 20:03:16 +0300
Sender: [EMAIL PROTECTED]
On Thursday 19 October 2006 19:39, Randy Bush wrote:
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT
2006
Certainly. My definition of *safely* means having a full backup of
the system to which I can go back to if the OS version upgrade
doesn't work; if you don't have a good backup, well, you can probably
update from 5 to 6 just fine, but I would not consider doing so to be
completely
I delete rc.d/* isdn/* bluetooth/* defaults/* gnats/* mtree/* periodic/*
and security/* as well as most other stuff in /etc that I know I have
not modified and won't need for a single-user boot. But be VERY careful
about this!
i regularly do that for /etc/rc.d for any update that is a month
LI Xin wrote:
Randy Bush wrote:
do folk actually successfully upgrade
# uname -a
FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386
to RELENG_6 *safely* on a many-user production system using the
the instructions
in UPDATING?
I've upgraded both 5.x to 6.x without serious problems, or even much work.
The usual advice holds: a serial console is invaluable, especially when
working remotely. You're much more likely to run into application upgrade
problems when you rebuild them all (or do binary
Hello everyone,
I have an annoying issue which is preventing me from installing FreeBSD
onto my new machine. I have a 1U server based on the Tyan S5360-1U
(http://www.tyan.com/products/html/thunderi7520r.html) board with the
3ware 9500S-4LP SATA card.
Scot Hetzel wrote:
You just need to define the _MAKE_CONF variable for the appropriate OS
that you are building:
make _MAKE_CONF=/etc/make.conf.6x [build|install]world
make _MAKE_CONF=/etc/make.conf.6x [build|install]kernel
I spent a bit of time today trying to figure out why the above
On 11/8/05, Chuck Swiger [EMAIL PROTECTED] wrote:
Craig Boston wrote:
On Tue, Nov 08, 2005 at 12:05:13PM +1000, Joel Hatton wrote:
Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method.
Do you know of any particular disadvantages of continuing with this
On Mon, Nov 07, 2005 at 04:21:56PM +1000, Joel Hatton wrote:
I've noticed that some CPU definitions have changed in /etc/make.conf
between 5 and 6. For good or for bad, I have up until now been building
5.x for both p3 and p4 architectures with 'i686' but this particular
definition's removal
Hello Joel,
Sunday, November 6, 2005, 10:21:56 PM, you wrote:
Hi,
I've noticed that some CPU definitions have changed in /etc/make.conf
between 5 and 6. For good or for bad, I have up until now been building
5.x for both p3 and p4 architectures with 'i686' but this particular
definition's
On 11/7/05, Joel Hatton [EMAIL PROTECTED] wrote:
Finally, when building on a single host, but where multiple requirements
are being met, is it possible to define different make.conf files for make
or is it easier to just edit this file before each build?
That is what I do when I build 5.x, 6.x
I always build my production servers with CPUTYPE=i686 so they can be
transplanted to any machine with a PPro or better processor (or even
qemu if necessary).
Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method.
Do you know of any particular disadvantages of
I always build my production servers with CPUTYPE=i686 so they can be
transplanted to any machine with a PPro or better processor (or even
qemu if necessary).
Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this
method.
Do you know of any particular disadvantages of
On Tue, Nov 08, 2005 at 12:05:13PM +1000, Joel Hatton wrote:
Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method.
Do you know of any particular disadvantages of continuing with this
less-than-optimised model - I guess I mean, is this something that is
likely to break or
Craig Boston wrote:
On Tue, Nov 08, 2005 at 12:05:13PM +1000, Joel Hatton wrote:
Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method.
Do you know of any particular disadvantages of continuing with this
less-than-optimised model - I guess I mean, is this something that is
Hi,
I've noticed that some CPU definitions have changed in /etc/make.conf
between 5 and 6. For good or for bad, I have up until now been building
5.x for both p3 and p4 architectures with 'i686' but this particular
definition's removal from 6.x has given me cause to rethink my strategy.
I'd like
On Fri, Oct 28, 2005 at 10:12:26AM +1000, Carl Makin wrote:
I've been playing with some GIS software and 32Mb TIFF images. Running
ImageMagick's convert utility under my normal user login to convert
the image to gif or jpeg blows away the system every time. No panic
seen on the console
On Fri, 28 Oct 2005, Carl Makin wrote:
I've been having a heap of trouble with the primary network interface on
a box that was running 5.4 and recently upgraded to 6.0-Beta5 where the
interface would just go dead. Nothing in ifconfig or syslog or dmesg
would indicate a problem, but nothing
I have found that ImageMagick writes to (and often fills up) /var/tmp...my
system becomes sluggish,
dies, reboots.
The solution I have used is to 1) create a /usr/tmp, 2) remove /var/tmp , 3)
make a symbolic link
between /usr/tmp and /var/tmp.
Perhaps ImageMagick could be patched to use a
On Fri, 28 Oct 2005, Carl Makin wrote:
I've been playing with some GIS software and 32Mb TIFF images. Running
ImageMagick's convert utility under my normal user login to convert the
image to gif or jpeg blows away the system every time. No panic seen on the
console and no core dump found,
On Fri, 28 Oct 2005 20:59, Michael A. Koerber wrote:
I have found that ImageMagick writes to (and often fills up) /var/tmp...my
system becomes sluggish, dies, reboots.
Your system shouldn't reboot - it is probably panicing for some reason and it
would be good to know why.
Can you enable crash
Michael A. Koerber wrote:
I have found that ImageMagick writes to (and often
fills up) /var/tmp...my system becomes sluggish,
dies, reboots.
The solution I have used is to 1) create a /usr/tmp,
2) remove /var/tmp , 3) make a symbolic link
between /usr/tmp and /var/tmp.
Perhaps
Rob wrote:
Michael A. Koerber wrote:
I have found that ImageMagick writes to (and often
fills up) /var/tmp...my system becomes sluggish,
dies, reboots.
The solution I have used is to 1) create a /usr/tmp,
2) remove /var/tmp , 3) make a symbolic link
between /usr/tmp and /var/tmp.
Perhaps
Carl Makin wrote:
John Pettitt wrote:
Carl Makin wrote:
Morning All,
the interface would just go dead. Nothing in ifconfig or syslog or
dmesg would indicate a problem, but nothing would go in or out. The
only way to fix it was reboot.
What sort of network card? I've been
Morning All,
I've been having a heap of trouble with the primary network interface on
a box that was running 5.4 and recently upgraded to 6.0-Beta5 where the
interface would just go dead. Nothing in ifconfig or syslog or dmesg
would indicate a problem, but nothing would go in or out. The
On Fri, Oct 28, 2005 at 09:55:21AM +1000, Carl Makin wrote:
Morning All,
I've been having a heap of trouble with the primary network interface on
a box that was running 5.4 and recently upgraded to 6.0-Beta5 where the
interface would just go dead. Nothing in ifconfig or syslog or dmesg
Morning All,
I've been playing with some GIS software and 32Mb TIFF images. Running
ImageMagick's convert utility under my normal user login to convert
the image to gif or jpeg blows away the system every time. No panic
seen on the console and no core dump found, the system just quietly
On Thursday 27 October 2005 17:12, Carl Makin wrote:
Morning All,
I've been playing with some GIS software and 32Mb TIFF images. Running
ImageMagick's convert utility under my normal user login to convert
the image to gif or jpeg blows away the system every time. No panic
seen on the
Carl Makin wrote:
Morning All,
I've been having a heap of trouble with the primary network interface
on a box that was running 5.4 and recently upgraded to 6.0-Beta5 where
the interface would just go dead. Nothing in ifconfig or syslog or
dmesg would indicate a problem, but nothing would
On Fri, 28 Oct 2005, 10:12+1000, Carl Makin wrote:
Morning All,
I've been playing with some GIS software and 32Mb TIFF images.
Running ImageMagick's convert utility under my normal user login
to convert the image to gif or jpeg blows away the system every
time. No panic seen on the console
John Pettitt wrote:
Carl Makin wrote:
Morning All,
the interface would just go dead. Nothing in ifconfig or syslog or
dmesg would indicate a problem, but nothing would go in or out. The
only way to fix it was reboot.
What sort of network card? I've been having the same syptoms
53 matches
Mail list logo
