FreeBSD_STABLE_9-i386 - Build #75 - Failure
FreeBSD_STABLE_9-i386 - Build #75 - Failure: Check console output at https://jenkins.freebsd.org/job/FreeBSD_STABLE_9-i386/75/ to view the results. ___ 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: can the l2arc memory leak fix be pulled into 10.1-RELEASE ?
On Wed, Jun 24, 2015 at 01:05:58PM -0700, Xin Li wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/23/15 04:36, Reko Turja wrote: -Original Message- From: Willem Jan Withagen Sent: Monday, June 22, 2015 11:48 PM To: Daniel Genis ; freebsd-stable@freebsd.org Subject: Re: can the l2arc memory leak fix be pulled into 10.1-RELEASE ? We are kind of new to FreeBSD, so we're wondering what are the plans to merge these fixes into the 10.1-RELEASE branch ? We'd love to get these fixes without having to rebuild the kernel. Is there any chance for the merge to happen in the near future, or should we compile the kernel to get the fixes? The RELEASE branch is exactly what it says, RELEASE. And is only done once per version when the actual official RELEASE is. So the next one will be the upcoming 10.2-RELEASE. Which is schedules for August 2015 according to: There are actually 2 branches tracking release: RELEASE which is the original release itself and RELENG which is the release+security and some errata fixes. In practice one should always track and compile RELENG sources with production servers, unless there's a bugfix or added driver that's only available in STABLE. The release/X.Y.Z are actually tags and not branches (i.e. read only copy of whatever state is in the release engineering/errata branch, releng/X.Y, is at the time it's released), but technically in svn a tag is also a branch. We do all efforts to avoid making any changes once a tag is laid, because it's a historical and reference point. Users who use -RELEASE should track releng/X.Y branch, or use freebsd-update(1) to keep their system up-to-date. Our goal is to allow a majority of users to use binary releases without having to compile and build themselves. If you know some specific reasons that forces you to compile yourself, please consider sending re@ an email so we will see what we can improve this. You are some wrong. Tracking releng/X.Y for -RELEASE don't allow reproductable build of -RELEASE image: after existing errata `svn export releng/X.Y` give different result compared to original release build. This is wrong. Building release image must be also from `svn export release/X.Y.Z`. Last release (10.1) will be build from releng/10.1 and I can't find easy way to get source of releases form svn. ___ 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: Last openssl update brakes localhost email sending
On Thu, 18 Jun 2015 08:04:04 -0700 Gregory Shapiro gshap...@gshapiro.net wrote: We ran into this as well. There are notes in UPDATING now that have the instructions on what changes need to be done to the locale .mc file. Even better than UPDATING: https://security.FreeBSD.org/advisories/FreeBSD-EN-15:08.sendmail.asc All of my 10.1-RELEASE-p13 systems are affected, some 20 boxes. Sendmail is used only for sending daily and security run outputs, but I am starting to feel unconfortable as it will soon be two weeks since I received them. All those systems are without source code on them, and it is quite inconvenient for me to rebuild from source. Is binary update for this coming soon? Is it coming at all? -- Marko Cupać https://www.mimar.rs/ ___ 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: Last openssl update brakes localhost email sending
All of my 10.1-RELEASE-p13 systems are affected, some 20 boxes. Sendmail is used only for sending daily and security run outputs, but I am starting to feel unconfortable as it will soon be two weeks since I received them. All those systems are without source code on them, and it is quite inconvenient for me to rebuild from source. Is binary update for this coming soon? Is it coming at all? It is coming, the commit for the stable branches was last night. The Security and RE teams are working on the releng branches next to produce the binary patches. A workaround is available: openssl dhparam -out /etc/mail/certs/dh.param 2048 cd /etc/mail/; make restart ___ 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
FreeBSD_stable_9 - Build #813 - Fixed
FreeBSD_stable_9 - Build #813 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_stable_9/813/ to view the results. ___ 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: can the l2arc memory leak fix be pulled into 10.1-RELEASE ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/25/15 02:13, Slawa Olhovchenkov wrote:
On Wed, Jun 24, 2015 at 01:05:58PM -0700, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512
On 06/23/15 04:36, Reko Turja wrote:
-Original Message- From: Willem Jan Withagen Sent:
Monday, June 22, 2015 11:48 PM To: Daniel Genis ;
freebsd-stable@freebsd.org Subject: Re: can the l2arc memory
leak fix be pulled into 10.1-RELEASE ?
We are kind of new to FreeBSD, so we're wondering what are
the plans to merge these fixes into the 10.1-RELEASE branch
?
We'd love to get these fixes without having to rebuild the
kernel. Is there any chance for the merge to happen in the
near future, or should we compile the kernel to get the
fixes?
The RELEASE branch is exactly what it says, RELEASE. And is
only done once per version when the actual official RELEASE
is. So the next one will be the upcoming 10.2-RELEASE. Which
is schedules for August 2015 according to:
There are actually 2 branches tracking release: RELEASE which
is the original release itself and RELENG which is the
release+security and some errata fixes. In practice one should
always track and compile RELENG sources with production
servers, unless there's a bugfix or added driver that's only
available in STABLE.
The release/X.Y.Z are actually tags and not branches (i.e. read
only copy of whatever state is in the release engineering/errata
branch, releng/X.Y, is at the time it's released), but
technically in svn a tag is also a branch. We do all efforts to
avoid making any changes once a tag is laid, because it's a
historical and reference point.
Users who use -RELEASE should track releng/X.Y branch, or use
freebsd-update(1) to keep their system up-to-date.
Our goal is to allow a majority of users to use binary releases
without having to compile and build themselves. If you know
some specific reasons that forces you to compile yourself, please
consider sending re@ an email so we will see what we can improve
this.
You are some wrong. Tracking releng/X.Y for -RELEASE don't allow
reproductable build of -RELEASE image: after existing errata `svn
export releng/X.Y` give different result compared to original
release build. This is wrong. Building release image must be also
from `svn export release/X.Y.Z`. Last release (10.1) will be build
from releng/10.1 and I can't find easy way to get source of
releases form svn.
releng/* is a _branch_ and it's not intended for reproducible builds.
In order to do so one will have to use a tag.
However, svn tag is different from CVS or other SCM's tag as they are
also a branch. To make things worse, we are using $FreeBSD$ expansion
and that would result in different contents in the files, and these
strings would end up going into some binaries, and speaking for binary
update, you would never want an update to refresh all binaries just
because there is difference because one copy is built from tag and
another is from branch.
To solve this issue we (re@, although it's mostly Glen doing the hard
work for the last few releases) always build on releng/* branch, and
then lay down tag once the build is considered gold. To reproduce
that build, what I can possibly think of would be something like this:
Assuming we have:
SVN_RELEASE_VERSION=10.1
FSVN=svn://svn.freebsd.org/base
Then one can reliably checkout the branch by doing:
svn export -r $(svn info ${FSVN}/release/${SVN_RELEASE_VERSION}.0 |
grep 'Last Changed Rev:' | cut -f2 -d:)
${FSVN}/releng/${SVN_RELEASE_VERSION} src
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.5 (FreeBSD)
iQIcBAEBCgAGBQJVjDmlAAoJEJW2GBstM+ns/Q8P/jvLJvSWvO9HENkUSF0hqKCd
cz8k53g9tCusNHGmN9j5FEERp1RiEEBLnIBd2yO2TnU6cgZUhq2IpA2+RMz2/RhE
XgVp8yrJRebTjstZzFMrYVEnQPKmYFQs8lrsC7sh6tQML2jRGXIDc1jL/rjD73+s
a+WoDQdcyqVZaeiLrpCB3Q5HZGDTk0mmHHlvo6kiKFcnGYe4FZ4Gqbt6jF0uj0qm
KXita7Ix23IiB0LBr9csV79AfuEe7ZqObj9vQxocHlrPQiwFCfwnDX2edpE2Slmz
4KIHRR4Ogv3KVdrdmopZDNiRcA3/DfC8wyNkOc5rCBtFrDUT4hKTZ2K48YSqKEbZ
TbRJutOf9lYpILEOOFS6ZE3QN1Dd2fZeSofoI1Xqt4vHEjxmYtK/pAWf2J44k8SR
bMkswHBEpBoqrp5+df6eQsV/mIKHPHYgamzHJHowRMCALOyLjLAtEIYnsRMrL9Je
jaHWrrlbrJ0F4yqW7Pm4BhYWZsu8lM5yHhmSQabHv0vUH22k9gAu2ohHGiTYmSu6
oANaYtv1ErIPWICckPQoI1LYTa9mKzLWmsLycTRk2UPDToQUjkzB4RG8l75d8/1n
pUxgmN+tn+A2/o/2/L/JHAiXf6dMxrdimOv71D8XgYzNR3WD1RJlciURMt8i1VMM
chfd7G6j1ey68TtD2PSD
=Ymad
-END PGP SIGNATURE-
___
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
Virtualbox on my new Dell 7810
Hi all, I'm having another issue with my new desktop machine, this time with Virtualbox. I originally sent this to freebsd-emulation a few days ago, but I haven't had any response. I'm hoping someone here can help me. My machine is running FreeBSD 10.2-PRERELEASE #2 r284595 with a GENERIC kernel. I built installed virtualbox-ose-4.3.28 (and kmod, of course) from ports. /etc/make.conf contains NO_LPR=yes NO_PROFILE= true CUPS_OVERWRITE_BASE=yes OPTIONS_SET= OPTIMIZED_CFLAGS OPTIONS_UNSET= NLS DEFAULT_VERSIONS=python=2.7 python2=2.7 gcc=4.9 bdb=5 perl=5.22 At boot, I now see the following: vboxdrv: fAsync=1 offMin=0x3ae80 offMax=0x3ae80 supdrvGipCreate: omni timer not supported, falling back to synchronous mode I've never seen the supdrvGipCreate message before. I first moved a 32 bit Windows 7 VM from my old desktop which was running a FreeBSD-stable a week or 2 old (literally; I took the drive out of the old machine). The first time I tried to boot the VM it took about 7 minutes. The CPU I allocated to the VM stayed at 100%. After some googling, I turned off hyperthreading in the 7810's BIOS. The VM now boots in a reasonable time and is almost usable. It'll be ok for 2 or 3 seconds, then almost freeze up for a little while (so far always less than a minute), and then be ok again for a few seconds. When it 'freezes up' its CPU is at 100%. As a test I started installing a 64 bit Windows 8.1 VM. It behaves exactly the same way. Does anyone have any ideas or suggestions? I'm hoping there's a BIOS setting I can tweak to make this work. Thanks in advance! -- Richard Kuhns r...@wintek.com Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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
FreeBSD_stable_9 - Build #812 - Failure
FreeBSD_stable_9 - Build #812 - Failure: Check console output at https://jenkins.freebsd.org/job/FreeBSD_stable_9/812/ to view the results. ___ 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
FreeBSD_STABLE_9-i386 - Build #76 - Fixed
FreeBSD_STABLE_9-i386 - Build #76 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_STABLE_9-i386/76/ to view the results. ___ 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: gptboot: unable to read backup GPT header - virtualbox guest with SAS controller
On Mon, 22 Jun 2015 08:28:10 -0600 (MDT)
Warren Block wbl...@wonkity.com wrote:
On Mon, 22 Jun 2015, Paul Koch wrote:
We get the following error after installing 10.1-p12 in a VirtualBox guest
when setup with an emulated LSI / SAS controller and a 50G fixed sized
virtual disk:
gptboot: error 1 lba 104857599
gptboot: unable to read backup GPT header
Can't seem to find anyone who has this same issue.
The problem does not exist if we configure the guest with a SATA controller
and same size virtual disk.
...
The guest boots fine, but we always get the gptboot error.
Is this just a problem with the virtualbox SAS controller emulation where
gptboot can't retrieve the backup table ?
That would be my first guess: an off-by-one error preventing the last
block from being read. It's not clear which emulated controller was
being used for the diskinfo output posted earlier. If it really was an
off-by-one bug, the block count would differ depending on the
controller.
However, some controllers keep metadata on the drive, and report a
reduced capacity, and that would have almost the same effect. Seems
like there would be a complaint by the controller firmware about the
contents of the metadata block, but maybe not by an emulated controller.
If controller metadata is the problem, installing FreeBSD using the
emulated controller in place should make sure the backup GPT is in the
correct position, rather than switching to the SCSI controller after
installing with, say, SATA.
It does look like gptboot couldn't access the last sector on the virtual SAS
disk. We were playing with expanding the size of the virtual disk...
Shutting down the VM, expanding the disk size, rebooting, and no gptboot error.
Running the appropriate gpart/zpool commands to take up the expanded space,
then reboot, and the gptboot error is back again.
We've been having similar/same issues with a customer who is running on bare
hardware using a Cisco C240 M4 using the mrsas driver, but it also appears
to exhibit the problem we were having where the backup partition table does
not get updated when the gpart bootonce flag is set so we can boot from an
alternate partition. Adding 'gpart recover ${disk}' to our startup script
gets around the problem.
Paul.
--
Paul Koch | Founder, CEO
AKIPS Network Monitor | akips.com
Brisbane, Australia
___
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
