Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 21, 2013, at 10:18 AM, Allan Jude wrote: On 2013-10-21 13:14, Teske, Devin wrote: On Oct 21, 2013, at 10:12 AM, Allan Jude wrote: On 2013-10-21 12:19, Teske, Devin wrote: On Oct 21, 2013, at 9:06 AM, Allan Jude wrote: On 2013-10-21 12:04, Teske, Devin wrote: On Oct 21, 2013, at 8:50 AM, Allan Jude wrote: On 2013-10-21 11:45, Johan Broman wrote: Hi! Sorry for the delayed answer. I've patched zfsboot and rebuilt the release. I now get an error message that ada2 can't be used, which is correct. Good stuff! :) ( I've recreated the test environment using a KVM guest with four SATA drives instead of the server I was using. I makes it easier to test stuff. ) Here's the screenshot: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.pngk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99 Maybe one should be unable to select drives that are part of a graid in the first place? Or is that out-of-scope for bsdinstall at this point? (As I guess that requires too many changes/new lines) Cheers Johan On 19/10/13 22:20, Teske, Devin wrote: On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. I have screen shots (taken with my phone) of the msgbox and ps auxwww output. Let me know what kind of debug info you would like. I've put the screen shots here: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstallk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1 I've added a patch to fix debugging in the zfsboot script... https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9 Feedback welcome. Johan,... Can you see if the patch sheds some better light as to what's failing? The patch won't fix the problem, but it should give us an accurate error message so that we can learn what precisely is returning an error status. Thanks in advance. I do notice that Devin's manually prefixing the error message with the tool name, is partially redundancy when the tool does it it self, but we can't always be sure it will do that. The next patchset will fix that. I'm dropping the tool name from the msgbox contents and putting it in the title (e.g., 'Error: gpart) that way... even if the tool spits out its own name (or not), we'll know what exactly what was going on by looking at the title. the graid thing is rather hard to detect, especially when it is a faulted array that doesn't even appear in graid status etc. I believe the idea behind the script is that whatever you tell it to use will be destroyed. Allan, maybe perhaps we could add some code that attempts to dis- assemble a graid to make the disk usable? Johan, what would you be more apt to expect? That it killed your graid or that it gave an error? (/me thinks what the recourse to the error might entail -- going to partedit?) Your recourse would be switching to the shell (control+alt+f4) and destroying the graid. I am a little hesitant to go destroying graids unprompted. If we had the geom.confxml parsing, we might be able to detect it and ask the user what to do Well, my concern with going and asking about each/every configuration before we clear it... Hasn't the user already answered a Last Chance! dialog giving the go- ahead to nuke any/all data *and* configurations on a drive? I guess that makes sense, We offer the dialog to allow the user to investigate their disk in detail so they can be sure they picked the correct ones. the graid thing is the biggest gotcha because it picks up metadata written by the motherboard raid system, so you can have a graid configuration even if you have never booted freebsd before. Hmmm... so what does one do in *that* situation? Go into the motherboard BIOS and disable on-board RAID features for the controller providing the disks-in-question? You can destroy the metadata with the graid delete command. I've only encountered once instance where 'graid status' didn't show any devices, but graid was blocking zfs from using the device until the graid was destroyed (the graid part was only discovered after generating an image out of the geom.confdot sysctl) Allan, Do we want to add a
[CFT] Kernel-Selection Enhancemnt to Boot Menu
Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Official FreeBSD Binary Packages now available for pkgng
On 02/11/2013 01:55, Eric van Gyzen wrote:
This kind of proxy configuration is not uncommon. It would be awesome
if this would Just Work. It would remove an impediment to adoption,
which is especially important in the kind of environments that have this
kind of proxy configuration.
Simply adding the mirrors' A (and ) records to pkg.freebsd.org might
suffice.
You seem hung up on the idea that pkg.freebsd.org should resolve to a
list of IP addresses. It doesn't and for very good reasons.
Admittedly, using eg. 'http://' as the URL scheme for PACKAGESITE URLs
was an error -- it contravenes RFC 2616 -- which is why we will be
switching to a new 'pkg+http://' (or 'pkg+https://', 'pkg+ftp://', etc.)
set of URL schemes with pkg-1.2.x
There certainly are all of the necessary A and records in the DNS
for the real servers that host the repositories.
If I understand what you're complaining about is that you see behavious
like the following:
* You download package foo-1.2.3.txz from pkg.freebsd.org
* Internally, that gets resolved to an HTTP request to eg.
pkg0.isc.freebsd.org
* Your web proxy caches this package
* On another host, you also want to download foo-1.2.3.txz
* This time the SRV record gets resolved to a different mirror,
say pkg1.nyi.freebsd.org
* Your proxy has no way of knowing that foo-1.2.3.txz from pkg1.nyi
is exactly the same file as foo-1.2.3.txz from pkg0.isc so it
downloads the whole package all over again.
Yes, this is certainly undesirable behaviour. I need to run some tests
to determine if this is actually what does happen in practice. If so,
I've an idea about how this problem might be addressed, but it will
require some changes to the repository configuration.
In the mean time, I suggest just choosing which ever of the
pkg.freebsd.org repositories is closest to you and using it directly -- eg.
cat EOF /usr/local/etc/pkg/repos/myrepo.conf
pkg0.isc {
url: http://pkg0.isc.freebsd.org/${ABI}/latest
enabled: yes
mirror_type: none
}
EOF
Obviously, substitute which ever one of
pkg0.isc.freebsd.org (US West)
pkg1.nyi.freebsd.org (US East)
pkg0.bme.freebsd.org (Europe)
is appropriate. And be prepared to deal with that specific mirror being
down or replaced by some other server.
Alternatively, running an HTTP-redirection service on a host named
pkg.freebsd.org would offer as much flexibility as the SRV records, if
not more. However, it would require maintenance of yet another central
service.
This is already supported in pkg when using the HTTP mirror type. This
would entail significantly more administrative effort and hardware
requirement to maintain and keep consistent in the specific case of
pkg.freebsd.org which is exactly why the SRV mirror type was selected.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin devin.te...@fisglobal.comwrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
Matthew Seaman matt...@freebsd.org schrieb:
On 02/11/2013 01:55, Eric van Gyzen wrote:
This kind of proxy configuration is not uncommon. It would be
awesome
if this would Just Work. It would remove an impediment to adoption,
which is especially important in the kind of environments that have
this
kind of proxy configuration.
Simply adding the mirrors' A (and ) records to pkg.freebsd.org
might
suffice.
You seem hung up on the idea that pkg.freebsd.org should resolve to a
list of IP addresses. It doesn't and for very good reasons.
Admittedly, using eg. 'http://' as the URL scheme for PACKAGESITE URLs
was an error -- it contravenes RFC 2616 -- which is why we will be
switching to a new 'pkg+http://' (or 'pkg+https://', 'pkg+ftp://',
etc.)
set of URL schemes with pkg-1.2.x
There certainly are all of the necessary A and records in the DNS
for the real servers that host the repositories.
If I understand what you're complaining about is that you see behavious
like the following:
* You download package foo-1.2.3.txz from pkg.freebsd.org
* Internally, that gets resolved to an HTTP request to eg.
pkg0.isc.freebsd.org
* Your web proxy caches this package
* On another host, you also want to download foo-1.2.3.txz
* This time the SRV record gets resolved to a different mirror,
say pkg1.nyi.freebsd.org
* Your proxy has no way of knowing that foo-1.2.3.txz from pkg1.nyi
is exactly the same file as foo-1.2.3.txz from pkg0.isc so it
downloads the whole package all over again.
Yes, this is certainly undesirable behaviour. I need to run some tests
to determine if this is actually what does happen in practice. If so,
I've an idea about how this problem might be addressed, but it will
require some changes to the repository configuration.
In the mean time, I suggest just choosing which ever of the
pkg.freebsd.org repositories is closest to you and using it directly --
eg.
cat EOF /usr/local/etc/pkg/repos/myrepo.conf
pkg0.isc {
url: http://pkg0.isc.freebsd.org/${ABI}/latest
enabled: yes
mirror_type: none
}
EOF
Obviously, substitute which ever one of
pkg0.isc.freebsd.org (US West)
pkg1.nyi.freebsd.org (US East)
pkg0.bme.freebsd.org (Europe)
is appropriate. And be prepared to deal with that specific mirror
being
down or replaced by some other server.
Alternatively, running an HTTP-redirection service on a host named
pkg.freebsd.org would offer as much flexibility as the SRV records,
if
not more. However, it would require maintenance of yet another
central
service.
This is already supported in pkg when using the HTTP mirror type. This
would entail significantly more administrative effort and hardware
requirement to maintain and keep consistent in the specific case of
pkg.freebsd.org which is exactly why the SRV mirror type was selected.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I understand from Eric's pist that the issue is that through his limiting
proxies, the SRV are not available at all so he does not even get to the point
where he could get the pkgN.nyi.freebsd.org name back.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On 02/11/2013 10:15, Matthias Andree wrote: I understand from Eric's pist that the issue is that through his limiting proxies, the SRV are not available at all so he does not even get to the point where he could get the pkgN.nyi.freebsd.org http://pkgN.nyi.freebsd.org name back. That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are done internally to pkg(8), which then issues an HTTP GET to the specific mirror selected by its internal algorithms. The web cache won't see literal 'pkg.freebsd.org' anywhere in the HTTP traffic -- as far as it is concerned, it's a simple HTTP request to a specific mirror 'pkg1.nyi.freebsd.org', and can be cached using the usual processes. What makes it cache unfriendly is that as far as the web cache is concerned each of the different mirrors appears to be completely independent of the others. So at the moment the chance of getting a cache hit is reduced by a factor of three because of the traffic distribution across the three mirrors. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.11.2013 08:06, Boris Bobrov wrote: В сообщении от Thursday 31 of October 2013 17:54:32 Gleb написал: On Thu, Oct 31, 2013 at 05:48:43PM +0400, Gleb Smirnoff wrote: T B 1. The bug disappeares if I disable VT-x/AMD-V in my virtual machine T B settings (Settings - System - Acceleration) and appeares if I enable it T B (thanks to Gleb for inspiration yesterday). It disappeares everywhere, on T B all revisions. T B T B 2. r244315 seems to be not buggy even with VT-x enabled. So we have to T B look somewhere between r244315 and r248935. T T Good news! Thanks Boris. T T Can you track this down to a particular revision? I have suspision that it is very close to the bhyve checkin: --- - r245652 | neel | 2013-01-19 08:18:52 +0400 (сб, 19 янв 2013) | 9 lines Merge projects/bhyve to head. 'bhyve' was developed by grehan@ and myself at NetApp (thanks!). Special thanks to Peter Snyder, Joe Caradonna and Michael Dexter for their support and encouragement. Obtained from: NetApp --- - since this is the code that started to utilize VT-x. Can you please check this revision and -1 revision to it? r245652 is not buggy. It's somewhere between r248500(passwd works) and r248556(passwd don't work). I haven't yet traced this down. - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ05jAACgkQPQ1pa2ELkNlKRgCfUDUUYSE2WAUF3icb9xkaL4HW /mEAn1ohyDuvU+lsEw0DI7iCtktyMYj6 =LC84 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On 02/11/2013 11:37, Kurt Jaeger wrote: Hi! On 02/11/2013 10:15, Matthias Andree wrote: I understand from Eric's pist that the issue is that through his limiting proxies, the SRV are not available at all so he does not even get to the point where he could get the pkgN.nyi.freebsd.org http://pkgN.nyi.freebsd.org name back. That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are done internally to pkg(8), ... which only works, if the DNS server queried answers SRV queries with SRV values. Which is not always true, especially in heavily firewalled environments. I feel no obligation to do anything to encourage people that deliberately break the DNS. They've made their bed, and now they have to lie in it. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Official FreeBSD Binary Packages now available for pkgng
On 11/02/2013 07:28 AM, Matthew Seaman wrote: On 02/11/2013 11:37, Kurt Jaeger wrote: Hi! On 02/11/2013 10:15, Matthias Andree wrote: I understand from Eric's pist that the issue is that through his limiting proxies, the SRV are not available at all so he does not even get to the point where he could get the pkgN.nyi.freebsd.org http://pkgN.nyi.freebsd.org name back. That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are done internally to pkg(8), ... which only works, if the DNS server queried answers SRV queries with SRV values. Which is not always true, especially in heavily firewalled environments. I feel no obligation to do anything to encourage people that deliberately break the DNS. They've made their bed, and now they have to lie in it. Eric Camachat didn't break the DNS: his network administrator did. Matthew, you're right: that doesn't make sense. But people do it, often for security, either real or perceived. In this kind of environment, many other things are typically equally broken. I imagine Eric needs all the encouragement he can get. Yes, he can reconfigure pkg to use a specific mirror. I only suggest that it could be made to work without that manual step (and the research necessary to determine that step). Lest anyone think I'm complaining: I am very impressed with pkg, and I appreciate all the technical and non-technical effort that Bryan, Baptiste, and many others spent on making it real. Instead of a complaint, consider this a feature request. That is, after all, the expected response to a feature announcement. :) Eric (van Gyzen) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2013-11-02 13:11:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-02 13:11:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-02 13:11:17 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-02 13:11:17 - cleaning the object tree TB --- 2013-11-02 13:12:05 - /usr/local/bin/svn stat /src TB --- 2013-11-02 13:12:08 - At svn revision 257540 TB --- 2013-11-02 13:12:09 - building world TB --- 2013-11-02 13:12:09 - CROSS_BUILD_TESTING=YES TB --- 2013-11-02 13:12:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-02 13:12:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-02 13:12:09 - SRCCONF=/dev/null TB --- 2013-11-02 13:12:09 - TARGET=ia64 TB --- 2013-11-02 13:12:09 - TARGET_ARCH=ia64 TB --- 2013-11-02 13:12:09 - TZ=UTC TB --- 2013-11-02 13:12:09 - __MAKE_CONF=/dev/null TB --- 2013-11-02 13:12:09 - cd /src TB --- 2013-11-02 13:12:09 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Nov 2 13:12:16 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 2 14:49:11 UTC 2013 TB --- 2013-11-02 14:49:11 - generating LINT kernel config TB --- 2013-11-02 14:49:11 - cd /src/sys/ia64/conf TB --- 2013-11-02 14:49:11 - /usr/bin/make -B LINT TB --- 2013-11-02 14:49:11 - cd /src/sys/ia64/conf TB --- 2013-11-02 14:49:11 - /usr/sbin/config -m LINT TB --- 2013-11-02 14:49:11 - building LINT kernel TB --- 2013-11-02 14:49:11 - CROSS_BUILD_TESTING=YES TB --- 2013-11-02 14:49:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-02 14:49:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-02 14:49:11 - SRCCONF=/dev/null TB --- 2013-11-02 14:49:11 - TARGET=ia64 TB --- 2013-11-02 14:49:11 - TARGET_ARCH=ia64 TB --- 2013-11-02 14:49:11 - TZ=UTC TB --- 2013-11-02 14:49:11 - __MAKE_CONF=/dev/null TB --- 2013-11-02 14:49:11 - cd /src TB --- 2013-11-02 14:49:11 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 2 14:49:11 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
Re: 10.0-BETA1 i386 on VirtualBox
В сообщении от Thursday 31 of October 2013 17:54:32 Gleb написал: On Thu, Oct 31, 2013 at 05:48:43PM +0400, Gleb Smirnoff wrote: T B 1. The bug disappeares if I disable VT-x/AMD-V in my virtual machine T B settings (Settings - System - Acceleration) and appeares if I enable it T B (thanks to Gleb for inspiration yesterday). It disappeares everywhere, on T B all revisions. T B T B 2. r244315 seems to be not buggy even with VT-x enabled. So we have to T B look somewhere between r244315 and r248935. T T Good news! Thanks Boris. T T Can you track this down to a particular revision? I have suspision that it is very close to the bhyve checkin: --- - r245652 | neel | 2013-01-19 08:18:52 +0400 (сб, 19 янв 2013) | 9 lines Merge projects/bhyve to head. 'bhyve' was developed by grehan@ and myself at NetApp (thanks!). Special thanks to Peter Snyder, Joe Caradonna and Michael Dexter for their support and encouragement. Obtained from: NetApp --- - since this is the code that started to utilize VT-x. Can you please check this revision and -1 revision to it? r245652 is not buggy. -- С наилучшими пожеланиями, Boris signature.asc Description: This is a digitally signed message part.
Re: Official FreeBSD Binary Packages now available for pkgng
Hi! On 02/11/2013 10:15, Matthias Andree wrote: I understand from Eric's pist that the issue is that through his limiting proxies, the SRV are not available at all so he does not even get to the point where he could get the pkgN.nyi.freebsd.org http://pkgN.nyi.freebsd.org name back. That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are done internally to pkg(8), ... which only works, if the DNS server queried answers SRV queries with SRV values. Which is not always true, especially in heavily firewalled environments. -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
Am 02.11.2013 11:51 schrieb Matthew Seaman matt...@freebsd.org: On 02/11/2013 10:15, Matthias Andree wrote: I understand from Eric's pist that the issue is that through his limiting proxies, the SRV are not available at all so he does not even get to the point where he could get the pkgN.nyi.freebsd.org http://pkgN.nyi.freebsd.org name back. That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are done internally to pkg(8), which then issues an HTTP GET to the specific mirror selected by its internal algorithms. The web cache won't see literal 'pkg.freebsd.org' anywhere in the HTTP traffic -- as far as it is concerned, it's a simple HTTP request to a specific mirror 'pkg1.nyi.freebsd.org', and can be cached using the usual processes. What makes it cache unfriendly is that as far as the web cache is concerned each of the different mirrors appears to be completely independent of the others. So at the moment the chance of getting a cache hit is reduced by a factor of three because of the traffic distribution across the three mirrors. Just to add another viewpoint. The redports backendmachines are put into an IPv6 private address space without default router and without a dns server. The only internet connection that they have is via an squid proxy. This setup works fine now that libfetch supports http proxies also for https urls. This all works based on the assumption that no direct dns lookups are required on the machines itself but all dns stuff is done on the proxy. Your description makes me believe that this won't work for pkgng. So it's not that people in the real world break their network setups but we also use that in our own FreeBSD infrastructure. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On Sat, 02 Nov 2013 09:01:56 -0500, Eric van Gyzen wrote: On 11/02/2013 07:28 AM, Matthew Seaman wrote: I feel no obligation to do anything to encourage people that deliberately break the DNS. They've made their bed, and now they have to lie in it. Eric Camachat didn't break the DNS: his network administrator did. Matthew, you're right: that doesn't make sense. But people do it, often for security, either real or perceived. In this kind of environment, many other things are typically equally broken. I imagine Eric needs all the encouragement he can get. When Matthew mentioned people that deliberately break the DNS, I don't think he meant Eric personally; I think he was referring to Eric's *organisation*. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Overriding sector size on disks?
On Nov 1, 2013, at 9:45 PM, Adrian Chadd adr...@freebsd.org wrote: Hi! I have an odd problem. That, honestly, can't be that odd. I have a bunch of SATA disks that when plugged into the laptop directly, show up as 512 byte sectors. But if I plug it in via this iomega USB caddy, they show up as 4k sector devices. Because of this, partitions just plainly don't work. Has anyone faced this? Is there some trick to do to get these things to go back to being 512 byte sector devices so one can use them? Similarly, because they show up as 512 byte sector devices on macosx/linux, they can read/write NTFS/MSDOS partitions on the thing. But if I plug it into freebsd, it shows up as a 4k sector device and things plainly don't work. Thanks! My coworker ran into this once. We couldn’t find a workaround. We just noted that we either had to use the disk with the adapter or without — you cannot swap between and expect to read your data. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin devin.te...@fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Official FreeBSD Binary Packages now available for pkgng
On 2 November 2013 05:28, Matthew Seaman matt...@freebsd.org wrote: I feel no obligation to do anything to encourage people that deliberately break the DNS. They've made their bed, and now they have to lie in it. Holy, holy crap. * We (as FreeBSD) are not big enough to dictate the direction that technology takes. In this instance, the direction that DNS SRV adoption should be; * This design is inherently not cachable, and as you add more CDN nodes, it will become less cachable; * And as far as I know, you haven't approached any cache vendors (eg Squid) which may have the infrastructure to _handle_ this (which Squid-2.x does, and I think Squid-3.x should be growing soon if it hasn't already.) You've removed the possibility of _standards_ and _well accepted_ HTTP caching techniques without also deploying technology extensions in popular open source projects to cope. You're using a DNS feature which isn't well adopted/supported and you haven't provided a fallback legacy, well tested path. In short, you've taken the least supported paths, glued it into the least HTTP caching scalable paths and not created a suitable fallback. I hate to say it, but pushing the CDN logic into pkgng is a cute but stupid idea for this deployment. Please reconsider this choice before it becomes more widely deployed and you/others have moved onto other things, leaving it to others to clean up. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On Nov 2, 2013, at 11:54 AM, Adrian Chadd adr...@freebsd.org wrote: You're using a DNS feature which isn't well adopted/supported and you haven't provided a fallback legacy, well tested path. But SRV has been widely deployed since… before 2000? It’s literally the backbone of Active Directory deployments. Here’s a list of things that his company’s network design probably breaks: * Office 365 (cloud Exchange hosting by Microsoft; requires you use SRV records to get your company’s clients pointed to their cloud infrastructure) * LDAP * SIP * XMPP * CALDAV / CARDDAV * SMTP, IMAP, and POP clients should also obey published SRV records. Not sure how many clients really do, though. * Teamspeak 3 doesn’t force you to use SRV, but you can use only SRV records * Minecraft * Last I knew IRCv4 specs are slated to include SRV as a core feature I can’t speak for the caching issues, but SRV is pretty active and only getting more popular because things like “round robin DNS” are a horrible, ugly, unreliable hack and things like Anycast or Geo-DNS isn’t always feasible. -0.02c ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-11-02 14:58:01 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-02 14:58:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-02 14:58:01 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-02 14:58:01 - cleaning the object tree TB --- 2013-11-02 14:59:10 - /usr/local/bin/svn stat /src TB --- 2013-11-02 14:59:14 - At svn revision 257540 TB --- 2013-11-02 14:59:15 - building world TB --- 2013-11-02 14:59:15 - CROSS_BUILD_TESTING=YES TB --- 2013-11-02 14:59:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-02 14:59:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-02 14:59:15 - SRCCONF=/dev/null TB --- 2013-11-02 14:59:15 - TARGET=powerpc TB --- 2013-11-02 14:59:15 - TARGET_ARCH=powerpc TB --- 2013-11-02 14:59:15 - TZ=UTC TB --- 2013-11-02 14:59:15 - __MAKE_CONF=/dev/null TB --- 2013-11-02 14:59:15 - cd /src TB --- 2013-11-02 14:59:15 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Nov 2 14:59:22 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 2 17:43:38 UTC 2013 TB --- 2013-11-02 17:43:38 - generating LINT kernel config TB --- 2013-11-02 17:43:38 - cd /src/sys/powerpc/conf TB --- 2013-11-02 17:43:38 - /usr/bin/make -B LINT TB --- 2013-11-02 17:43:38 - cd /src/sys/powerpc/conf TB --- 2013-11-02 17:43:38 - /usr/sbin/config -m LINT TB --- 2013-11-02 17:43:38 - building LINT kernel TB --- 2013-11-02 17:43:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-02 17:43:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-02 17:43:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-02 17:43:38 - SRCCONF=/dev/null TB --- 2013-11-02 17:43:38 - TARGET=powerpc TB --- 2013-11-02 17:43:38 - TARGET_ARCH=powerpc TB --- 2013-11-02 17:43:38 - TZ=UTC TB --- 2013-11-02 17:43:38 - __MAKE_CONF=/dev/null TB --- 2013-11-02 17:43:38 - cd /src TB --- 2013-11-02 17:43:38 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 2 17:43:39 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors /src/sys/dev/netmap/netmap.c: In function 'netmap_ioctl': /src/sys/dev/netmap/netmap.c:2550: warning: cast discards qualifiers from pointer target type /src/sys/dev/netmap/netmap.c: In function 'nm_bdg_preflush': /src/sys/dev/netmap/netmap.c:3219: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *** Error code 1 Stop.
[CFT] bsdinstall and zfsboot enhancements
Hi all, Another Call For Testing... This one is for bsdinstall. Two patchsets are required for this CFT: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/ http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ The enhancements are: + Add a `-D FILE command-line option for overriding the path to the bsdinstall log file (BSDINSTALL_LOG env var). + Document new `-D FILE' in the man page for bsdinstall. + If FILE in `-D FILE' begins with a +, debug output goes to stdout (interleaved between dialog(1) invocations/output) as well as to FILE (minus the leading + of course). + If BSDINSTALL_LOG cannot be written, then debugging is disabled (except in the case of a leading + in the pathname, wherein debug will still be printed to stdout). + Update source code format to approximate a future shstyle(9) + Fix a dangling participle (Begun ... - Began ...) + Rewrite the docsinstall script (was necessary to abate direct dependency on BSDINSTALL_LOG (instead, use fault-tolerant bsdconfig framework which displays appropriate errors for package management). + Add additional debug output for dhclient/rtsol/wpa_cliscan + Display script errors in a textbox rather than just on stdout + Update many coments. + Add new f_show_err() API call (like f_show_msg but changes the dialog title to Error)(see bsdconfig's `common.subr'). + Add new f_eval_catch() API call for executing a command via eval but not before logging the command to debug. Several example cases documented in API header for function in bsdconfig's `common.subr'. + Fix dialog auto-sizing when launched as an rvalue to a pipe for indirected scripts (previously would default to 80x24 sizing in this case, now it can autosize to full size even when in a pipe chain). + Fix a bug in f_snprintf wherein if the $format argument began with a - or -- it would be misinterpreted as a flag to printf. (this is in bsdcofig's strings.subr) + Add accompanying f_sprintf() and f_vsprintf() to go along with already existing f_snprintf() and f_vsnprintf() (see bsdconfig's strings.subr). + Update bsdinstall's config script to adjust ttyu* entries in /etc/ttys when it is determined that we are in-fact doing an install over serial (e.g. bhyve). + Remove some unnecessary default ZFS datasets from the automatic zfsboot script. Such as: /usr/ports/distfiles /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and /var/run (these can all be created as-needed once the system is installed). + Remove setuid=off for /usr/home (as discussed with others from last round of CFT). + Fix some i18n string violations in zfsboot + Bolster debugging output in zfsboot + Fix some string quoting issues in zfsboot + Fix some variable scope issues in zfsboot + Only display the ZFS vdev type selection menu when running interactively (duh). + Change Create to Install in zfsboot main menu + Increase pedantic error checking in zfsboot (type-check arguments and such). + Add a call to graid destroy to kill automatic metadata (part of the series of pedantic destructions we do when bootstrapping a new/naked disk). + Make judicious use of new f_eval_catch() in zfsboot + More comments (zfsboot). + Fixup some variable names for consistency (zfsboot). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-11-02 16:56:53 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-02 16:56:53 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-02 16:56:53 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-02 16:56:53 - cleaning the object tree TB --- 2013-11-02 16:57:53 - /usr/local/bin/svn stat /src TB --- 2013-11-02 16:57:56 - At svn revision 257540 TB --- 2013-11-02 16:57:57 - building world TB --- 2013-11-02 16:57:57 - CROSS_BUILD_TESTING=YES TB --- 2013-11-02 16:57:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-02 16:57:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-02 16:57:57 - SRCCONF=/dev/null TB --- 2013-11-02 16:57:57 - TARGET=sparc64 TB --- 2013-11-02 16:57:57 - TARGET_ARCH=sparc64 TB --- 2013-11-02 16:57:57 - TZ=UTC TB --- 2013-11-02 16:57:57 - __MAKE_CONF=/dev/null TB --- 2013-11-02 16:57:57 - cd /src TB --- 2013-11-02 16:57:57 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Nov 2 16:58:04 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sat Nov 2 18:04:42 UTC 2013 TB --- 2013-11-02 18:04:42 - generating LINT kernel config TB --- 2013-11-02 18:04:42 - cd /src/sys/sparc64/conf TB --- 2013-11-02 18:04:42 - /usr/bin/make -B LINT TB --- 2013-11-02 18:04:42 - cd /src/sys/sparc64/conf TB --- 2013-11-02 18:04:42 - /usr/sbin/config -m LINT TB --- 2013-11-02 18:04:42 - building LINT kernel TB --- 2013-11-02 18:04:42 - CROSS_BUILD_TESTING=YES TB --- 2013-11-02 18:04:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-02 18:04:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-02 18:04:42 - SRCCONF=/dev/null TB --- 2013-11-02 18:04:42 - TARGET=sparc64 TB --- 2013-11-02 18:04:42 - TARGET_ARCH=sparc64 TB --- 2013-11-02 18:04:42 - TZ=UTC TB --- 2013-11-02 18:04:42 - __MAKE_CONF=/dev/null TB --- 2013-11-02 18:04:42 - cd /src TB --- 2013-11-02 18:04:42 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Nov 2 18:04:42 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float
Re: Official FreeBSD Binary Packages now available for pkgng
Am 02.11.2013 11:50, schrieb Matthew Seaman: On 02/11/2013 10:15, Matthias Andree wrote: I understand from Eric's pist that the issue is that through his limiting proxies, the SRV are not available at all so he does not even get to the point where he could get the pkgN.nyi.freebsd.org http://pkgN.nyi.freebsd.org name back. That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are done internally to pkg(8), which then issues an HTTP GET to the specific mirror selected by its internal algorithms. The web cache won't see literal 'pkg.freebsd.org' anywhere in the HTTP traffic -- as far as it is concerned, it's a simple HTTP request to a specific mirror 'pkg1.nyi.freebsd.org', and can be cached using the usual processes. What makes it cache unfriendly is that as far as the web cache is concerned each of the different mirrors appears to be completely independent of the others. So at the moment the chance of getting a cache hit is reduced by a factor of three because of the traffic distribution across the three mirrors. I think it does make sense - if the end user is behind a site where he must use a proxy because his end user's computer does not resolve any external addresses, then SRV is not getting you anywhere and you need a HTTP(S)-based redirector. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On 2 November 2013 10:44, Mark Felder f...@freebsd.org wrote: But SRV has been widely deployed since… before 2000? It’s literally the backbone of Active Directory deployments. Here’s a list of things that his company’s network design probably breaks: * Office 365 (cloud Exchange hosting by Microsoft; requires you use SRV records to get your company’s clients pointed to their cloud infrastructure) * LDAP * SIP * XMPP * CALDAV / CARDDAV * SMTP, IMAP, and POP clients should also obey published SRV records. Not sure how many clients really do, though. * Teamspeak 3 doesn’t force you to use SRV, but you can use only SRV records * Minecraft * Last I knew IRCv4 specs are slated to include SRV as a core feature Wonderful. I can’t speak for the caching issues, but SRV is pretty active and only getting more popular because things like “round robin DNS” are a horrible, ugly, unreliable hack and things like Anycast or Geo-DNS isn’t always feasible. I can speak for the caching issues. It's a non-starter. I'd rather see patches to Squid and such that support more automated SRV handling (if it doesn't already do it; I haven't checked lately!) and make things work correctly with caching. With a fallback, of course, to A records. A lot of HTTP infrastructure lives on anycast DNS, HTTP redirects and geoip records. Saying it's broken and not feasible is nonsense. Also - all you have to do is require all the servers in your farm to handle requests for 'pkg.freebsd.org' rather than 'somethinguniqueperhost.freebsd.org' and then teach pkgng to actually issue requests for that, and caching will mostly just work again. Right now you're having SRV return a set of named aliases to issue requests to and this set of hostnames is what's breaking effective caching. Sheesh! -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ia64 r255488: spontaneous reboots, no panic, no trace in logs
On r255488 ia64 I get spontaneous reboots, which are more or less reproducible. These are triggered by nginx serving poudriere built packages. The is no panic, and no traces in the logs. The system just reboots. A similar issue was seen in about 2011, when we tried to build is64 packages on portscluster. I think marcel@ gave up on it. Has any new diagnostics been added since then? Anything else I could try to see what is going on prior to the reboot? Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On Nov 2, 2013, at 3:27 PM, Adrian Chadd adr...@freebsd.org wrote: A lot of HTTP infrastructure lives on anycast DNS, HTTP redirects and geoip records. Saying it's broken and not feasible is nonsense. More specifically what I was referring to was the fact that traditionally HTTP failover with round-robin A records is very unreliable; every client can act differently. You really need to be doing anycast as well to ensure those records are always available which adds additional architecture complexity that the project may not have the resources to throw at. GeoDNS also adds a layer of complexity, but as it turns out there are members of the project with extensive experience running it. SRV would give us very simple, cheap, reliable failover. It seems we do have some blockers, though. The good news is that we fully control the client. Hopefully we can just work around these issues. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] bsdinstall and zfsboot enhancements
On Sat, Nov 2, 2013 at 1:59 PM, Teske, Devin devin.te...@fisglobal.comwrote: Hi all, Another Call For Testing... This one is for bsdinstall. Two patchsets are required for this CFT: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/ http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ The enhancements are: + Add a `-D FILE command-line option for overriding the path to the bsdinstall log file (BSDINSTALL_LOG env var). + Document new `-D FILE' in the man page for bsdinstall. + If FILE in `-D FILE' begins with a +, debug output goes to stdout (interleaved between dialog(1) invocations/output) as well as to FILE (minus the leading + of course). + If BSDINSTALL_LOG cannot be written, then debugging is disabled (except in the case of a leading + in the pathname, wherein debug will still be printed to stdout). + Update source code format to approximate a future shstyle(9) + Fix a dangling participle (Begun ... - Began ...) + Rewrite the docsinstall script (was necessary to abate direct dependency on BSDINSTALL_LOG (instead, use fault-tolerant bsdconfig framework which displays appropriate errors for package management). + Add additional debug output for dhclient/rtsol/wpa_cliscan + Display script errors in a textbox rather than just on stdout + Update many coments. + Add new f_show_err() API call (like f_show_msg but changes the dialog title to Error)(see bsdconfig's `common.subr'). + Add new f_eval_catch() API call for executing a command via eval but not before logging the command to debug. Several example cases documented in API header for function in bsdconfig's `common.subr'. + Fix dialog auto-sizing when launched as an rvalue to a pipe for indirected scripts (previously would default to 80x24 sizing in this case, now it can autosize to full size even when in a pipe chain). + Fix a bug in f_snprintf wherein if the $format argument began with a - or -- it would be misinterpreted as a flag to printf. (this is in bsdcofig's strings.subr) + Add accompanying f_sprintf() and f_vsprintf() to go along with already existing f_snprintf() and f_vsnprintf() (see bsdconfig's strings.subr). + Update bsdinstall's config script to adjust ttyu* entries in /etc/ttys when it is determined that we are in-fact doing an install over serial (e.g. bhyve). + Remove some unnecessary default ZFS datasets from the automatic zfsboot script. Such as: /usr/ports/distfiles /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and /var/run (these can all be created as-needed once the system is installed). + Remove setuid=off for /usr/home (as discussed with others from last round of CFT). + Fix some i18n string violations in zfsboot + Bolster debugging output in zfsboot + Fix some string quoting issues in zfsboot + Fix some variable scope issues in zfsboot + Only display the ZFS vdev type selection menu when running interactively (duh). + Change Create to Install in zfsboot main menu + Increase pedantic error checking in zfsboot (type-check arguments and such). + Add a call to graid destroy to kill automatic metadata (part of the series of pedantic destructions we do when bootstrapping a new/naked disk). + Make judicious use of new f_eval_catch() in zfsboot + More comments (zfsboot). + Fixup some variable names for consistency (zfsboot). nice work, looks good, patched the bootloader also, seems to function well, love the kernel selection variable -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Sat, Nov 2, 2013 at 12:47 PM, Teske, Devin devin.te...@fisglobal.comwrote: On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin devin.te...@fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. patched the bootloader, seems to function well, love the kernel selection variable -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Sat, Nov 2, 2013 at 9:47 AM, Teske, Devin devin.te...@fisglobal.com wrote: where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Thanks for the patches. Tried on stable/9 and they worked great for me. Do you have anything similar to select boot environment as well? --Artem ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] bsdinstall and zfsboot enhancements
On 11/02/13 12:59, Teske, Devin wrote: Hi all, Another Call For Testing... This one is for bsdinstall. Will look at the rest later... + Update bsdinstall's config script to adjust ttyu* entries in /etc/ttys when it is determined that we are in-fact doing an install over serial (e.g. bhyve). I think this is the wrong solution. The installer is run in a lot of circumstances, and tying it to the boot environment is a mistake. If we want serial consoles to default to on for x86, they should default to on (they do for most other architectures). The magic should never ever be in the installer. Setting the terminal type to vt100 unconditionally is also questionable. Using kbdcontrol also doesn't do the right thing, since it will turn on serial consoles if you install to, say, a disk image from an xterm or if you use newcons. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fatal trap 12: page fault while in kernel mode (FUSE related?)
On Fri, Nov 1, 2013 at 6:03 AM, Alexey Dokuchaev da...@nsu.ru wrote: On Thu, Oct 31, 2013 at 09:59:42AM -0700, Kevin Oberman wrote: On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev da...@nsu.ru wrote: I was running out of space on my UFS partition and decided to use big NTFS one I also have on the drive. I've mounted it with ntfs-3g and our native fuse.ko. I needed the scratch space to built Open/LibreOffice on it *LOL*. Well, it failed with a panic (see the excerpt from text core at the end of this email; full debug info is available upon request). I get a very similar panic when I attempt an rsync from a remote system to my NTFS drive. Very easy to reproduce. Something in fuse goes off the rails under active R/W activity, it seems. Hmm, given more people are seeing it, and it's not too hard to reproduce, I hope it can be tracked down and nailed. I will enable debugging features in my kernel so I can gather some data when this shit happens again to me. ./danfe Just to be clear, my software was built from source, so the package repo is irrelevant. Also, I am running 9.2-Stable with fuse in the kernel (not a module) backported from the 10.0 code and the mount_fuse from 10.0, as well, so mine is a rather odd system. I should be able to capture dump, but I don't have one now. I should also mention that the FreeBSD kernel code was updated in July to 7.10, but was reverted five days later to 7.8 due to issues with fusefs_libs not getting along with it. At the time it was suggested that fusefs_libs would need to be updated to match. (I have no idea how tricky this might be, but it is way beyond my capability. Guess it's almost time to update to 10.0. I really should have moved to HEAD before 10-STABLE was branched. Then I'll be running fully supported code. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
