gmane.os.freebsd.devel.hackers

Bug in qmail port's Makefile, where to report?

Joe Schaefer — 2013-06-18T22:38:17

I looked on freshports for a way to file a bug report but didn't see
anything.
I have a one-character patch to the Makefile that needs incorporation.
Any tips for how to contact the ports maintainers for qmail?

Thx.
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

how do I build a single app?

2013-06-17T15:42:16

Hi,

I installed FreeBSD into a VirtualBox VM in January and started playing with the code. I must complement you people on the clarity of your code. I've enjoyed examining it.

I wanted to try some code changes to some of the apps in the /bin directory, but can't figure out how to build a single app, or even build a single set of apps, like /usr/src/bin, /usr/src/sbin, /usr/src/usr.bin, or /usr/src/usr.sbin. Is there a way to do this, or do I just have to create my own Makefiles for each app I am experimenting on?

If this is the wrong place to ask this question, I appologize and ask you to direct me to a mailing list that would be the appropriate place to ask this.

Sincerely,

David Lee from Tennessee
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

9.1 stage 2 boot

2013-06-15T18:58:42

The FreeBSD boot(8) block now supports /boot/config in addition to /boot.config as the boot block parameter file.
When both of them exist, the former will be used.[r231287]

Just to test it I've:
# echo '-s' > /boot.config

Then
# mv -v /boot/config /boot.config

Whichever is used, stage 2 boot, always claims it is /boot/config file and prints it's contest.
This is a tiny bug.

Just asking, what is the main benefit of additional /boot/config file?


Domagoj Smolčić
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

WhatsApp Messenger: iPhone + Android + Nokia + BlackBerry + Windows Phone

2013-06-14T20:16:18

Hey,

I just downloaded WhatsApp Messenger on my iPhone.

It is a Smartphone Messenger that replaces SMS. This app even lets me send pictures, video and other multimedia!

WhatsApp Messenger is available for iPhone, Android, Nokia, BlackBerry and Windows Phone. There's no PIN or username to remember - it works just like SMS but uses your Internet data plan.

Get it now from http://www.whatsapp.com/download/ and say good-bye to SMS.



my.linkedin.com/pub/yb-tan-sri-dato-ir-adli-a-k-a-dell/44/64b/464/
Sent from my iPhone
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

panic: vfs_mount_destroy: nonzero activevnodelistsize

2013-06-13T18:33:20

http://forums.freebsd.org/showthread.php?p=223457
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

Exposing driver's GPIOs through gpiobus

Ryan Stone — 2013-06-13T03:36:04

At $WORK we have some custom boards with multi-port uarts managed by puc.
The uart devices happen to provide some GPIOs, and our hardware designers
have appropriated those GPIOs for various purposes entirely unrelated to
the uart.

I'm looking for a clean way to provide access to the GPIOs.  It occurred to
me that this was a problem that should be solved through newbus, and lo and
behold I have discovered that FreeBSD provides a gpiobus driver that seems
suitable.  I've been playing around with this for a couple of days and I
have a solutions that is working, but there are aspects that I am unhappy
with.  I also quite unfamiliar with newbus, so there easily could be better
ways to approach the problem that I haven't thought of.

What I ended up doing was making gpiobus and gpioc children of the puc
bus.  In puc_bfe_attach() I create two new child devices of the puc device
with device_add_child(), one with the gpioc devclass and one with the
gpiobus devclass.  I then attach both children with
device_probe_and_attach().  I make the puc_pci driver itself provide
implementations of the various gpio methods (like gpio_pin_get) so they can
be inherited by the child devices.

Things start to get somewhat messy in the gpio client code.  I have the
same image running on many different hardware types, so I can't use device
hints to create a child device of the gpiobus.  Instead my kernel module
tracks down the device_t for the puc, finds the gpiobus child, and uses
BUS_ADD_CHILD to create a child of the gpiobus.  I had to add a new gpiobus
method to allocate GPIO pins to my driver instance.  Once that's done, I
can toggle GPIOs and whatnot using methods on my driver instance.

The things that I'm most unhappy with (newbus-wise, anyway) are:

1) By default the gpioc and gpiobus drivers were claiming the uart children
of the puc.  I had to decrease their priority in bus_probe to
BUS_PROBE_LOW_PRIORITY to work around the problem.  I really don't think
that was the right solution.  I guess I could introduce a new device that
is a child of the puc, make sure that it will not claim the uarts, and then
make the gpioc and gpiobus children of this device.

2) I'm not sure how to clean up my child device when my module is
unloaded.  Currently I am checking if it already exists on load and reusing
it if so.  I may be missing something obvious here.

3) I really don't like the way that I am adding my child to gpiobus.  Upon
writing this it occurs to me that device_identify would be the canonical
way to do this.  Previously it wasn't clear to me how to fit
device_identify into the current architecture of the gpio client but I see
how it can be done now.
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base?

Baptiste Daroussin — 2013-06-11T22:11:24

Hi,

I have been working in importing tradcpp (developped by David A. Holland from
NetBSD) into the ports tree, it is a traditional (K&R-style) C macro
preprocessor BSD licensed. I first worked on it so that imake can work properly
without gcc.

I discovered that some part of the base system still needs a traditional
preprocessor, like (calendar), what I propose it to import tradcpp into the base
system (not the version in port right now but what will become version 0.2).

It mostly behave like gcpp, and I'm able to properly use calendar along with
tradcpp with this small patch: http://people.freebsd.org/~bapt/tradcpp.diff

Any objections against me importing it?

regards,
Bapt

Where is stack of program?

Vagner — 2013-06-10T16:44:25

Hi!
I need method of finding in struct vm_map or vm_object segments of
memory which is situated in the stack.
Can you help me please?

Network Recieve Performance Working Group

George Neville-Neil — 2013-06-09T21:04:49

Howdy,

At the Network Receive Performance working group at BSDCan we covered a narrower set of topics
than we normally do, which seems to have resulted in a reasonably sized work list for improving
our systems in this area. The main issues relate to getting a good API that addresses multi-queue
NICs. The notes are on the WIki page as well as reproduced here.

Best,
George

https://wiki.freebsd.org/201305DevSummit/NetworkReceivePerformance

The discussion opened with an attempt to constrain the problem we were trying to solve, including pointing out that any KPI/API suggested needed to be achievable in the next six months.

Some of the existing solutions to the problem of talking to hardware with multiple queues, which all high end NICs currently have, were:

• Connection Groups
• Not really a KPI
• RSS vs. Flow Table is an issue to solve, we have things for the former, but little for the latter
• Socket affinity is also an issue
• NAPI
• This is an APi in Linux. It uses upcalls.
• Flow table mapping. Chelsio may have some of this.
• SRIO
• VLL Cloner
There are several ways to map flows, including: 4 tuple, MAC filter, arbitrary offset. An API that only handles offset, length, value is too simple from the standpoint of getting the right data into the hardware. We need something more rich on the kernel side of the API to that driver writers don't have to figure out our intentions.

Some methods that a good KPI/API ought to have include:

• Query Device for information about its queues, including how many exist, and how they are mapped to other resources, including CPU and memory
• Map CPUID to a Flow
• Setup RSS
• Request RxRing local memory
• Solaris Mapping API might be a way to go (http://www.oracle.com/technetwork/articles/servers-storage-admin/crossbowsetup-191326.pdf)
•
Some consumers of such an API include: Performance, affinity, virtualization, policy, kernel bypass, QoS, and VIMAGE.

We have two patches, for different bits, to start from including Vijay's [RobertWatson] and Randall's [RandallStewart], [GeorgeNevilleNeil]

We need quite a few things, including:

• Per connection flow table
• Describing queues in the stack such that we can expose interesting parts via netstat.
• Packet Batching. This was not overwhelmingly popular.
A straw person API includes:

• MBUF Flag
• Hash Value
• The whole thing may be used as opaque
• Used by the stack for inpcb
• Get number of buckets
• Map bucket to RSS
• Map queue/ithread to CPU
• Get width of the hash
• RSS get CPU
• RSS get hash algo
• Pick hash inputs
• Get and set key
• Rebalance
• Software hash table
• Query queue length
• Get queue affinity
• Set mask (CPUSET) on socket
• Set policy on CPU/socket
• Queue event reporting
• Load distrubtion stats

_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

Beyond Buildworld Dev Summit Working Group Report

George Neville-Neil — 2013-06-09T21:02:22

Howdy,

The Beyond Buildworld working group discussed many subjects around our build system, including
upcoming changes to do a better job of addressing embedded systems, the integration of bmake,
and the need for better incremental build support.  The full notes are on the wiki and 
also pasted at the bottom of this email.

Best,
George

https://wiki.freebsd.org/201305DevSummit/Buildworld

This section includes volunteers or contact points as links.

• uboot ports [DianeBruce]
• compiler patches vs. gccc on Linux [TimKeintzle]
• ubloader not on ELF [Ian]
• uboot API [GeorgeNevilleNeil]
• FDT for MIPS and ARM 4/5 [RobertWatson]
• Unify Loaders [RobertWatson]
• Parallel Build Enhanced [SimonGarrety]
• projects/bmake
• switch date?
• review [WarnerLosh], [BrooksDavis], [GarretCooper]
• Cross Build [BrooksDavis]
• Depends on bmake
• toochains.mk [SimonGarrety]
• LLVM binutils [DavidChisnal]
• Kerberos build issue [GlenBarber]
• Crochet with VM images [TimKeintzle], [GlenBarber], [ColinPercival]
• Integrate make.conf into source tree [SimonGarrety]
• Dump src.conf and make.conf during buildworld [GeorgeNevilleNeil]
• Build config files not in the tree [GeorgeNevilleNeil]
• Kernel build issues [GarretCooper]
• modules
• options
• Packages built from the source tree [BaptisteDaroussin]
• clang/LLVM test suite [DavidChisnall]
• Tinderbox Test Cluster [GeorgeNevilleNeil]
• Source Tinderbox Redport [GlenBarber], [BernhardFroehlich], [GarretCooper]
• Anyone can revert any change to deal with build breakage, and this needs to be better socialized by core< at >
• Build Bot [MarcelMoolenaar]
• Cross build subset of user land [AdrianChadd]
• Build from hosts that are not FreeBSD, aka MacOS etc. [MarcelMoolenaar]

_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

Fix MNAMELEN or reimplement struct statfs

Dirk Engling — 2013-06-08T22:52:11

The arbitrary value

#define MNAMELEN        88              /* size of on/from name bufs */

struct statfs {
[...]
charf_mntfromname[MNAMELEN];/* mounted filesystem */
charf_mntonname[MNAMELEN];/* directory on which mounted */
};

currently bites us when trying to use poudriere with errors like

'mount: tmpfs: File name too long'

/poudriere/data/build/91_RELEASE_amd64-REALLY-REALLY-LONG-JAILNAME/ref/wrkdirs

The topic has been discussed several times since 2004 and has been
postponed each time, the last time when it hit zfs users:

http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html

So I'd like to point to the calendar, it's 2013 already and there's
still a static arbitrary (and way too low) limit in one of the core
areas of the vfs code.

So I'd like to bump the issue and propose either making f_mntfromname a
dynamic allocation or just increase MNAMELEN, using 10.0 as water shed.

Regards,

  erdgeist
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

[patch] TLS Server Name Indication (SNI) support for fetch(1)

Sofian Brabez — 2013-06-08T20:56:53

Hi,

fetch(1) currently does not support TLS extension Server Name Indication (RFC
6066) [1] when dealing with SSL. Nowadays lot of clients and servers implement
this extension.

Using the TLS SNI Test website sni.velox.ch [2], the test fails in r251550:

% fetch -o out https://sni.velox.ch/ && grep 'libfetch' out
fetch: https://sni.velox.ch/: size of remote file is not known
out                                                   5101  B  134 kBps 00m00s
<p><strong>Unfortunately, your client </strong>[fetch libfetch/2.0] <strong>

After patching lib/libfetch with my changes:

% cd /usr/src/lib/libfetch
% patch -p0 < <(fetch -o - http://people.freebsd.org/~sbz/fetch_ssl_sni.diff)

And after rebuilding lib/libfetch library and usr.bin/fetch program, the test
suceeded:

% fetch -o out https://sni.velox.ch/ &&  grep 'libfetch' out
fetch: https://sni.velox.ch/: size of remote file is not known
out                                                   5063  B  104 kBps 00m00s
<p><strong>Great! Your client </strong>[fetch libfetch/2.0] <strong>

Our OpenSSL version 1.0.1c in base support this extension already. s_client too
using -servername argument:

% openssl version
OpenSSL 1.0.1c-freebsd 10 May 2012
% openssl s_client -h 2>&1| grep servername
 -servername host  - Set TLS extension servername in ClientHello
% openssl s_client -connect sni.velox.ch:443 -servername sni.velox.ch -tlsextdebug 2>/dev/null|grep 'extension'
TLS server extension "server name" (id=0), len=0
TLS server extension "renegotiation info" (id=65281), len=1
TLS server extension "EC point formats" (id=11), len=4
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1

You will find the patch here [3] and as inline attachment.

Is it OK for your des< at > ?

Regards

[1] http://en.wikipedia.org/wiki/Server_Name_Indication
[2] https://sni.velox.ch/
[3] http://people.freebsd.org/~sbz/fetch_ssl_sni.diff

--
Sofian Brabez

question in sosend_generic()

vasanth rao naik sabavat — 2013-06-07T22:16:17

Hi,

When sending data out of the socket I don't see in the code where the sb_cc
is incremented.

Is the socket send performed in the same thread of execution or the data is
copied on to the socket send buffer and a different thread then sends the
data out of the socket?

Because, I see a call to sbwait(&so->so_snd) in the sosend_generic and I
don't understand who would wake up this thread?

If the data is not copied on to the socket buffers then it should
technically send all data out in the same thread of execution and future
socket send calls should see that space is always fully available. In that
case I dont see a reason why we need to wait on the socket send buffer. As
there would no one who will actually wake you up.

                if (space < resid + clen &&
                    (atomic || space < so->so_snd.sb_lowat || space <
clen)) {
                        if ((so->so_state & SS_NBIO) || (flags & MSG_NBIO))
{
                                SOCKBUF_UNLOCK(&so->so_snd);
                                error = EWOULDBLOCK;
                                goto release;
                        }
                        error = sbwait(&so->so_snd);
                        SOCKBUF_UNLOCK(&so->so_snd);
                        if (error)
                                goto release;
                        goto restart;
                }

In the above code snippet, for a blocking socket if the space is not
available, then it may trigger a deadlock?

please clarify.

A way to switch off nVidia discrete cards ?

Florent Peterschmitt — 2013-06-07T23:57:14

Hi,

I've absolutely no skill in system development but I think, based on 
bbswitch (which is part of bumblebee project), that doing such a think 
would not be too difficult.

I have a 9.1-RELEASE FreeBSD which I'm going to upgrade to -current, for 
testing and developing purpose so, is there any documentation or little 
how-to of how to develop for FreeBSD, in the kernel, using access to 
hardware and ACPI ?

Thanks
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

openstack under virtualbox

Aryeh Friedman — 2013-06-07T19:19:54

I have been banging my head for almost 3 weeks now to get openstack
(nova and glance only or what ever the min is), I have tried essex and
currdntly attempting grizzly, it gets all way the point of making
instances but the instances are unreachable (by tcp/ip but the console
works fine)... using devstack it does work... I am just wondering if
there is anything weird people have encountered here... note the vbox
host (I will be moving it to real hardware once vb works) is:

FreeBSD scoobySnax3 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Thu May
23 01:01:35 EDT 2013     root< at >scoobySnax3:/usr/obj/usr/src/sys/GENERIC
 amd64

and the first image I want to install once it working is the rackspace
freebsd image
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

[PATCH] Install standalone debug files in /usr/lib/debug

Ed Maste — 2013-06-06T18:51:37

Add a new knob WITH_DEBUG_FILES to control the building of standalone
debug files for userland programs and libraries.  The "-g" debug flag
is automatically applied when WITH_DEBUG_FILES is set.

The debug files are now named ${prog}.debug and ${shlib}.debug for
consistency with other systems and documentation.  In addition they are
installed under /usr/lib/debug, to simplify the process of installing
them if needed after a crash.  Users of bsd.{prog,lib}.mk outside of the
base system place the standalone debug files in a .debug subdirectory.
GDB automatically searches both of these directories for standalone
debug files.

Thanks to everyone who contributed changes, review, and testing during
development.
---
Changes since previous version of the patch:
. some cleanup suggested by brooks< at > and kib< at >
. separate debug tree into separate mtree file
. use new DEBUGMODE variable rather than BINMODE / LIBMODE, to avoid
  suid or sgid debug files

 Makefile.inc1                           | 15 ++++++++
 etc/Makefile                            |  6 ++++
 etc/mtree/BSD.debug.dist                | 48 +++++++++++++++++++++++++
 etc/mtree/Makefile                      |  4 +++
 gnu/usr.bin/gdb/Makefile.inc            |  1 +
 gnu/usr.bin/gdb/arch/amd64/config.h     |  3 --
 gnu/usr.bin/gdb/arch/arm/config.h       |  3 --
 gnu/usr.bin/gdb/arch/i386/config.h      |  3 --
 gnu/usr.bin/gdb/arch/ia64/config.h      |  3 --
 gnu/usr.bin/gdb/arch/mips/config.h      |  3 --
 gnu/usr.bin/gdb/arch/powerpc/config.h   |  3 --
 gnu/usr.bin/gdb/arch/powerpc64/config.h |  3 --
 gnu/usr.bin/gdb/arch/sparc64/config.h   |  3 --
 gnu/usr.bin/gdb/gdb/Makefile            |  1 +
 share/mk/bsd.crunchgen.mk               |  3 ++
 share/mk/bsd.lib.mk                     | 37 +++++++++++++------
 share/mk/bsd.own.mk                     | 10 ++++++
 share/mk/bsd.prog.mk                    | 63 +++++++++++++++++++++++++++++----
 tools/build/options/WITH_DEBUG_FILES    |  7 ++++
 19 files changed, 178 insertions(+), 41 deletions(-)
 create mode 100644 etc/mtree/BSD.debug.dist
 create mode 100644 tools/build/options/WITH_DEBUG_FILES

diff --git a/Makefile.inc1 b/Makefile.inc1
index f09aa97..d65dd31 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
< at >< at > -470,6 +470,13 < at >< at > _worldtmp:
 mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
     -p ${WORLDTMP}/usr/include >/dev/null
 ln -sf ${.CURDIR}/sys ${WORLDTMP}
+.if ${MK_DEBUG_FILES} != "no"
+# We could instead disable debug files for these build stages
+mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+    -p ${WORLDTMP}/legacy/usr/lib >/dev/null
+mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+    -p ${WORLDTMP}/usr/lib >/dev/null
+.endif
 .if ${MK_BIND_LIBS} != "no"
 mtree -deU -f ${.CURDIR}/etc/mtree/BIND.include.dist \
     -p ${WORLDTMP}/usr/include >/dev/null
< at >< at > -555,6 +562,10 < at >< at > build32:
     -p ${LIB32TMP}/usr >/dev/null
 mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
     -p ${LIB32TMP}/usr/include >/dev/null
+.if ${MK_DEBUG_FILES} != "no"
+mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+    -p ${LIB32TMP}/usr/lib >/dev/null
+.endif
 mkdir -p ${WORLDTMP}
 ln -sf ${.CURDIR}/sys ${WORLDTMP}
 .for _t in obj includes
< at >< at > -779,6 +790,10 < at >< at > distributeworld installworld: installcheck installcheck_UGID
     -p ${DESTDIR}/${DISTDIR}/${dist}/usr >/dev/null
 mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
     -p ${DESTDIR}/${DISTDIR}/${dist}/usr/include >/dev/null
+.if ${MK_DEBUG_FILES} != "no"
+mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+    -p ${DESTDIR}/${DISTDIR}/${dist}/usr/lib >/dev/null
+.endif
 .if defined(NO_ROOT)
 ${IMAKEENV} nmtree -C -f ${.CURDIR}/etc/mtree/BSD.root.dist | \
     sed -e 's#^\./#./${dist}/#' >> ${METALOG}
diff --git a/etc/Makefile b/etc/Makefile
index c0806e8..f509a19 100644
--- a/etc/Makefile
+++ b/etc/Makefile
< at >< at > -143,6 +143,9 < at >< at > MTREE+=BIND.chroot.dist
 MTREE+=BIND.include.dist
 .endif
 .endif
+.if ${MK_DEBUG_FILES} != "no"
+MTREE+=BSD.debug.dist
+.endif
 
 PPPCNF=ppp.conf
 
< at >< at > -312,6 +315,9 < at >< at > MTREES=mtree/BSD.root.dist/\
 mtree/BSD.var.dist/var\
 mtree/BSD.usr.dist/usr\
 mtree/BSD.include.dist/usr/include
+.if ${MK_DEBUG_FILES} != "no"
+MTREES+=mtree/BSD.debug.dist/usr/lib
+.endif
 .if ${MK_BIND_LIBS} != "no"
 MTREES+=mtree/BIND.include.dist/usr/include
 .endif
diff --git a/etc/mtree/BSD.debug.dist b/etc/mtree/BSD.debug.dist
new file mode 100644
index 0000000..ab75d0f
--- /dev/null
+++ b/etc/mtree/BSD.debug.dist
< at >< at > -0,0 +1,48 < at >< at >
+# $FreeBSD$
+#
+# Please see the file src/etc/mtree/README before making changes to this file.
+#
+
+/set type=dir uname=root gname=wheel mode=0755
+.
+    debug
+        bin
+        ..
+        boot
+        ..
+        lib
+            geom
+            ..
+        ..
+        libexec
+        ..
+        sbin
+        ..
+        usr
+            bin
+            ..
+            games
+            ..
+            lib
+                engines
+                ..
+            ..
+            lib32
+            ..
+            libexec
+                bsdinstall
+                ..
+                lpr
+                    ru
+                    ..
+                ..
+                sendmail
+                ..
+                sm.bin
+                ..
+            ..
+            sbin
+            ..
+        ..
+    ..
+..
diff --git a/etc/mtree/Makefile b/etc/mtree/Makefile
index 15da1bf..06aeb19 100644
--- a/etc/mtree/Makefile
+++ b/etc/mtree/Makefile
< at >< at > -4,6 +4,7 < at >< at >
 
 FILES=${_BIND.chroot.dist} \
 ${_BIND.include.dist} \
+${_BSD.debug.dist} \
 BSD.include.dist \
 BSD.root.dist \
 ${_BSD.sendmail.dist} \
< at >< at > -16,6 +17,9 < at >< at > _BIND.chroot.dist=BIND.chroot.dist
 _BIND.include.dist=BIND.include.dist
 .endif
 .endif
+.if ${MK_DEBUG_FILES} != "no"
+_BSD.debug.dist=BSD.debug.dist
+.endif
 .if ${MK_GROFF} != "no"
 _BSD.groff.dist=BSD.groff.dist
 .endif
diff --git a/gnu/usr.bin/gdb/Makefile.inc b/gnu/usr.bin/gdb/Makefile.inc
index c40e9b8..5e1d5cd 100644
--- a/gnu/usr.bin/gdb/Makefile.inc
+++ b/gnu/usr.bin/gdb/Makefile.inc
< at >< at > -37,6 +37,7 < at >< at > GDB_CROSS_DEBUGGER=
 ${CNTRB_GDB}/gdb/signals ${CNTRB_GDB}/gdb/tui ${TARGET_SUBDIR}
 
 CFLAGS+= -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1
+CFLAGS+= -DDEBUGDIR=\"${DEBUGDIR}\"
 CFLAGS+= -I.
 CFLAGS+= -I${TARGET_SUBDIR}
 CFLAGS+= -I${BMAKE_BU}/libbfd -I${BMAKE_BU}/libbfd/${TARGET_CPUARCH}
diff --git a/gnu/usr.bin/gdb/arch/amd64/config.h b/gnu/usr.bin/gdb/arch/amd64/config.h
index ac81c54..674f818 100644
--- a/gnu/usr.bin/gdb/arch/amd64/config.h
+++ b/gnu/usr.bin/gdb/arch/amd64/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_i386_arch
 
diff --git a/gnu/usr.bin/gdb/arch/arm/config.h b/gnu/usr.bin/gdb/arch/arm/config.h
index e1b128c..b2481f8 100644
--- a/gnu/usr.bin/gdb/arch/arm/config.h
+++ b/gnu/usr.bin/gdb/arch/arm/config.h
< at >< at > -451,9 +451,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_arm_arch
 
diff --git a/gnu/usr.bin/gdb/arch/i386/config.h b/gnu/usr.bin/gdb/arch/i386/config.h
index f21da4c..e849e0a 100644
--- a/gnu/usr.bin/gdb/arch/i386/config.h
+++ b/gnu/usr.bin/gdb/arch/i386/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_i386_arch
 
diff --git a/gnu/usr.bin/gdb/arch/ia64/config.h b/gnu/usr.bin/gdb/arch/ia64/config.h
index 5faa96b..4cc29f9 100644
--- a/gnu/usr.bin/gdb/arch/ia64/config.h
+++ b/gnu/usr.bin/gdb/arch/ia64/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_ia64_arch
 
diff --git a/gnu/usr.bin/gdb/arch/mips/config.h b/gnu/usr.bin/gdb/arch/mips/config.h
index 41a6731..2b375a6 100644
--- a/gnu/usr.bin/gdb/arch/mips/config.h
+++ b/gnu/usr.bin/gdb/arch/mips/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_mips_arch
 
diff --git a/gnu/usr.bin/gdb/arch/powerpc/config.h b/gnu/usr.bin/gdb/arch/powerpc/config.h
index f169fad..37416a7 100644
--- a/gnu/usr.bin/gdb/arch/powerpc/config.h
+++ b/gnu/usr.bin/gdb/arch/powerpc/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_rs6000_arch
 
diff --git a/gnu/usr.bin/gdb/arch/powerpc64/config.h b/gnu/usr.bin/gdb/arch/powerpc64/config.h
index d8b9b6d..58843fb 100644
--- a/gnu/usr.bin/gdb/arch/powerpc64/config.h
+++ b/gnu/usr.bin/gdb/arch/powerpc64/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_rs6000_arch
 
diff --git a/gnu/usr.bin/gdb/arch/sparc64/config.h b/gnu/usr.bin/gdb/arch/sparc64/config.h
index 5527a79..974e426 100644
--- a/gnu/usr.bin/gdb/arch/sparc64/config.h
+++ b/gnu/usr.bin/gdb/arch/sparc64/config.h
< at >< at > -439,9 +439,6 < at >< at >
 /* Name of this package.  */
 #define PACKAGE "gdb"
 
-/* Global directory for separate debug files.  */
-#define DEBUGDIR "/usr/local/lib/debug"
-
 /* Define to BFD's default architecture.  */
 #define DEFAULT_BFD_ARCH bfd_sparc_arch
 
diff --git a/gnu/usr.bin/gdb/gdb/Makefile b/gnu/usr.bin/gdb/gdb/Makefile
index ef9e135..15eb2eb 100644
--- a/gnu/usr.bin/gdb/gdb/Makefile
+++ b/gnu/usr.bin/gdb/gdb/Makefile
< at >< at > -15,3 +15,4 < at >< at > DPADD=${GDBLIBS} ${BULIBS} ${LIBM} ${LIBREADLINE} ${LIBTERMCAP} ${LIBGNUREGEX}
 LDADD=${GDBLIBS} ${BULIBS} -lm -lreadline -ltermcap -lgnuregex
 
 .include <bsd.prog.mk>
+CFLAGS+=-DDEBUGDIR=\"${DEBUGDIR}\"
diff --git a/share/mk/bsd.crunchgen.mk b/share/mk/bsd.crunchgen.mk
index 95f1aa3..d8f07b1 100644
--- a/share/mk/bsd.crunchgen.mk
+++ b/share/mk/bsd.crunchgen.mk
< at >< at > -47,6 +47,9 < at >< at > CRUNCH_GENERATE_LINKS?=yes
 
 CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h
 
+# Don't try to extract debug info from ${PROG}.
+NO_DEBUG_FILES=
+
 # Program names and their aliases contribute hardlinks to 'rescue' executable,
 # except for those that get suppressed.
 .for D in $(CRUNCH_SRCDIRS)
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index cb2544c..fe2efb4 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
< at >< at > -43,6 +43,11 < at >< at > CTFFLAGS+= -g
 STRIP?=-s
 .endif
 
+.if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g*)
+CFLAGS+= -g
+CTFFLAGS+= -g
+.endif
+
 .include <bsd.libnames.mk>
 
 # prefer .s to a .c, add .po, remove stuff not used in the BSD libraries
< at >< at > -114,8 +119,17 < at >< at > PO_FLAG=-pg
 all: objwarn
 
 .if defined(SHLIB_NAME)
-.if defined(DEBUG_FLAGS)
-SHLIB_NAME_FULL=${SHLIB_NAME}.debug
+.if ${MK_DEBUG_FILES} != "no"
+SHLIB_NAME_FULL=${SHLIB_NAME}.full
+# Use ${DEBUGDIR} for base system debug files, else .debug subdirectory
+.if ${SHLIBDIR} == "/boot" ||\
+    ${SHLIBDIR:C%/lib(/.*)?$%/lib%} == "/lib" ||\
+    ${SHLIBDIR:C%/usr/lib(32)?(/.*)?%/usr/lib%} == "/usr/lib"
+DEBUGFILEDIR=${DEBUGDIR}${SHLIBDIR}
+.else
+DEBUGFILEDIR=${SHLIBDIR}/.debug
+DEBUGMKDIR=
+.endif
 .else
 SHLIB_NAME_FULL=${SHLIB_NAME}
 .endif
< at >< at > -201,13 +215,13 < at >< at > ${SHLIB_NAME_FULL}: ${SOBJS}
 ${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${SOBJS}
 .endif
 
-.if defined(DEBUG_FLAGS)
-CLEANFILES+=${SHLIB_NAME_FULL} ${SHLIB_NAME}.symbols
-${SHLIB_NAME}: ${SHLIB_NAME_FULL} ${SHLIB_NAME}.symbols
-${OBJCOPY} --strip-debug --add-gnu-debuglink=${SHLIB_NAME}.symbols \
+.if ${MK_DEBUG_FILES} != "no"
+CLEANFILES+=${SHLIB_NAME_FULL} ${SHLIB_NAME}.debug
+${SHLIB_NAME}: ${SHLIB_NAME_FULL} ${SHLIB_NAME}.debug
+${OBJCOPY} --strip-debug --add-gnu-debuglink=${SHLIB_NAME}.debug \
     ${SHLIB_NAME_FULL} ${.TARGET}
 
-${SHLIB_NAME}.symbols: ${SHLIB_NAME_FULL}
+${SHLIB_NAME}.debug: ${SHLIB_NAME_FULL}
 ${OBJCOPY} --only-keep-debug ${SHLIB_NAME_FULL} ${.TARGET}
 .endif
 .endif #defined(SHLIB_NAME)
< at >< at > -286,10 +300,13 < at >< at > _libinstall:
 ${INSTALL} ${STRIP} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
     ${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \
     ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
-.if defined(DEBUG_FLAGS)
-${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
+.if ${MK_DEBUG_FILES} != "no"
+.if defined(DEBUGMKDIR)
+${INSTALL} -T debug -d ${DESTDIR}${DEBUGFILEDIR}
+.endif
+${INSTALL} -T debug -o ${LIBOWN} -g ${LIBGRP} -m ${DEBUGMODE} \
     ${_INSTALLFLAGS} \
-    ${SHLIB_NAME}.symbols ${DESTDIR}${SHLIBDIR}
+    ${SHLIB_NAME}.debug ${DESTDIR}${DEBUGFILEDIR}
 .endif
 .if defined(SHLIB_LINK)
 # ${_SHLIBDIRPREFIX} and ${_LDSCRIPTROOT} are both needed when cross-building
diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk
index dfa8ed6..a9eee61 100644
--- a/share/mk/bsd.own.mk
+++ b/share/mk/bsd.own.mk
< at >< at > -43,6 +43,11 < at >< at >
 # LIBMODELibrary mode. [${NOBINMODE}]
 #
 #
+# DEBUGDIRBase path for standalone debug files. [/usr/lib/debug]
+#
+# DEBUGMODEMode for debug files. [${NOBINMODE}]
+#
+#
 # KMODDIRBase path for loadable kernel modules
 #(see kld(4)). [/boot/kernel]
 #
< at >< at > -147,6 +152,9 < at >< at > LIBOWN?=${BINOWN}
 LIBGRP?=${BINGRP}
 LIBMODE?=${NOBINMODE}
 
+DEBUGDIR?=/usr/lib/debug
+DEBUGMODE?=${NOBINMODE}
+
 
 # Share files
 SHAREDIR?=/usr/share
< at >< at > -213,6 +221,7 < at >< at > COMPRESS_EXT?=.gz
 #
 .for var in \
     CTF \
+    DEBUG_FILES \
     INSTALLLIB \
     MAN \
     PROFILE
< at >< at > -365,6 +374,7 < at >< at > __DEFAULT_NO_OPTIONS = \
     BSD_GREP \
     CLANG_EXTRAS \
     CTF \
+    DEBUG_FILES \
     GPL_DTC \
     HESIOD \
     ICONV \
diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk
index 0991915..3c48329 100644
--- a/share/mk/bsd.prog.mk
+++ b/share/mk/bsd.prog.mk
< at >< at > -24,8 +24,23 < at >< at > CTFFLAGS+= -g
 .endif
 .endif
 
+.if defined(PROG_CXX)
+PROG=${PROG_CXX}
+.endif
+
+.if defined(PROG) && target(${PROG})
+MK_DEBUG_FILES=no
+.elif !empty(LDFLAGS:M-Wl,*--oformat,*) || !empty(LDFLAGS:M-static)
+MK_DEBUG_FILES=no
+.endif
+
 .if defined(CRUNCH_CFLAGS)
 CFLAGS+=${CRUNCH_CFLAGS}
+.else
+.if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g*)
+CFLAGS+= -g
+CTFFLAGS+= -g
+.endif
 .endif
 
 .if !defined(DEBUG_FLAGS)
< at >< at > -36,21 +51,36 < at >< at > STRIP?=-s
 LDFLAGS+= -static
 .endif
 
-.if defined(PROG_CXX)
-PROG=${PROG_CXX}
+.if ${MK_DEBUG_FILES} != "no"
+PROG_FULL=${PROG}.full
+# Use ${DEBUGDIR} for base system debug files, else .debug subdirectory
+.if defined(BINDIR) && (\
+    ${BINDIR} == "/bin" ||\
+    ${BINDIR} == "/libexec" ||\
+    ${BINDIR} == "/sbin" ||\
+    ${BINDIR:C%/usr/(bin|bsdinstall|games|libexec|lpr|sendmail|sm.bin|sbin)(/.*)?%/usr/bin%} == "/usr/bin"\
+     )
+DEBUGFILEDIR=${DEBUGDIR}${BINDIR}
+.else
+DEBUGFILEDIR?=${BINDIR}/.debug
+DEBUGMKDIR=
+.endif
+.else
+PROG_FULL=${PROG}
 .endif
 
 .if defined(PROG)
 PROGNAME?=${PROG}
+
 .if defined(SRCS)
 
 OBJS+=  ${SRCS:N*.h:R:S/$/.o/g}
 
 .if target(beforelinking)
 beforelinking: ${OBJS}
-${PROG}: beforelinking
+${PROG_FULL}: beforelinking
 .endif
-${PROG}: ${OBJS}
+${PROG_FULL}: ${OBJS}
 .if defined(PROG_CXX)
 ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
 .else
< at >< at > -78,9 +108,9 < at >< at > OBJS+=${PROG}.o
 
 .if target(beforelinking)
 beforelinking: ${OBJS}
-${PROG}: beforelinking
+${PROG_FULL}: beforelinking
 .endif
-${PROG}: ${OBJS}
+${PROG_FULL}: ${OBJS}
 .if defined(PROG_CXX)
 ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
 .else
< at >< at > -89,10 +119,19 < at >< at > ${PROG}: ${OBJS}
 .if ${MK_CTF} != "no"
 ${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS}
 .endif
-.endif
+.endif # !target(${PROG})
 
 .endif # !defined(SRCS)
 
+.if ${MK_DEBUG_FILES} != "no"
+${PROG}: ${PROG_FULL} ${PROGNAME}.debug
+${OBJCOPY} --strip-debug --add-gnu-debuglink=${PROGNAME}.debug \
+    ${PROG_FULL} ${.TARGET}
+
+${PROGNAME}.debug: ${PROG_FULL}
+${OBJCOPY} --only-keep-debug ${PROG_FULL} ${.TARGET}
+.endif
+
 .if${MK_MAN} != "no" && !defined(MAN) && \
 !defined(MAN1) && !defined(MAN2) && !defined(MAN3) && \
 !defined(MAN4) && !defined(MAN5) && !defined(MAN6) && \
< at >< at > -109,6 +148,9 < at >< at > all: _manpages
 
 .if defined(PROG)
 CLEANFILES+= ${PROG}
+.if ${MK_DEBUG_FILES} != "no"
+CLEANFILES+=${PROG_FULL} ${PROGNAME}.debug
+.endif
 .endif
 
 .if defined(OBJS)
< at >< at > -156,6 +198,13 < at >< at > _proginstall:
 .if defined(PROG)
 ${INSTALL} ${STRIP} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
     ${_INSTALLFLAGS} ${PROG} ${DESTDIR}${BINDIR}/${PROGNAME}
+.if ${MK_DEBUG_FILES} != "no"
+.if defined(DEBUGMKDIR)
+${INSTALL} -T debug -d ${DESTDIR}${DEBUGFILEDIR}
+.endif
+${INSTALL} -T debug -o ${BINOWN} -g ${BINGRP} -m ${DEBUGMODE} \
+    ${PROGNAME}.debug ${DESTDIR}${DEBUGFILEDIR}/${PROGNAME}.debug
+.endif
 .endif
 .endif# !target(realinstall)
 
diff --git a/tools/build/options/WITH_DEBUG_FILES b/tools/build/options/WITH_DEBUG_FILES
new file mode 100644
index 0000000..16eee2a
--- /dev/null
+++ b/tools/build/options/WITH_DEBUG_FILES
< at >< at > -0,0 +1,7 < at >< at >
+.\" $FreeBSD$
+Set to strip debug info into a separate file for each executable binary
+and shared library.
+The debug files will be placed in a subdirectory of
+.Pa /usr/lib/debug
+and are located automatically by
+.Xr gdb 1 .

Announce: Unofficial binary package builds for old releases

Kevin Day — 2013-06-05T00:21:20

Thanks to poudriere making this easy, we're now making public our (unofficial!) constantly being rebuilt repository of binary packages for old FreeBSD releases and less popular architectures.

See http://ftpmirror.your.org/pub/FreeBSD-Unofficial-Packages for instructions on how to use this.

How do these differ from the official packages?

1) We're building packages for 9.1 all the way back to 7.2.

2) We're constantly grabbing new versions of ports and rebuilding as fast as the builders can go. Our goal is to rebuild the latest version (9.1 right now) in both amd64 and i386 every 24 hours, and all other versions every 7 days.

3) We're leaving up old versions (in the All directory) of everything, so you can grab older versions if we have them.

4) We're building everything twice, one by default and one a special internal-use version that has X11, examples, debugging and a few other features shut off. If the port can't be built without those features, it just gets skipped. (This may not be of use to anyone other than us)

5) We're building packages for i386, amd64, ia64, and have the hardware in house to build for PPC, ARM and sparc64 if anyone asks for it.

(As of this writing, our ia64 box just started building things, and looks like it'll take another 5+ days to finish. If you need ia64, give it a few days.)


Feel free to contact me with any questions, or suggestions for how this might be more useful to you. If you could actually use this on any other release or architecture that isn't currently listed, please let me know. If there's anyone out there that would prefer pkgng instead of the old style packages, we might be able to get those going too. This is primarily for our own internal use so I don't want to add support for a ton of things if nobody is going to use this, so speak up if you want something!

pw

2013-06-04T01:47:55

____________________________________________________________
NetZero now offers 4G mobile broadband. Sign up now.
http://www.netzero.net/?refcd=NZINTISP0512T4GOUT1

I have 2 FreeBSD systems (they are using versions 4.3 and 4.7 of the FreeBSD Operating System) that I have not used for a long time, and I have forgotten their passwords. I have information on these systems that I want to retrieve but I have not been able to log into these Systems. My problem was put on the internet several years ago and the usual ways of getting into the systems (basically by being the operator) were suggested and tried, unsuccressfully. A friend and I discussed my problem and he suggested that I zero out the root password so that I can get in as rooy (to set a new password and then continue operating as root).
Does the FreeBSD community have a program (either on a floppy or a CD ROM, preferably the latter) that can do this? If not, I suggest that you write one that would work with all the (formats of) password files that have ever been used. If it can determine the format of password files just by examining them, that would be fine. If it can't, then it should ask the user in which version of the FreeBSD Operating System the password file was used, try to verify it by the structure of the password file and if it is verified make a copy of the password file (in case something goes wrong, so that the system can be restored to its original condition and so undo anything that this program has done), and zero out the root password. After this is done, one could log in as root to set the root password and afterwards (as root) set other user passwords.

Operating Systems that have ever been run.
You could set it up to look
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

DVD burner failure on FreeBSD: the LUN appears to be stuck

Yuri — 2013-06-03T16:30:22

I have DVD burner Pioneer DVR-112D failing on FreeBSD-9.1 amd64. It 
begins to write ok, but later gets stuck at some percentage point with 
"the LUN appears to be stuck" message (log is below).
Command used to burn is:
$ growisofs -dvd-compat -speed=4 -Z /dev/acd0=my.iso
growisofs is from dvd+rw-tools-7.1, which hasn't been updated from 2008.
cd0: <PIONEER DVD-RW  DVR-112D 1.21> Removable CD-ROM SCSI-0 device

Now there is a dilemma. Does this mean that the burner went bad? Or does 
this mean that there is some fault in the burner driver?
I know that few years ago this burner worked fine on BSD.

Maybe anybody has an expertise and would know if this error means the 
hardware or software failure?
Anybody is able to burn DVDs with the same/similar burner?
Or maybe some other command should be used for burning? (growisofs is 
recommended by the handbook)

Googling the message doesn't clarify the issue.

Yuri



--- error log ---
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 86:00 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 86:19 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 86:45 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 87:05 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 87:24 RBU 100.0% UBU 100.0%
   072726016/8061945856 (13.3%) < at >0.0x, remaining 87:50 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 88:10 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 88:30 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 88:56 RBU 100.0% UBU 100.0%
:-? the LUN appears to be stuck writing LBA=7fe10h, keep retrying in 141ms
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 89:15 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 89:35 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 90:01 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 90:20 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 90:40 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 91:06 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 91:25 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 91:45 RBU 100.0% UBU 100.0%
:-? the LUN appears to be stuck writing LBA=7fe10h, keep retrying in 141ms
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 92:11 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 92:31 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 92:50 RBU 100.0% UBU 100.0%
  1072726016/8061945856 (13.3%) < at >0.0x, remaining 93:16 RBU 100.0% UBU 100.0%
^C/dev/pass0: flushing cache

_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

sed query

Chris Rees — 2013-05-31T14:01:59

Hi all,

I think I've discovered a strange behaviour of sed perhaps triggered
by the length of a regex passed to it.  I noticed that a certain
expression I passed took a very long time, and suspected the usual
backtracking loop, so I started trimming it... and discovered this:

[crees< at >pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/por,,"
/var/db/pkg/INDEX-9
4.699u 0.007s 0:04.70 99.7% 40+2733k 0+0io 0pf+0w
[crees< at >pegasus]~% time sed -ne "s,^BitchX-[0-9][^|]*[\|]/usr/po,,"
/var/db/pkg/INDEX-9
0.042u 0.000s 0:00.04 100.0% 48+3216k 0+0io 0pf+0w

I've looked at the code, and can't from a brief glance figure out why
a slightly longer regex makes such a difference-- does it start to
split it?

Chris
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"

seeding randomness in zee cloud

Dirk-Willem van Gulik — 2013-05-31T10:01:02

Thanks to a badly-written mngt script - we've rencently noticed a freshly generated ssh-key on a new AWS instances to be indentical to one seen a few months prior.

Careful analysis of some other logs showed that we've had similar clashes on another script just after startup generating a very short x509 CSR. It happens quite rarely though. But still.

I am surmising that perhaps the (micro-T) images do not have that much entropy on startup.

So I am wondering how to best make our images 'more random' -- and want to avoid the linux/openstack suggestion[1] of doing this through the boot-params [2] (as in our
case it is the operator of the machine we're protecting/guarding against accusations/temptations).

Now we happen to have very easy access to blocks of 1024bits of randomness from a remote server in already nicely PKI signed packages (as it is needed later for something else).

Is it safe to simply *add* those with:

set -1
# fetch randomness & check signature
.. snipped...

# Seed Software random generator
#
cat rnd > /dev/random

# Activate software random generator as an additional source
sysctl kern.random.sys.harvest.swi=1

Or does this cause a loss/reset of all entropy gathered by the hardware sofar ? Or is there a cleaner way to add a additional seed as a one-off with disturbing as little as possible (in the few seconds just after the network is brought up).

Thanks,

Dw.

FWIIW: this is the output of sysctl kern.random.

kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 192
kern.random.yarrow.slowthresh: 256
kern.random.yarrow.slowoverthresh: 2
kern.random.sys.seeded: 1
kern.random.sys.harvest.ethernet: 1
kern.random.sys.harvest.point_to_point: 1
kern.random.sys.harvest.interrupt: 1
kern.random.sys.harvest.swi: 0

1: http://blog.dustinkirkland.com/2012/10/entropy-or-lack-thereof-in-openstack.html
2: https://review.openstack.org/#/c/14550/
_______________________________________________
freebsd-hackers< at >freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe< at >freebsd.org"