Re: WITH_OPENSSL_PORT=yes
On 03/05/2012 21:22, Darrel wrote: If WITH_OPENSSL_PORT=yes exists in /etc/make.conf, will the system compile against that as well or only applications? The base system always links against the copy of openssl in base irrespective of the WITH_OPENSSL_PORT setting: % grep WITH_OPENSSL_PORT /etc/make.conf WITH_OPENSSL_PORT= yes A sample application from the base that uses openssl: % ldd /usr/bin/ssh /usr/bin/ssh: [...] libcrypto.so.6 = /lib/libcrypto.so.6 (0x8012dd000) [...] Whereas something installed from ports uses the ports version of openssl: % ldd /usr/local/sbin/sendmail /usr/local/sbin/sendmail: [...] libssl.so.8 = /usr/local/lib/libssl.so.8 (0x800ce8000) libcrypto.so.8 = /usr/local/lib/libcrypto.so.8 (0x800f4a000) [...] So, yes, you do need to update the system in the manner described in the recent FreeBSD-SA-12:01.openssl security advisory. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: freebsd-update not updating reported patchlevel
On 03/05/2012 23:43, Robert Bonomi wrote: Amazingly, this very question was covered on this list within the last few hours. grin It's not that much of a coincidence. We always get a rash of queries like this every time there's a security advisory and consequently a lot of people are updating. Executive summary: the kernel ID string that uname reports changes only when the -kernel- is changed. -p4, -p5, -p6, and -p7. have -not- involved any changes to the kernel. hence the ID string has stayed at '-p3'. While this _is_ counter-intuitive, it does make sense to avoid pushing a new k ernel out, and/or forcing an admin to rebuild a custom kernel, when the -only- change would be to the ID string. I wonder if it would be possible or indeed worthwhile to have a very small kld or sysctl that shows the current patch level and that can be updated without replacing the kernel entire. Obviously, this introduces the possibility of faking the patchlevel, so perhaps this should be constructed so it can only be modified on reboot. H Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: freebsd-update not updating reported patchlevel
On 03/05/2012 22:52, Mike Brown wrote: For example, with this latest OpenSSL security update, running 'freebsd-update fetch' says (among other things) The following files will be updated as part of updating to 8.2-RELEASE-p7 and WARNING: FreeBSD 8.2-RELEASE-p3 is approaching its End-of-Life date. It is strongly recommended that you upgrade to a newer release within the next 2 months. Aside from the question of the version string embedded in the kernel not being updated which has been addressed elsewhere, this warning seems a bit unclear. It's actually the entire 8.2-RELEASE branch that is approaching EoL, not any specific patchlevel within it. (Individual patchlevels don't have an EoL concept per se: they just last until the next one comes out, or the whole branch goes out of support.) In other words, this message is warning you to update to 8.3-RELEASE or 9.0-RELEASE in the near future. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: freebsd-update not updating reported patchlevel
From owner-freebsd-questi...@freebsd.org Fri May 4 02:54:56 2012
Date: Fri, 04 May 2012 08:52:24 +0100
From: Matthew Seaman m.sea...@infracaninophile.co.uk
To: freebsd-questions@freebsd.org
Subject: Re: freebsd-update not updating reported patchlevel
On 03/05/2012 23:43, Robert Bonomi wrote:
Amazingly, this very question was covered on this list within the last few
hours. grin
It's not that much of a coincidence. ...
No kidding. wry grin
The 'amazingly' was a wry commentary on that very fact.
I wonder if it would be possible or indeed worthwhile to have a very
small kld or sysctl that shows the current patch level and that can be
updated without replacing the kernel entire. Obviously, this introduces
the possibility of faking the patchlevel, so perhaps this should be
constructed so it can only be modified on reboot.
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Both kernel revision level and 'world' patchlevel are reset -only-
when a new minor (or major) release of the O/S is installed. Aside
from that, they increment semi-independantly -- 'world' patchlevel
is always greater-equal to kernel revision level.
Ideally, this is a _log_ of all the actual changes, something along the
lines of:
BEGIN updates
updated {foo}, Vers x.y.z, old file renamed to {foo}.x.y.x-replaced
patchfile {foo1} for {pathname}, patch application succeeded
patchfile {foo2} for {pathname}, patch application FAILED
obselete file {foo3} renamed to {foo3}.x.y.z-obselete
END updates Now at patchlevel {quux}
For 'audit' purposes', every line is prefixed with
timestamp,
login username/effective UID(as a username)
the tty device from which the action was performed.
When a new release of the O/S is installed, the patchlog file is renamed
or deleted, and a single line of the form:
END install Now at patchlevel 0
is written. Thus there is always an END line with the patchlevel ID.
The numeric patchlevel is written as a fixed-width *right-justiied* field.
Thus, the last 'END' starts at a 'known' position before the end of the
file, allowing an application to do a direct fseek(3)/lseek(2) to it (or
the patchlevel) without having to read the entire file. ('install' and
'updates' are chosen with malice aforethought, they're the same length ;)
From the command-line, 'tail -1 {patchlog}' gets everything.
With this kind of setup, and assuming that all distributed patchfiles have
'unique' names, the 'patchlog' provides a roadmap for reconstructing the
state of the kernel and 'world' as of any particular point in time.
AT LEAST as important, it provides a record that would let one 'back out'
an update, to revert to a prior system state, if needed. In fact, it
would be 'easy' to have automation perform that task.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
editors/libreoffice:internal build errors: ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj
I found myself incapable of rebuilding/updating editors/libreoffice on ALL FreeBSD 9-STABLE and FreeBSD 10-CURRENT (amd64) platforms with the very same error message as shown below. It doesn't matter whether I try to build/update with CLANG or the legacy gcc 4.2.1. GCC 4.6 and 4.7 fail due to 32/64 bit incompatibilities (some weird errors occur, not further investigated). It seems impossible to rebuild even a former installed version of libreoffice. Resources are no problem, I build Libreoffice with DISABLE_MAKE_JOBS and in one case the box has 32GB of RAM - and is free of other duties for the time building LibreOffice. Regards, O. Hartmann [...] /usr/local/bin/xsltproc --nonet --stringparam uri \ Compiling: lingucomponent/source/thesaurus/libnth/ntreg.cxx Compiling: lingucomponent/source/thesaurus/libnth/nthesimp.cxx 'vnd.sun.star.expand:$LO_LIB_DIR/libspelllo.so' -o ../../../unxfbsd.pro/misc/spell.component \ /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/solenv/bin/createcomponent.xslt spell.component Compiling: lingucomponent/source/hyphenator/altlinuxhyph/hyphen/hreg.cxx Compiling: lingucomponent/source/hyphenator/altlinuxhyph/hyphen/hyphenimp.cxx /usr/local/bin/xsltproc --nonet --stringparam uri \ 'vnd.sun.star.expand:$LO_LIB_DIR/libhyphenlo.so' -o ../../../../unxfbsd.pro/misc/hyphen.component \ /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/solenv/bin/createcomponent.xslt hyphen.component /usr/local/bin/xsltproc --nonet --stringparam uri \ 'vnd.sun.star.expand:$LO_LIB_DIR/liblnthlo.so' -o ../../../unxfbsd.pro/misc/lnth.component \ /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/solenv/bin/createcomponent.xslt lnth.component /usr/local/bin/xsltproc --nonet --stringparam uri \ 'vnd.sun.star.expand:$LO_LIB_DIR/libguesslanglo.so' -o ../../unxfbsd.pro/misc/guesslang.component \ /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/solenv/bin/createcomponent.xslt guesslang.component Making:guesslang.lib Making:libguesslanglo.so Entering /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/lingucomponent/source/spellcheck/macosxspell Nothing to build for GUIBASE=unx Making:spell.lib Making:libspelllo.so Making:hyphen_lib.lib Making:libhyphenlo.so Making:lnth.lib Making:liblnthlo.so lingucomponent deliver Module 'lingucomponent' delivered successfully. 12 files copied, 2 files unchanged --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/ucb/source/ucp/cmis ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/odk/pack/gendocu it seems you are using a threaded build, which means that the actual compile error is probably hidden far above, and could be inside any of these other modules: ucb vcl please re-run build inside each one to isolate the problem. --- /usr/local/bin/bash cd /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2 source ./Env.Host.sh cd odk rm -Rf /usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/odk/unxfbsd.pro # optional module 'clean' build when the problem is isolated and fixed exit and re-run 'make' from the top-level gmake[1]: *** [build] Error 1 gmake[1]: Leaving directory `/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2' gmake: *** [source-env-and-recurse] Error 2 *** Error code 1 Stop in /usr/ports/editors/libreoffice. *** Error code 1 Stop in /usr/ports/editors/libreoffice. === make failed for editors/libreoffice === Aborting update === Update for editors/libreoffice failed === Aborting update Terminated ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Performance and mouse problems
Le 02/05/2012 ? 22:44:19+0200, Jerome Herman a écrit
Ok here is what happens,
In your system you have your touchpad declared both in a static way in
your xorg config, and probed by HAL.
What happens is that when xorg starts it first install the touchpad as
required by the config file, and then tries to install it again via
autodetection. Of course the second installation of the same device
doesn't work as the device is already busy with xorg, and xorg stops to
try to auto-install devices.
When you plug another mouse, xorg is notified that there are new
devices, but starts by trying to reinstall the touchpad, fails again for
the same reason as above and stops trying.
In order to solve your problem you can try the following :
a) remove the touchpad lines from your xorg config. This way the
touchpad should be installed by auto detection. (simply comment it as
you might be needing it back soon)
b) forbid hal from probing the touchpad. If solution a fails, I would
explain to you how to do this if solution a) fails.
I try this.
I do a hal-device find the unique udi to have /dev/psm0 in input.device,
udi = '/org/freedesktop/Hal/devices/psm_0'
freebsd.driver = 'psm' (string)
freebsd.unit = 0 (0x0) (int)
platform.id = 'psm.0' (string)
freebsd.device_file = '/dev/psm0' (string)
info.capabilities = { 'input', 'input.mouse' } (string list)
info.category = 'input' (string)
input.device = '/dev/psm0' (string)
input.x11_driver = 'mouse' (string)
info.addons = { 'hald-addon-mouse-sysmouse' } (string list)
info.udi = '/org/freedesktop/Hal/devices/psm_0' (string)
info.parent = '/org/freedesktop/Hal/devices/atkbdc_0' (string)
info.product = 'PS/2 Mouse' (string)
info.subsystem = 'platform' (string)
and add a new file in /usr/local/etc/hal/fdi/policy/ with
?xml version=1.0 encoding=UTF-8?
deviceinfo version=0.2
device
match key=info.product string=PS/2 Mouse
merge key=info.ignore type=booltrue/merge
/match
/device
/deviceinfo
restart hald, reboot and...nothing :-(
I've try also with something like
?xml version=1.0 encoding=UTF-8?
deviceinfo version=0.2
device
match key=freebsd.driver string=psm
match key=info.product string=PS/2 Mouse
merge key=info.ignore type=booltrue/merge
/match
/match
/device
/deviceinfo
but same result.
The touchpad still working and most important the mouse still NOT working.
Any help ?
Thanks.
Regards.
JAS
--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
Téléphone : 01 45 07 76 26/06 86 69 95 71
xmpp: j...@obspm.fr
Heure local/Local time:
ven 4 mai 2012 14:42:00 CEST
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update not updating reported patchlevel
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the build number
and the date of the currently installed -STABLE snapshot.
A separation of a kernel version file and a world version
file is useful in cases the kernel won't be touched, so no
need to update its version file (as well as the kernel itself)
by a binary update.
The files should be easily parsable. They could even contain
an assignment in sh syntax, as well as comments (for BSDL and
$FreeBSD$ information). Their templates could be stored in
the /usr/src subtree for the etc/ structure, so programs like
make and mergemaster could access them from there.
Maybe a binary command could be added to the base system to
query this information (maybe getent could do that?).
Here are some suggestions:
/etc/kernversion
VERSION=8.2
BRANCH=STABLE
BUILD=12345
DATE=2011-08-01 12:34:56
or
/etc/kernversion
VERSION=8.4
BRANCH=RELEASE
PATCH=2
DATE=2012-02-02 02:02:02
/etc/sysversion
VERSION=8.4
BRANCH=RELEASE
PATCH=4
DATE=2012-04-04 04:04:04
This shows: Kernel has last been updated to patchlevel 2 (to
check with uname -r will show that version), but the system
has been updated two more times to patchlevel 4.
The notation could be X.Y-pZ or X.Y.Z for -RELEASE installations,
and X.Y-B for -STABLE installations. However, it's not hard to
write any custom parser and composer if urgently needed.
Maybe things also present in uname -a output (such as architecture
and OS name) could be included, but I think that's not required
because it's mostly obvious. :-)
Both kernel revision level and 'world' patchlevel are reset -only-
when a new minor (or major) release of the O/S is installed. Aside
from that, they increment semi-independantly -- 'world' patchlevel
is always greater-equal to kernel revision level.
Ideally, this is a _log_ of all the actual changes, something along the
lines of:
BEGIN updates
updated {foo}, Vers x.y.z, old file renamed to {foo}.x.y.x-replaced
patchfile {foo1} for {pathname}, patch application succeeded
patchfile {foo2} for {pathname}, patch application FAILED
obselete file {foo3} renamed to {foo3}.x.y.z-obselete
END updates Now at patchlevel {quux}
For 'audit' purposes', every line is prefixed with
timestamp,
login username/effective UID(as a username)
the tty device from which the action was performed.
When a new release of the O/S is installed, the patchlog file is renamed
or deleted, and a single line of the form:
END install Now at patchlevel 0
is written. Thus there is always an END line with the patchlevel ID.
The numeric patchlevel is written as a fixed-width *right-justiied* field.
Thus, the last 'END' starts at a 'known' position before the end of the
file, allowing an application to do a direct fseek(3)/lseek(2) to it (or
the patchlevel) without having to read the entire file. ('install' and
'updates' are chosen with malice aforethought, they're the same length ;)
From the command-line, 'tail -1 {patchlog}' gets everything.
Also very nice. By simply _viewing_ the file, the most non-current
version will be discovered, so maybe (just _maybe_) re-ordering them
in upside-down (newest version on top) would be better? Of course,
this would not go well with the log idea. Files like UPDATING
in the /usr/ports and /usr/src tree use such an approach.
Such a log file would not feel comfortable in /etc, it should
rather go to /var or even /var/log. :-)
With this kind of setup, and assuming that all distributed patchfiles have
'unique' names, the 'patchlog' provides a roadmap for reconstructing the
state of the kernel and 'world' as of any particular point in time.
AT LEAST as important, it provides a record that would let one 'back out'
an update, to revert to a prior system state, if needed. In fact, it
would be 'easy' to have automation perform that task.
How about performing version skips, e. g. from -p1 to -p4
directly (using
Re: freebsd-update not updating reported patchlevel
Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
included in kernal builds, and where the *handful* of utilities -- e.g.
lsof -- that are intimately coupled to the exact O/S version are already
picking up 'system specific' gory details.
/usr/include is definitely a 'wrong place'. Arguably, so is /etc.
From the standpoint of 'a single place' for critical data, anything other
than a kernel build should use what is in the 'uname' output. (See the
notes on O'Brien, below.)
_Very_few_ applications are concerned with the patchlevel of 'world'.
rebuilding everything that #included a 'world patchlevel' file, when
the only thing that changed was the patchlevel, is just plain silly.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the build number
and the date of the currently installed -STABLE snapshot.
Changes for 'other than that application' are -irrelevant- to any
particular application.
*PROPERLY* USED, CVS keywords provide automatic inclusion of this
information -- for _every_ source module (.c or .h, and equivalents for
other languages) in every executable build.
For example, put the following lines in the start of every source module
(before any '#include' lines);
static char *_id =
@(#) $Id:$ \0\0
@(#) Version: $Revision:$ Edited: $Date:$ \0\0
@(#) Build:__DATE__ __TIME__ ;
and similar lines in each #include (excluding the 'build' info),
with the variable name being made 'unique' by appendinng the file name,
and bracketed in #ifndef/#endif to ensure only a single inclusion in a
given mudule.
Recognizing that '@(#)' is a 'magic sequence' used by SCCS, and utilized
by what(1). if 'what' is not available, it can be simulated by;
strings {foo} | awk '/^@(#) / { $1=; print; }'
Add a similarly-constructed '_id_header' in the 'main' module, (making sure
that 'main' is named first on the linker line) which provides a label, the
'published' Major/minor/revision number and a 'counter' of the number of
builds (doe with a one-liner addition in the makefile target that builds the
executable, and you get results like THIS:
% what milter_daemon
milter_daemon:
version-control
Version: 1.1.0(368)
milter_daemon.c,v 1.34 2010/11/04 23:54:02 bonomi Exp
Version: 1.34 Edited: 2010/11/04 23:54:02
Build: Dec 20 2010 02:49:47
testharness.h,v 1.5 2010/11/04 23:53:37 bonomi Exp
Version: 1.5 Edited: 2010/11/04 23:53:37
milter_includes.h,v 1.5 2010/11/04 23:53:37 bonomi Exp
Version: 1.5 Edited: 2010/11/04 23:53:37
pass_dict.h,v 1.4 2010/11/04 23:53:37 bonomi Exp
Version: 1.4 Edited: 2010/11/04 23:53:37
headers.h,v 1.4 2010/10/02 00:12:56 bonomi Exp
Version: 1.4 Edited: 2010/10/02 00:12:56
mime_subs.h,v 1.4 2010/11/04 23:53:37 bonomi Exp
Version: 1.4 Edited: 2010/11/04 23:53:37
milter_config_file.h,v 1.25 2010/11/27 21:43:02 bonomi Exp
Version: 1.25 Edited: 2010/11/27 21:43:02
postfixer.h,v 1.8 2010/11/04 23:53:37 bonomi Exp
Version: 1.8 Edited: 2010/11/04 23:53:37
mlfi_priv.h,v 1.9 2010/10/05 16:18:15 bonomi Exp
Version: 1.9 Edited: 2010/10/05 16:18:15
checklists.h,v 1.3 2010/09/16 18:27:51 bonomi Exp
Version: 1.3 Edited: 2010/09/16 18:27:51
per_user_config.h,v 1.2 2010/10/25 22:45:37 bonomi Exp
Version: 1.2 Edited: 2010/10/25 22:45:37
pass_dictionary.c,v 1.5 2010/11/04 23:54:02 bonomi Exp
Version: 1.5 Edited: 2010/11/04 23:54:02
Build: Dec 20 2010 02:49:49
headers.c,v 1.4 2010/10/02 00:12:56 bonomi Exp
Version: 1.4 Edited:
Re: freebsd-update not updating reported patchlevel
On 2012-05-04 10:45, Polytropon wrote: Allow me to extent the approach: For -STABLE versions (e. g. if updated per CVS), those files could contain the build number and the date of the currently installed -STABLE snapshot. A separation of a kernel version file and a world version file is useful in cases the kernel won't be touched, so no need to update its version file (as well as the kernel itself) by a binary update. The files should be easily parsable. They could even contain an assignment in sh syntax, as well as comments (for BSDL and $FreeBSD$ information). Their templates could be stored in the /usr/src subtree for the etc/ structure, so programs like make and mergemaster could access them from there. Maybe a binary command could be added to the base system to query this information (maybe getent could do that?). Here are some suggestions: /etc/kernversion VERSION=8.2 BRANCH=STABLE BUILD=12345 DATE=2011-08-01 12:34:56 or /etc/kernversion VERSION=8.4 BRANCH=RELEASE PATCH=2 DATE=2012-02-02 02:02:02 /etc/sysversion VERSION=8.4 BRANCH=RELEASE PATCH=4 DATE=2012-04-04 04:04:04 This shows: Kernel has last been updated to patchlevel 2 (to check with uname -r will show that version), but the system has been updated two more times to patchlevel 4. The notation could be X.Y-pZ or X.Y.Z for -RELEASE installations, and X.Y-B for -STABLE installations. However, it's not hard to write any custom parser and composer if urgently needed. Maybe things also present in uname -a output (such as architecture and OS name) could be included, but I think that's not required because it's mostly obvious. :-) I think you could still get a machine-parseable version on one line, that's also a bit nicer for human reading. Perhaps something like this? (Partly inspired by RedHat's /etc/redhat-release) /etc/sysversion FreeBSD RELEASE 8.4-p4: 2012-04-04 04:04:04 You should be able to parse that with a few lines of C or shell, and it looks like something set up to be read by humans. You just need to define - and stick to - which pieces of information will be in there in what order. (For instance, I'd prefer '9.0-p0' to '9.0' Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: editors/libreoffice:internal build errors
Hartmann, O. ohart...@zedat.fu-berlin.de wrote: Cc: Subject: editors/libreoffice:internal build errors: ERROR: error 65280 I found myself incapable of rebuilding/updating editors/libreoffice on ALL FreeBSD 9-STABLE and FreeBSD 10-CURRENT (amd64) platforms with the very same error message as shown below. Not to be obnoxious did you try doing what was recommended _in_the_error_ _message_? If so, what were the results of -that-? If not, _why_ not? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: editors/libreoffice:internal build errors
On 05/04/12 19:01, Robert Bonomi wrote: Hartmann, O. ohart...@zedat.fu-berlin.de wrote: Cc: Subject: editors/libreoffice:internal build errors: ERROR: error 65280 I found myself incapable of rebuilding/updating editors/libreoffice on ALL FreeBSD 9-STABLE and FreeBSD 10-CURRENT (amd64) platforms with the very same error message as shown below. Not to be obnoxious did you try doing what was recommended _in_the_error_ _message_? If so, what were the results of -that-? If not, _why_ not? I did, I did and it ended up as it ended up in the past 5 years with Open-/LibreOffice and FreeBSD. It doesn't work. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update not updating reported patchlevel
First of all, thanks for explaining your point of view.
Allow me to add a few thoughts:
On Fri, 4 May 2012 11:44:49 -0500 (CDT), Robert Bonomi wrote:
Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
included in kernal builds, and where the *handful* of utilities -- e.g.
lsof -- that are intimately coupled to the exact O/S version are already
picking up 'system specific' gory details.
Correct. I appreciate the idea of having _one_ centralized
point for that information that is authoritative regarding
all queries. Like uname displays several aspects of the
kernel's data, it is limited in some regards:
For example, if you have updated the system the binary
way to -p3 which included a kernel change, uname will
report that -p3 properly. If you follow -STABLE, you
don't get the information of what build you currently
have, so you cannot put it into relation after what
-plevel we currently are.
% uname -r
8.2-STABLE
I know there is some file in /usr/src where the build
number can be obtained from (I think it's a #define),
but it's not included in the kernel queryable data.
/usr/include is definitely a 'wrong place'. Arguably, so is /etc.
From the standpoint of 'a single place' for critical data, anything other
than a kernel build should use what is in the 'uname' output. (See the
notes on O'Brien, below.)
_Very_few_ applications are concerned with the patchlevel of 'world'.
rebuilding everything that #included a 'world patchlevel' file, when
the only thing that changed was the patchlevel, is just plain silly.
Oh, I didn't think about recompiling any stuff against
such a header file. I did primarily assume it as a kind
of purely informative source, which could also be provided
by a plain text file.
*PROPERLY* USED, CVS keywords provide automatic inclusion of this
information -- for _every_ source module (.c or .h, and equivalents for
other languages) in every executable build.
Correct, but obtaining such data is often not possible by the
application itself (except it has an extended version option
or it includes that info in a help screen).
For the kernel, uname prints various information (which are
obtained from the kernel directly, which is good), but what
program can do the same for the system?
See above.
Done 'right', this stuff is already all there, with _existing- tools.
Not fully, if I see it correctly. E. g., what build number
has a particular -STABLE installation? Or, if kernel and world
are able to be updated independently - no kernel change, but a
program change from -plevel to -plevel+1 will leave the
kernel's uname -r at -plevel, so how to tell easily that
the world is at -plevel+1?
Also very nice. By simply _viewing_ the file, the most non-current
version will be discovered, so maybe (just _maybe_) re-ordering them
in upside-down (newest version on top) would be better?
Definitely -not-. grin
You obviously didn't notice that the file flags are 'sysem append only'.
Oh, I noticed that, and I know appending on top is always
more complicated than appending (in the precise sense of what
to append means). :-)
The entire point of my proposal is to make it an IMMUTATABLE RECORD of
'what was done'. 'add to top' has several disadvantages. First,
a performance issue, you do have to read down the log to find the
first 'END' line rather than being able to seek directly to it.
Second, and the *BIG* one, you risk destroying the prior information
by re-writing the file. Third, it makes it easier for a 'malicious'
update to cover it's tracks.
Additionally, _undoing_ operations would also be logged - not
by omitting lines, but by a proper record that states how things
have been reverted to a previous level, which is also very good
for diagnostics.
Until you learn to think like O'Brien, staying ahead of him requires a
-lot- of forethought.
Oh, I often think like O'Brien, and I don't remember, especially
when I'm talking to 6079 Smith W., machen Sie die Augen auf! :-)
On topic again:
Re: freebsd-update not updating reported patchlevel
On 4 May 2012, at 16:45, Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the build number
and the date of the currently installed -STABLE snapshot.
I have massive love for this idea, having to check the kern build date to have
a rough idea of what 8-STABLE I'm running is too prone to errors.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Off topic: NetBSD or OpenBSD for Alpha server ?
On Fri, May 4, 2012 at 3:56 PM, Erik Nørgaard norga...@locolomo.org wrote: On 04/05/2012 19:51, Kenneth Hatteland wrote: So I checked the 2 other main contenders and just wanted to ask if anyone here had an opinion what 2 install of the BSDs ? Or perhaps FreeBSD 6.4 is a good choice ( I have not tested Open or Net BSD so FreeBSD is my hometurf) The machine will probably be a server to have fun with and hopefully learn something from. Perhaps some server role in my rig, routing, security etc. Any advise would be nice :) QNX will not run on the Alpha architecture, freeBSD 6.4 in my opinion is still the far better choice for anything alpha the only other thing i would recommend oin that platorm would be OpenVMS from the hobbyist kit. But then again I only run real Operating systems on my Alphas :) A few things you could consider: - which OS seems to be the most active? I recall NetBSD was about a dead end a few years ago, but maybe they got back. - which OS seems to offer you the best learning oportunity? If you're interested in security OpenBSD might be a choice. ... but then, why not try both, it's free. Or consider something completely different? If I had to go BSD, and not FreeBSD, I'd go with OpenBSD for the security. But I'd much rather like to try a microkernel system like QNX if that would be an alternative. BR, Erik -- M: +34 666 334 818 T: +34 915 211 157 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Off topic: NetBSD or OpenBSD for Alpha server ?
On Fri, May 04, 2012 at 04:45:17PM -0400, Outback Dingo wrote: On Fri, May 4, 2012 at 3:56 PM, Erik N?rgaard norga...@locolomo.org wrote: On 04/05/2012 19:51, Kenneth Hatteland wrote: So I checked the 2 other main contenders and just wanted to ask if anyone here had an opinion what 2 install of the BSDs ? Or perhaps FreeBSD 6.4 is a good choice ( I have not tested Open or Net BSD so FreeBSD is my hometurf) The machine will probably be a server to have fun with and hopefully learn something from. Perhaps some server role in my rig, routing, security etc. Any advise would be nice :) QNX will not run on the Alpha architecture, freeBSD 6.4 in my opinion is still the far better choice for anything alpha the only other thing i would recommend oin that platorm would be OpenVMS from the hobbyist kit. But then again I only run real Operating systems on my Alphas :) 6.4 is way past EOL. It's irresponsible to recommend it. I've run VMS on Alphas for several years, there's nothing wrong with it. Indeed, it's very good. Plus VMS Alpha is highly optimised. You are unlikely to get a similar performance from any other OS on this architecture. If you want to learn UNIX, then I strongly recommend FreeBSD, but do not use an obsolete version. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: HOWTO: FreeBSD ZFS Madness (Boot Environments)
I have zfs-on-root using the classical documentation (everything under zpool, possibly with some sub-mounts, but I've left those out lately). Is there a way to transition my system to a form that beadm expects? I tried just running it, and it's upset that zpool/ROOT doesn't exist. Hi, I would suggest using something like that: # zfs create -o mountpoint=none zpool/ROOT # zfs snapshot zpool@be # zfs clone zpool@be zpool/ROOT/default # fetch https://github.com/vermaden/beadm/blob/master/beadm # chmod +x beadm # ./beadm list # ./beadm activate default # reboot Be sure to use the latest *beadm* from one of these: https://raw.github.com/vermaden/beadm/master/beadm https://sourceforge.net/projects/beadm/ Let me know how these instructions work, especially if You got any errors or an unbootable system. It would be best if You would test this zpool root to sys/ROOT/be transition under VirtualBox for 100% safety ;) Regards, vermaden -- ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: HOWTO: FreeBSD ZFS Madness (Boot Environments)
vermaden == vermaden verma...@interia.pl writes: vermaden # fetch https://github.com/vermaden/beadm/blob/master/beadm Heh. That's HTML. I think you want fetch https://raw.github.com/vermaden/beadm/master/beadm vermaden # chmod +x beadm vermaden # ./beadm list vermaden # ./beadm activate default vermaden # reboot vermaden Be sure to use the latest *beadm* from one of these: vermaden https://raw.github.com/vermaden/beadm/master/beadm vermaden https://sourceforge.net/projects/beadm/ vermaden Let me know how these instructions work, especially if You got vermaden any errors or an unbootable system. Oh, that worked perfectly, except for an error message during the create. and after reboot, zfs set mountpoint=none zroot would also seem to clean that up. vermaden It would be best if You would test this zpool root to sys/ROOT/be transition under VirtualBox for 100% safety ;) vermaden Regards, vermaden vermaden vermaden -- vermaden ... vermaden ___ vermaden freebsd-questions@freebsd.org mailing list vermaden http://lists.freebsd.org/mailman/listinfo/freebsd-questions vermaden To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update not updating reported patchlevel
On Fri, 4 May 2012 16:45:51 -0500 (CDT), Robert Bonomi wrote:
Polytropon free...@edvax.de wrote:
First of all, thanks for explaining your point of view.
Allow me to add a few thoughts:
On Fri, 4 May 2012 11:44:49 -0500 (CDT), Robert Bonomi wrote:
Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision
level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the
kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
included in kernal builds, and where the *handful* of utilities -- e.g.
lsof -- that are intimately coupled to the exact O/S version are already
picking up 'system specific' gory details.
Correct. I appreciate the idea of having _one_ centralized
point for that information that is authoritative regarding
all queries. Like uname displays several aspects of the
kernel's data, it is limited in some regards:
For example, if you have updated the system the binary
way to -p3 which included a kernel change, uname will
report that -p3 properly. If you follow -STABLE, you
don't get the information of what build you currently
have, so you cannot put it into relation after what
-plevel we currently are.
% uname -r
8.2-STABLE
uname -v, maybe ??
Like uname -a (maximum output), only the date of the kernel
build is present. I'd like to know that strange number and
how it relates (pre-/postdates) -plevel patch levels.
If you're talking about trying to associate a particular patch/revison
level of a particular program with a partiular 'world' patchlevel. That
is a very different problem, and requires a separate separate solution,
something like a 'correlation' database.
Yes, that was my primary intention.
For the kernel, uname prints various information (which are
obtained from the kernel directly, which is good), but what
program can do the same for the system?
For kernel info, any program that can 'popen' for write uname -a. *grin*
For the patchlevel of the 'world', TTBOMK it isn't recorded anywhere
conveniently accessible.
I know that this build number is stored somewhere (I found it
once!), I think it was a header file. Sure, you can grep for it,
but it would be easier to make this information better accessible
(and maybe even to put it into relation to a patch level number).
Not fully, if I see it correctly. E. g., what build number
has a particular -STABLE installation? Or, if kernel and world
are able to be updated independently - no kernel change, but a
program change from -plevel to -plevel+1 will leave the
kernel's uname -r at -plevel, so how to tell easily that
the world is at -plevel+1?
It doesn't presently exist.
That's precisely what the solution I proposed addresses.
In the complete solution I proposed,
'tail -1 /etc/{patchlog'
Or, for a program,
one can popen() that command, and read the output
or even
#include sys/patchlog
#include stdio.h
fd=fopen(PATCHLOG,r);
fseek(fd,PATCHLOG_LAST,SEEK_END);
fgets(line,sizeof(line),fd)
So when does it arrive in -CURRENT? :-)
The entire point of my proposal is to make it an IMMUTATABLE RECORD of
'what was done'. 'add to top' has several disadvantages. First,
a performance issue, you do have to read down the log to find the
first 'END' line rather than being able to seek directly to it.
Second, and the *BIG* one, you risk destroying the prior information
by re-writing the file. Third, it makes it easier for a 'malicious'
update to cover it's tracks.
Additionally, _undoing_ operations would also be logged - not
by omitting lines, but by a proper record that states how things
have been reverted to a previous level, which is also very good
for diagnostics.
If it's being done by automation, it can either log all the individual
'undo' changes, or just log a 'reverting to patchlevel {foo} line.
There are benefits to both approaches.
If it's a 'manual' reversion, there's no way to guarantee anything gets
added to the log.
Let's assume that the standard ways (freebsd-update, make installworld
or
Re: HOWTO: FreeBSD ZFS Madness (Boot Environments)
Randal == Randal L Schwartz mer...@stonehenge.com writes: vermaden == vermaden verma...@interia.pl writes: vermaden # fetch https://github.com/vermaden/beadm/blob/master/beadm Randal and after reboot, zfs set mountpoint=none zroot would also seem to Randal clean that up. Oh wait, it looks like zroot is still holding 1.04G of data... will that ever go away? Shouldn't all the data be in the /ROOT/xxx items? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Off topic: NetBSD or OpenBSD for Alpha server ?
Anton Shterenlikht me...@bristol.ac.uk wrote: On Fri, May 04, 2012 at 04:45:17PM -0400, Outback Dingo wrote: On Fri, May 4, 2012 at 3:56 PM, Erik N?rgaard norga...@locolomo.org wrote: On 04/05/2012 19:51, Kenneth Hatteland wrote: So I checked the 2 other main contenders and just wanted to ask if anyone here had an opinion what 2 install of the BSDs ? Or perhaps FreeBSD 6.4 is a good choice ( I have not tested Open or Net BSD so FreeBSD is my hometurf) The machine will probably be a server to have fun with and hopefully learn something from. Perhaps some server role in my rig, routing, security etc. Any advise would be nice :) QNX will not run on the Alpha architecture, freeBSD 6.4 in my opinion is still the far better choice for anything alpha the only other thing i would recommend oin that platorm would be OpenVMS from the hobbyist kit. But then again I only run real Operating systems on my Alphas :) 6.4 is way past EOL. It's irresponsible to recommend it. Dec ALPHAs are way past EOL. DEC, itself, is way past EOL. For obselete hardware one frequetly has no alternative but to run an obselete operating system. The OP has already decided on a *BSD. Recommending VMS, of any form, is not a 'helpful'/'responsive' response to his questions. You *don't*know* _why_ he has selected *BSD, so you have _no_ idea whether VMS is viable or his needs. Given that he -needs- a *BSD on _that_ hardware which which 'flavor' would you recomend? Or would you insist he discard that hardware and replace it with something current? inquiring minds want to know. *grin* ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: HOWTO: FreeBSD ZFS Madness (Boot Environments)
Randal == Randal L Schwartz mer...@stonehenge.com writes: Randal Oh wait, it looks like zroot is still holding 1.04G of data... will Randal that ever go away? Shouldn't all the data be in the /ROOT/xxx Randal items? And worse, the things from the readme don't work: locohost# ./beadm create upgrade cannot create 'zroot/ROOT/upgrade': invalid property '' cannot open 'zroot/ROOT/upgrade': dataset does not exist Created successfully So, no joy on this yet. This is FreeBSD 8.2. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: HOWTO: FreeBSD ZFS Madness (Boot Environments)
Randal == Randal L Schwartz mer...@stonehenge.com writes: Randal This is FreeBSD 8.2. And no difference on 8.3 :( Should there have been a promote in there somewhere? It looks like the boot env is still dependent on the very old zroot. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Off topic: NetBSD or OpenBSD for Alpha server ?
On Fri, 4 May 2012 17:11:00 -0500 (CDT), Robert Bonomi wrote: For obselete hardware one frequetly has no alternative but to run an obselete operating system. Depending on the actual intention of use, it _may_ be no problem to use obsolete operating systems and software. (For example, I still have a FreeBSD 5.4 system with lots of applications installed, perfectly working on a 300 MHz system, intended for special purposes; I would _never_ use that as a server facing the Internet!) The OP has already decided on a *BSD. Recommending VMS, of any form, is not a 'helpful'/'responsive' response to his questions. You *don't*know* _why_ he has selected *BSD, so you have _no_ idea whether VMS is viable or his needs. Given that he -needs- a *BSD on _that_ hardware which which 'flavor' would you recomend? Or would you insist he discard that hardware and replace it with something current? inquiring minds want to know. *grin* It there is a _required_ reason to run Alpha hardware, an older FreeBSD OS isn't a bad choice. Depending on the availability of sources (per /usr/ports of _that_ version) or of packages (from the installation media of _that_ version, or $PACKAGESITE pointing to the correct archives on the FreBSD FTP server), software can be installed. There's also the excellent tool portdowngrade. However, it may be a try miss to find out what software still runs, what _current_ software can be made running, and what operation procedures still work. This _ALL_ depends on what the system should be used for. Only the OP can decide about what applies, and what doesn't. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: help debug bwn(4) wireless
how about `ifconfig wlan0 mode 11b` 11g sticks very soon for me and some other people. Regards, Buganini 2012/5/5 Anton Shterenlikht me...@bristol.ac.uk: I've US Robotics 5411 wireless pccard device. It's identified as: # pciconf -lv *skip* siba_bwn0@pci0:3:0:0: class=0x028000 card=0x431814e4 chip=0x431814e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller' class = network and from dmesg: siba_bwn0: Broadcom BCM4318 802.11b/g Wireless mem 0xcc502000-0xcc503fff irq 20 at device 0.0 on cardbus0 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits) I've build a kernel with bwn(4), loaded the firmware module: # kldstat Id Refs Address Size Name 1 4 0x8020 104fb98 kernel 2 1 0x81412000 28aa1 bwn_v4_ucode.ko # I created wlan device: bwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:c0:49:58:00:fe nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:c0:49:58:00:fe inet 192.168.1.104 netmask 0xff00 broadcast 192.168.1.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid lagartixa channel 11 (2462 MHz 11g) bssid 00:18:39:e6:46:b6 country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL I run wpa_supplicant: # wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf Trying to associate with 00:18:39:e6:46:b6 (SSID='lagartixa' freq=2462 MHz) Associated with 00:18:39:e6:46:b6 WPA: Key negotiation completed with 00:18:39:e6:46:b6 [PTK=CCMP GTK=CCMP] CTRL-EVENT-CONNECTED - Connection to 00:18:39:e6:46:b6 completed (auth) [id=0 id_str=] I got issued the ip address by my wireless router. I see the card on the router: DHCP Active IP Table DHCP Server IP Address: 192.168.1.1 Client Host Name IP Address MAC Address Expires 192.168.1.104 00:c0:49:58:00:fe 23:58:54 I get /etc/resolve.conf set up automatically (through the wired connection): % cat /etc/resolv.conf # Generated by resolvconf search cable.virginmedia.net nameserver 194.168.4.100 nameserver 194.168.8.100 But I just can't get the wireless connection, even to the router: % ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ^C On the console I see: RX decryption attempted (old 0 keyidx 0x1) RX decryption attempted (old 0 keyidx 0x1) RX decryption attempted (old 0 keyidx 0x1) RX decryption attempted (old 0 keyidx 0x1) firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) Please help What am I doing wrong? What else can I try? Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-mob...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To unsubscribe, send any mail to freebsd-mobile-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: HOWTO: FreeBSD ZFS Madness (Boot Environments)
On 5/4/2012 5:10 PM, Randal L. Schwartz wrote: Randal == Randal L Schwartz mer...@stonehenge.com writes: Randal Oh wait, it looks like zroot is still holding 1.04G of data... will Randal that ever go away? Shouldn't all the data be in the /ROOT/xxx Randal items? And worse, the things from the readme don't work: locohost# ./beadm create upgrade cannot create 'zroot/ROOT/upgrade': invalid property '' cannot open 'zroot/ROOT/upgrade': dataset does not exist Created successfully So, no joy on this yet. This is FreeBSD 8.2. Hi, Those errors will be fixed in the next release, out in the next day or so. Still testing it. If you want to help test, it's out on vermaden's github right now. An updated port will be available soon as well. Regards, Bryan Drewery ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
4294967287 messages downloaded - Thunderbird
Hello list! What and why is this? 4294967287 messages downloaded It does not make sense. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
