Re: USB Drive not showing up correctly in 8.1 (works in 7.3)
Jerahmy Pocott wrote: > I have a USB Drive that was working fine under 7.3, but since > updating to 8.1 no longer has the correct /dev entries. Under > 7.3 it was da0s1, in 8.1 there is now only da0 and da0a, which > shouldn't exist... > > Any ideas on how to correct this problem? No, but you're not the first to notice 7.3 vs 8.1 disk-recognition differences: http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060472.html Adding usb@ in case they have any ideas. ___ 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"
Re: Could MSGBUF_SIZE be made a loader tunable?
Anyone had a chance to look at this? http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060793.html ___ 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"
Re: Policy on static linking ?
Hi On 16 January 2011 02:17, Jean-Yves Avenard wrote: > Hi > > On 15 January 2011 23:48, Jilles Tjoelker wrote: > >> >> The approach has been used by Debian for some time. >> >> Links: >> http://chris.dzombak.name/blog/2010/03/building-openssl-with-symbol-versioning/ >> http://chris.dzombak.name/files/openssl/openssl-0.9.8l-symbolVersioning.diff >> http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest > > This sounds very interesting. > > I do have trouble understanding on how this would make a difference > with how it's currently working. > > base openssl uses libssl.so.6 and libcrypto.so.6 > > current port openssl is using .so.7 > > So they too have different sonames; How could changing this to > .so.0.9.8 for base and so.1.0.2 for port make things behave > differently? Replying to myself.. Looking at the symbols in the openssl libraries found on a Ubuntu machine, I see what is going on: symbol name: X509_NAME_cmp@OPENSSL_0.9.8 vs X509_NAME_cmp This sounds like a great approach.. and should definitely resolve my problems I think. Are you sure both base and port needs to be patched? I would have assumed that patching only port would be sufficient (provided all tools depending on it are also recompiled) Jean-Yves ___ 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"
Re: Policy on static linking ?
Hi On 15 January 2011 23:48, Jilles Tjoelker wrote: > > The approach has been used by Debian for some time. > > Links: > http://chris.dzombak.name/blog/2010/03/building-openssl-with-symbol-versioning/ > http://chris.dzombak.name/files/openssl/openssl-0.9.8l-symbolVersioning.diff > http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest This sounds very interesting. I do have trouble understanding on how this would make a difference with how it's currently working. base openssl uses libssl.so.6 and libcrypto.so.6 current port openssl is using .so.7 So they too have different sonames; How could changing this to .so.0.9.8 for base and so.1.0.2 for port make things behave differently? JY ___ 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"
Re: geli problems after installkernel & installworld
On Sat, 15 Jan 2011 22:30:56 +0100 Pawel Jakub Dawidek wrote: > On Thu, Jan 13, 2011 at 10:00:19PM +0100, Christopher J. Ruwe wrote: > > I use a mostly geli encrypted hd on my Thinkpad R500, > > with /compat, /usr, /tmp and /var all on the encrypted geli > > provider. > > > > After an upgrade of kernel and world (STABLE), I experience a weird > > issue: While booting, I am asked for the geli passphrase as usual. > > Completing password authentication for geli returns a success > > message, > > > > cryptosoft0: on motherboard > > GEOM_ELI: Device ada0p3.eli created. > > GEOM_ELI: Encryption: AES-CBC 256 > > GEOM_ELI: Crypto: software > > > > however, the zpool on geli is unavailable. > > > > Logging in a root, I can attach the geli provider manually as geli > > itself should do from /etc/rc.conf. After a successful zfs mount > > -a, I can resume as usual after manually starting > > the /usr/local/rc.d services. > > > > Neither have I noticed a change in the device names nor any unusual > > messages from dmesg. Currently, I am doing a new compile run on > > world and kernel to attempt anew tomorrow. > > > > Am I missing something? > > Can you show the output of 'geli list' from a running system? > Sure I can ... I'll additionally comment the output with what I do to. First I boot and my /usr/local/rc.d/ - schripts do not start. Likewise does zsh. From doing geli list, I get (on stdout) Geom name: ada0p3.eli State: ACTIVE EncryptionAlgorithm: AES-CBC KeyLength: 256 Crypto: software UsedKey: 0 Flags: SINGLE-KEY, NATIVE-BYTE-ORDER, BOOT, RW-DETACH Providers: 1. Name: ada0p3.eli Mediasize: 249656594432 (233G) Sectorsize: 4096 Mode: r0w0e0 Consumers: 1. Name: ada0p3 Mediasize: 249656596992 (233G) Sectorsize: 512 Mode: r1w1e1 Doing a zpool status -v gives on stdout pool: ntank state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM ntank UNAVAIL 0 0 0 insufficient replicas ada0p3.eli UNAVAIL 0 0 0 cannot open pool: rpool state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 gptid/3ab00705-d22f-11df-8e1b-002713b40a7b ONLINE 0 0 0 errors: No known data errors and on stderr ( I noticed the output on stderr as I ran the command, so I just typed that) GEOM_ELI[1]: Device ada0p3.eli is still open, so it cannot be definitely removed. GEOM_ELI[1]: Detached ada0p3.eli on last close. When doing a geli attach -k /pathtomykey/key /dev/ada0p3 directly followed by a zfs mount -a, I have my filesystems where I am used to finding them. I run my /usr/local/rc.ds from there and am functional again. Then (I post this anwe, I will point out why later on), I get for geli list Geom name: ada0p3.eli State: ACTIVE EncryptionAlgorithm: AES-CBC KeyLength: 256 Crypto: software UsedKey: 0 Flags: SINGLE-KEY, NATIVE-BYTE-ORDER, BOOT Providers: 1. Name: ada0p3.eli Mediasize: 249656594432 (233G) Sectorsize: 4096 Mode: r1w1e1 Consumers: 1. Name: ada0p3 Mediasize: 249656596992 (233G) Sectorsize: 512 Mode: r1w1e1 I never noticed that before, but, as I did not know which geli output you were asking for (the one not working or the one working), I diffed the two files and noticed, that directly after booting, the RW-DETACH flag is set. I do not know what that means nor do I know whether that matters, I find that curious, though. Thank you for your help, have a nice Sunday, kind regards, -- Christopher J. Ruwe TZ GMT + 1 signature.asc Description: PGP signature
Re: Policy on static linking ?
On Sat, Jan 15, 2011 at 09:11:50PM +1100, Jean-Yves Avenard wrote:
> On Friday, 14 January 2011, Pete French wrote:
> > I build code using static linking for deployment across a set of
> > machines. For me this has a lot of advantages - I know that the
> > code will run, no matter what the state of the ports is on the
> > machine, and if there is a need to upgrade a library then I do it
> > once on the build machine, rebuild the executable, and rsync it out
> > to the leaf nodes. Only one place to track security updates, only
> > one place where I need to have all the porst the code depends on
> > installed.
> I actually tried to compile a port against another and have it link
> statically, but I couldn't find a way to do so without hacking the
> configure script. I was wondering if there was another (and easier)
> way to do so...
> I use ldap for authentication purposes, along with pam_ldap and nss_ldap
> If I compile openldap-client against openssl from ports, then it
> creates massive problems elsewhere.
> For example, base ssh server will now crash due to using different
> libcrypto. compiling ports will also become impossible as bsd tar
> itself crash (removing ldap call from nsswitch.conf is required to
> work again)
> I was then advised in the freebsd forums to uninstall openssl port,
> compile openldap against openssl base, install it, then re-install
> openssl port.
> (I have to use openssl from ports with apache/subversion to fix a bug
> with TLSv1 making svn commit crash under some circumstances)
> I dislike this method, because should openldap gets upgraded again and
> be linked against openssl port, I will lock myself out of the machine
> again due to sshd crashing. Just like what happened today :(
> So how can I configure openldap-client to link against libssl and
> libcrypto statically?
I think this can be solved with a symbol versioning trick. By applying a
different version to all symbols from each OpenSSL version, the dynamic
linker will be able to distinguish between different versions of OpenSSL
and will use the correct OpenSSL version each object was linked to, even
if there are multiple OpenSSL versions in the process. Note that each
OpenSSL version should still have its own SONAME (the security/openssl
port does this).
The version script can be as simple as (substituting the version)
OPENSSL_0.9.8 {
global:
*;
};
and needs to be in the top level and in the engines directory.
For it to work completely, both base and the port need to be patched.
Old binaries continue to work but the benefit only appears after
recompilation.
The SONAME needs to be bumped when the version string is changed or
deleted (but not when it is initially added), otherwise binaries will
stop working. This also means that making the change cannot be undone
without breaking binary compatibility.
What will not work is allocating an OpenSSL structure in one object
linked to one OpenSSL version and then using it in another object linked
to another OpenSSL version. That would require true symbol versioning,
keeping compatibility with old versions in the same library with the
same SONAME. Unlike the approach I propose, that would be a lot of work
and can only be done by the OpenSSL project, and I think their policy is
not to do such extra work for ABI compatibility. If they change their
mind they will probably start with the symver version of the previous
release so as to remain compatible with what various Linux distributions
are doing.
Also, a side effect is that it is no longer possible to cheat by
symlinking different OpenSSL versions.
The approach has been used by Debian for some time.
Links:
http://chris.dzombak.name/blog/2010/03/building-openssl-with-symbol-versioning/
http://chris.dzombak.name/files/openssl/openssl-0.9.8l-symbolVersioning.diff
http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest
--
Jilles Tjoelker
___
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"
Re: geli problems after installkernel & installworld
On Thu, Jan 13, 2011 at 10:00:19PM +0100, Christopher J. Ruwe wrote: > I use a mostly geli encrypted hd on my Thinkpad R500, > with /compat, /usr, /tmp and /var all on the encrypted geli provider. > > After an upgrade of kernel and world (STABLE), I experience a weird > issue: While booting, I am asked for the geli passphrase as usual. > Completing password authentication for geli returns a success message, > > cryptosoft0: on motherboard > GEOM_ELI: Device ada0p3.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Crypto: software > > however, the zpool on geli is unavailable. > > Logging in a root, I can attach the geli provider manually as geli > itself should do from /etc/rc.conf. After a successful zfs mount -a, I > can resume as usual after manually starting the /usr/local/rc.d > services. > > Neither have I noticed a change in the device names nor any unusual > messages from dmesg. Currently, I am doing a new compile run on world > and kernel to attempt anew tomorrow. > > Am I missing something? Can you show the output of 'geli list' from a running system? -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpQCk7rcAddp.pgp Description: PGP signature
Re: kern/138341: [nanobsd] [patch] 8.0-BETA3: nanobsd build broken due to sysipc kernel module
'make MODULES_WITH_WORLD=yes buildworld' is still broken for 8.2-PRERELEASE.
Here is a patch for RELENG_8 sources updated today:
--- sys/modules/cryptodev/Makefile.orig 2010-08-23 12:13:44.0 +0700
+++ sys/modules/cryptodev/Makefile 2010-08-23 12:13:52.0 +0700
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../opencrypto
KMOD = cryptodev
SRCS = cryptodev.c
-SRCS += bus_if.h device_if.h
+SRCS += bus_if.h device_if.h opt_compat.h
.include
--- sys/modules/dtrace/lockstat/Makefile.orig 2009-09-16 23:05:25.0
+0800
+++ sys/modules/dtrace/lockstat/Makefile2009-09-16 23:05:45.0
+0800
@@ -5,7 +5,7 @@
KMOD= lockstat
SRCS= lockstat.c
-SRCS+= vnode_if.h
+SRCS+= vnode_if.h opt_kdtrace.h
CFLAGS+= -I${.CURDIR}/../../../cddl/compat/opensolaris \
-I${.CURDIR}/../../../cddl/contrib/opensolaris/uts/common \
--- sys/modules/mqueue/Makefile.orig2010-04-24 17:47:03.0 +0700
+++ sys/modules/mqueue/Makefile 2010-04-24 17:47:14.0 +0700
@@ -5,6 +5,6 @@
KMOD= mqueuefs
SRCS= uipc_mqueue.c \
vnode_if.h \
- opt_posix.h
+ opt_posix.h opt_compat.h
.include
--- sys/modules/sysvipc/sysvmsg/Makefile.orig 2009-08-30 19:12:16.0
+0800
+++ sys/modules/sysvipc/sysvmsg/Makefile2009-09-19 01:12:18.0
+0800
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../../kern
KMOD= sysvmsg
-SRCS= sysv_msg.c opt_sysvipc.h
+SRCS= sysv_msg.c opt_sysvipc.h opt_compat.h
.include
--- sys/modules/sysvipc/sysvsem/Makefile.orig 2009-08-30 19:52:13.0
+0800
+++ sys/modules/sysvipc/sysvsem/Makefile2009-08-30 19:52:33.0
+0800
@@ -3,6 +3,6 @@
.PATH: ${.CURDIR}/../../../kern
KMOD= sysvsem
-SRCS= sysv_sem.c opt_sysvipc.h
+SRCS= sysv_sem.c opt_sysvipc.h opt_compat.h
.include
___
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"
Re: Policy on static linking ?
On 1/15/2011 5:11 AM, Jean-Yves Avenard wrote: > If I compile openldap-client against openssl from ports, then it > creates massive problems elsewhere. [snip problems] > I dislike this method, because should openldap gets upgraded again and > be linked against openssl port, I will lock myself out of the machine > again due to sshd crashing. Just like what happened today :( Problems like that are why I do my package compiling in a jail, or a VM, and not on a live system. Jails are simple to setup these days and it's handy to be able to just blow away the jail and recreate it if things go wonky with dependencies when experimenting with package builds. (Or snapshot a VM before trying) I've taken a stab or two at compiling ports static in the past and also came up empty. It would be really nice to be able to build a single tbz package that would run once installed and that didn't have to pull down every other dependency individually. There are a number of ways that dependency tracking with packages can go sideways, and it isn't fun when trying to ensure that said packages install OK when transplanting them to other machines... Jim ___ 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"
Re: i386/153947: Make buildworld fails in hastd/token.c
This also breaks source upgrade path from RELENG_7. ___ 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"
Re: Policy on static linking ?
On Friday, 14 January 2011, Pete French wrote: > I build code using static linking for deployment across a set of > machines. For me this has a lot of advantages - I know that the > code will run, no matter what the state of the ports is on the > machine, and if there is a need to upgrade a library then I do it > once on the build machine, rebuild the executable, and rsync it out > to the leaf nodes. Only one place to track security updates, only > one place where I need to have all the porst the code depends on > installed. I actually tried to compile a port against another and have it link statically, but I couldn't find a way to do so without hacking the configure script. I was wondering if there was another (and easier) way to do so... I use ldap for authentication purposes, along with pam_ldap and nss_ldap If I compile openldap-client against openssl from ports, then it creates massive problems elsewhere. For example, base ssh server will now crash due to using different libcrypto. compiling ports will also become impossible as bsd tar itself crash (removing ldap call from nsswitch.conf is required to work again) I was then advised in the freebsd forums to uninstall openssl port, compile openldap against openssl base, install it, then re-install openssl port. (I have to use openssl from ports with apache/subversion to fix a bug with TLSv1 making svn commit crash under some circumstances) I dislike this method, because should openldap gets upgraded again and be linked against openssl port, I will lock myself out of the machine again due to sshd crashing. Just like what happened today :( So how can I configure openldap-client to link against libssl and libcrypto statically? Thanks ___ 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"
Re: Next ZFSv28 patchset ready for testing.
To use with newer stable (or releng/8.2) use a more recent patch from: http://people.freebsd.org/~mm/patches/zfs/v28/ Cheers, mm Dňa 14.01.2011 18:19, Christopher J. Ruwe wrote / napísal(a): > Hi, > > I would like to test Martin Matuskas patch for ZFS v28 against stable. > Can I patch against any stable (like stable of today) or does it > necessarily need to be the stable-tree of the date specified in the > patch-file? > > If the latter should be true, how do I obtain a stable tree of any > given date? > > Thanks for any help, kind regards, ___ 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"
