Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168
On (22/03/2013 11:51), Shawn Webb wrote:
> Hey All,
>
> I'm not sure if this is a result of r248583 or a different commit, but I
> hit a kernel panic when closing Chrome. I've linked to the info and
> core.txt files below. If you need me to ship you the vmcore file, let me
> know. It's 1.1GB in size.
>
> Other than the pasted files, I'm not too sure where to go from here. If
> there's any other info you need, please let me know. I'm a newb at
> submitting this kind of stuff.
>
> Paste of info file: http://ix.io/4Qo
> Paste of core.txt file: http://ix.io/4Qp
Shawn, did you find workaround for the problem?
I've just upgraded to recent HEAD and see the same panic on closing
chrome. Switching back to r247601 just before "Merge Capsicum overhaul"
commit makes panic disappear.
~ # kgdb -n 1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
VNASSERT failed
0xfe0196700760: tag none, type VBAD
usecount 0, writecount 0, refcount 0 mountedhere 0
flags (VV_NOSYNC|VI_DOOMED)
lock type zfs: UNLOCKED
panic: No vop_advlock(0xfe0196700760, 0xff823adb9908)
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff823adb9740
kdb_backtrace() at kdb_backtrace+0x39/frame 0xff823adb97f0
vpanic() at vpanic+0x127/frame 0xff823adb9830
kassert_panic() at kassert_panic+0x136/frame 0xff823adb98a0
VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x92/frame 0xff823adb98d0
closef() at closef+0x9a/frame 0xff823adb9960
closefp() at closefp+0xa0/frame 0xff823adb99b0
amd64_syscall() at amd64_syscall+0x1f9/frame 0xff823adb9ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff823adb9ab0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80aeaaa8a, rsp =
0x7ebf3f38, rbp = 0x7ebf3f50 ---
[...]
(kgdb) fr 0
#0 doadump (textdump=1) at pcpu.h:231
231 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) up
#1 0x804f5827 in kern_reboot (howto=260) at
/freebsd-src/local/sys/kern/kern_shutdown.c:447
447 doadump(TRUE);
(kgdb)
#2 0x804f5d36 in vpanic (fmt=, ap=)
at /freebsd-src/local/sys/kern/kern_shutdown.c:754
754 kern_reboot(bootopt);
(kgdb)
#3 0x804f5bc6 in kassert_panic (fmt=)
at /freebsd-src/local/sys/kern/kern_shutdown.c:642
642 vpanic(fmt, ap);
(kgdb)
#4 0x80747aa2 in VOP_ADVLOCK_APV (vop=,
a=0xff823adb9908)
at vnode_if.c:2522
2522VNASSERT(vop != NULL, a->a_vp, ("No vop_advlock(%p, %p)",
a->a_vp, a));
(kgdb)
#5 0x804b8eaa in closef (fp=0xfe014da8ccd0, td=0xfe0014aea920)
at vnode_if.h:1041
1041vnode_if.h: No such file or directory.
in vnode_if.h
(kgdb)
#6 0x804b7030 in closefp (fdp=0xfe001c8c4800, fd=, fp=0xfe014da8ccd0,
td=0xfe0014aea920, holdleaders=)
at /freebsd-src/local/sys/kern/kern_descrip.c:1136
1136error = closef(fp, td);
(kgdb) p *fp
$5 = {f_data = 0xfe0196700760, f_ops = 0x80a477b8, f_cred =
0xfe0067907600,
f_vnode = 0xfe0196700760, f_type = 1, f_vnread_flags = 0, f_flag = 3,
f_count = 0, f_seqcount = 0,
f_nextoff = 16388, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0}, f_offset
= 16388, f_label = 0x0}
(kgdb) p *fp
$6 = {f_data = 0xfe0196700760, f_ops = 0x80a477b8, f_cred =
0xfe0067907600,
f_vnode = 0xfe0196700760, f_type = 1, f_vnread_flags = 0, f_flag = 3,
f_count = 0, f_seqcount = 0,
f_nextoff = 16388, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0}, f_offset
= 16388, f_label = 0x0}
(kgdb) p fp->f_vnode
$7 = (struct vnode *) 0xfe0196700760
(kgdb) p *fp->f_vnode
$8 = {v_tag = 0x807a3e35 "none", v_op = 0x0, v_data = 0x0, v_mount =
0x0, v_nmntvnodes = {
tqe_next = 0xfe014fd95760, tqe_prev = 0xfe011d500958}, v_un =
{vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev =
0x0}, v_cache_src = {
lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last =
0xfe01967007b0}, v_cache_dd = 0x0,
v_lock = {lock_object = {lo_name = 0x80dddbb1 "zfs", lo_flags =
91881472, lo_data = 0,
lo_witness = 0x0}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri =
96}, v_interlock = {
lock_object = {lo_name = 0x807bfbb9 "vnode interlock", lo_flags =
16908288, lo_data = 0,
lo_witness = 0x0}, mtx_lock = 6}, v_vnlock = 0xfe01967007c8,
v_actfreelist = {
tqe_next = 0xfe0031985b10, tqe_prev = 0xfe014fd95820}, v_bufobj =
{bo_mtx = {lock_object = {
lo_name = 0xff
Re: ipfilter(4) needs maintainer
2013/04/13 16:01、Scott Long のメッセージ: > Maybe something else, but whatever it is, it should be done. If you and Gleb > don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html ___ 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: ipfilter(4) needs maintainer
On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote: > On 2013/04/13, at 5:03, Scott Long wrote: >> You target audience for this isn't people who track CURRENT, it's people who >> are on 7, 8, or 9 and looking to update to 10.x sometime in the future. > > Yes, I'm aware of that, but the problem remains. If ipfilter is broken or > gets broken because of the networking stack changes, we'll have to fix it to > keep the deprecation path going... > Welcome to the challenges of maintaining a whole OS :-) So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. >>> >>> >>> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but >>> I'm not sure automated tools exist. I'm also not convinced we need to write >>> them and I think the issue can be deal with by writing a bunch of examples >>> on how to do it manually. Then we can give people 1y to switch. >> >> Please believe me that no matter how trivial you think the switch is, a >> migration guide still needs to be written. > > > A migration *guide*, yes. Tools to convert one syntax to another: no. > Ok, so in response to this and to Glebs email, lets rephrase the call for help into a call for someone with ipfilter experience to help write a migration guide. Like I said, this isn't about migrating from 10-current to 10-current prime, it about migrating from 7/8/9 where up ipfilter does work. Maybe look for old openbsd docs and mailing list items from when they did their forced migration. Maybe fish for help by announcing the deprecation and removal schedule and hook whomever complains into helping instead. Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. Scott ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
Hi -- On 13.04.2013, at 14:29, Kimmo Paasiala wrote: [great deal of simplification by ipv6_addrs_IF] > Sorry to resurrect this thread but since nothing has happened in about > three months I have to ask: What can I do to have this commited to > HEAD? +1 Nowadays -where IPv6 becomes more and more available by ISPs- I *really* would like to see this simplification implemented, soon, very soon. The current scheme is way to much error prone, and, its a pain in the ass! Thanks for the patch, Michael ___ 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 armv6/arm
TB --- 2013-04-13 15:50:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-13 15:50:18 - 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-04-13 15:50:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-04-13 15:50:18 - cleaning the object tree TB --- 2013-04-13 15:51:23 - /usr/local/bin/svn stat /src TB --- 2013-04-13 15:51:26 - At svn revision 249439 TB --- 2013-04-13 15:51:27 - building world TB --- 2013-04-13 15:51:27 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 15:51:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 15:51:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 15:51:27 - SRCCONF=/dev/null TB --- 2013-04-13 15:51:27 - TARGET=arm TB --- 2013-04-13 15:51:27 - TARGET_ARCH=armv6 TB --- 2013-04-13 15:51:27 - TZ=UTC TB --- 2013-04-13 15:51:27 - __MAKE_CONF=/dev/null TB --- 2013-04-13 15:51:27 - cd /src TB --- 2013-04-13 15:51:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 13 15:51:31 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 Apr 13 18:52:18 UTC 2013 TB --- 2013-04-13 18:52:18 - generating LINT kernel config TB --- 2013-04-13 18:52:18 - cd /src/sys/arm/conf TB --- 2013-04-13 18:52:18 - /usr/bin/make -B LINT TB --- 2013-04-13 18:52:18 - cd /src/sys/arm/conf TB --- 2013-04-13 18:52:18 - /usr/sbin/config -m LINT TB --- 2013-04-13 18:52:18 - skipping LINT kernel TB --- 2013-04-13 18:52:18 - cd /src/sys/arm/conf TB --- 2013-04-13 18:52:18 - /usr/sbin/config -m AC100 TB --- 2013-04-13 18:52:18 - building AC100 kernel TB --- 2013-04-13 18:52:18 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 18:52:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 18:52:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 18:52:18 - SRCCONF=/dev/null TB --- 2013-04-13 18:52:18 - TARGET=arm TB --- 2013-04-13 18:52:18 - TARGET_ARCH=armv6 TB --- 2013-04-13 18:52:18 - TZ=UTC TB --- 2013-04-13 18:52:18 - __MAKE_CONF=/dev/null TB --- 2013-04-13 18:52:18 - cd /src TB --- 2013-04-13 18:52:18 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Sat Apr 13 18:52:18 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 >>> Kernel build for AC100 completed on Sat Apr 13 18:55:09 UTC 2013 TB --- 2013-04-13 18:55:09 - cd /src/sys/arm/conf TB --- 2013-04-13 18:55:09 - /usr/sbin/config -m ARMADAXP TB --- 2013-04-13 18:55:09 - building ARMADAXP kernel TB --- 2013-04-13 18:55:09 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 18:55:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 18:55:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 18:55:09 - SRCCONF=/dev/null TB --- 2013-04-13 18:55:09 - TARGET=arm TB --- 2013-04-13 18:55:09 - TARGET_ARCH=armv6 TB --- 2013-04-13 18:55:09 - TZ=UTC TB --- 2013-04-13 18:55:09 - __MAKE_CONF=/dev/null TB --- 2013-04-13 18:55:09 - cd /src TB --- 2013-04-13 18:55:09 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP >>> Kernel build for ARMADAXP started on Sat Apr 13 18:55:09 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 >>> Kernel build for ARMADAXP completed on Sat Apr 13 18:59:02 UTC 2013 TB --- 2013-04-13 18:59:02 - cd /src/sys/arm/conf TB --- 2013-04-13 18:59:02 - /usr/sbin/config -m ATMEL TB --- 2013-04-13 18:59:02 - skipping ATMEL kernel TB --- 2013-04-13 18:59:03 - cd /src/sys/arm/conf TB --- 2013-04-13 18:59:03 - /usr/sbin/config -m AVILA TB --- 2013-04-13 18:59:03 - skipping AVILA kernel TB --- 2013-04-13 18:59:03 - cd /src/sys/arm/conf TB --- 2013-04-13 18:59:03 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-04-13 18:59:03 - building BEAGLEBONE kernel TB --- 2013-04-13 18:59:03 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 18:59:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 18:59:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 18:59:03 - SRCCONF=/dev/null TB --- 2013-04-13 18:59:03 - TARGET=arm TB --- 2013-04-13 18:59:03 - TARGET_ARCH=armv6 TB --- 2013-04-13 18:59:03 - TZ=UTC TB --- 2013-04-13 18:59:03 - __MAKE_CONF=/dev/null TB --- 2013-04-13 18:59:03 - cd /src TB --- 2013-04-13 18:59:03 - /usr/bin/make -B buildkernel KERNCONF=BEAGLEBONE >>> Kernel build for BEAGLEBONE started on Sat Apr 13 18:59:03 UTC 2013 >>> st
CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@
Trying to recompile converters/libiconv on FreeBSD 10.0-CUR/r49438 (with
bran new CLANG 3.3) results with the errors below. This error shows up
on boxes having FBSD 10 and X11. It doesn't show up on those boxes
running without a full X11 (that is the only difference I can figure out
at the moment since the different systems share a lot of configuration
stuff, having different CPU types (C2D, Sandy-Bridge, Ivy-Bridge) but
nothing I can figure out as the source of the strange behaviour and
error).
Maybe someone has a hint what this could be ...
Thanks in advance and regards,
Oliver
converters/libiconv:
[...]
rm -f unitypes.h-t unitypes.h && { echo '/* DO NOT EDIT! GENERATED
AUTOMATICALLY! */'; cat ./unitypes.in.h; } > unitypes.h-t && mv -f
unitypes.h-t unitypes.h
rm -f uniwidth.h-t uniwidth.h && { echo '/* DO NOT EDIT! GENERATED
AUTOMATICALLY! */'; cat ./uniwidth.in.h; } > uniwidth.h-t && mv -f
uniwidth.h-t uniwidth.h
make all-am
cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib -I../intl
-DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1-O2 -pipe -O3
-march=native -fno-strict-aliasing -c allocator.c
cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib -I../intl
-DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1-O2 -pipe -O3
-march=native -fno-strict-aliasing -c areadlink.c
In file included from areadlink.c:27:
In file included from ./careadlinkat.h:23:
In file included from ./fcntl.h:62:
./unistd.h:694:5: error: invalid token at start of a preprocessor
expression
#if @GNULIB_EUIDACCESS@
^
1 error generated.
*** [areadlink.o] Error code 1
Stop in /usr/ports/converters/libiconv/work/libiconv-1.14/srclib.
*** [all] Error code 1
Stop in /usr/ports/converters/libiconv/work/libiconv-1.14/srclib.
*** [all] Error code 1
Stop in /usr/ports/converters/libiconv/work/libiconv-1.14.
*** [do-build] Error code 1
Stop in /usr/ports/converters/libiconv.
*** [install] Error code 1
Stop in /usr/ports/converters/libiconv.
*** [reinstall] Error code 1
Stop in /usr/ports/converters/libiconv.
signature.asc
Description: This is a digitally signed message part
Re: ipfilter(4) needs maintainer
On 2013/04/13, at 5:03, Scott Long wrote: > You target audience for this isn't people who track CURRENT, it's people who > are on 7, 8, or 9 and looking to update to 10.x sometime in the future. Yes, I'm aware of that, but the problem remains. If ipfilter is broken or gets broken because of the networking stack changes, we'll have to fix it to keep the deprecation path going... >>> So with that said, would it be possible to write some tutorials on how to >>> migrate an ipfilter installation to pf? Maybe some mechanical syntax docs >>> accompanied by a few case studies? Is it possible for a script to automate >>> some of the common mechanical changes? Also essential is a clear document >>> on what goes away with ipfilter and what is gained with pf. Once those >>> tools are written, I suggest announcing that ipfilter is available but >>> deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. >>> Certain people will still pitch a fit about it departing, but if the tools >>> are there to help the common users, you'll be successful in winning >>> mindshare and general support. >> >> >> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but >> I'm not sure automated tools exist. I'm also not convinced we need to write >> them and I think the issue can be deal with by writing a bunch of examples >> on how to do it manually. Then we can give people 1y to switch. >> > > Please believe me that no matter how trivial you think the switch is, a > migration guide still needs to be written. A migration *guide*, yes. Tools to convert one syntax to another: no. Regards, -- Rui Paulo ___ 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: ipfilter(4) needs maintainer
Scott, On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote: S> One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing "ipfilter is going away. EOM" is inadequate and leads to completely justified complaints from users. S> S> So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. The task to write a migration guide is already a task for maintainer, and the thread is to search one. If lack of migration guide doesn't allow us to remove in 10.x cycle, I doubt the guide will appear in 11.x cycle, 12.x, etc. So we will live with ipfilter forever. What I can do, is to resend email to the stable@ list. Also, I can add the deprecation WARNING to stable/9 unless we find maintainer prior to 9.2 branching. -- Totus tuus, Glebius. ___ 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: CURRENT ( > r249381): can't find boot partition on GPT disk
On Sat, 2013-04-13 at 10:07 +, Marcus Reid wrote: > On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote: > > Trying to boot a kernel > r249381 fails and I see on the console the > > loader prompt at "mountroot". Obviously, the bootloader doesn't find > > the root/boot partition. > > Same problem observed here. r249435, gpt zfs root. Entering > "zfs:zroot" at the mountroot prompt allows system to continue booting. > > Marcus The problem vanished with the most recent sources (FreeBSD 10.0-CURRENT #0 r249436: Sat Apr 13 12:23:27 CEST 2013) Oliver signature.asc Description: This is a digitally signed message part
Re: CURRENT ( > r249381): can't find boot partition on GPT disk
On Sat, 13 Apr 2013, Marcus Reid wrote: On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote: Trying to boot a kernel > r249381 fails and I see on the console the loader prompt at "mountroot". Obviously, the bootloader doesn't find the root/boot partition. Same problem observed here. r249435, gpt zfs root. Entering "zfs:zroot" at the mountroot prompt allows system to continue booting. Marcus Same problem here, also with gpt zfs root. Dan ___ 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: Problems with axe(4) and checksum offloading
Hi YongHyeon, Will post on freebsd-ipfw@ as well... Does your engineering sample function normally with rxcsum/txcsum disabled? Kind regards, Spil. On Thu, Apr 11, 2013 at 3:11 AM, YongHyeon PYUN wrote: > On Wed, Apr 10, 2013 at 07:48:00PM +0200, Spil Oss wrote: > > Hi YongHyeon, > > > > With the original unmodified .ko... > > > > ifconfig output as requested at bottom > > > > Static IP-configuration does not make a difference with the ipfw > behaviour. > > > > ipfw ruleset (based on /etc/rc.firewall simple ruleset) > > 00010 allow ip from any to me dst-port 22 recv ue0 > > 00010 allow tcp from me 22 to any xmit ue0 > > 00100 allow ip from any to any via lo0 > > 00200 deny ip from any to 127.0.0.0/8 > > 00300 deny ip from 127.0.0.0/8 to any > > 00400 deny ip from any to ::1 > > 00500 deny ip from ::1 to any > > 00600 allow ipv6-icmp from :: to ff02::/16 > > 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 > > 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 > > 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 > > 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > > 01100 deny ip from 10.16.2.1 to any in via ue0 > > 01200 deny ip from 172.17.2.111 to any in via re0 > > 01300 deny ip from any to 10.0.0.0/8 via ue0 > > 01500 deny ip from any to 192.168.0.0/16 via ue0 > > 01600 deny ip from any to 0.0.0.0/8 via ue0 > > 01700 deny ip from any to 169.254.0.0/16 via ue0 > > 01800 deny ip from any to 192.0.2.0/24 via ue0 > > 01900 deny ip from any to 224.0.0.0/4 via ue0 > > 02000 deny ip from any to 240.0.0.0/4 via ue0 > > 02100 divert 8668 ip4 from any to any via ue0 > > 02200 deny ip from 10.0.0.0/8 to any via ue0 > > 02400 deny ip from 192.168.0.0/16 to any via ue0 > > 02500 deny ip from 0.0.0.0/8 to any via ue0 > > 02600 deny ip from 169.254.0.0/16 to any via ue0 > > 02700 deny ip from 192.0.2.0/24 to any via ue0 > > 02800 deny ip from 224.0.0.0/4 to any via ue0 > > 02900 deny ip from 240.0.0.0/4 to any via ue0 > > 03000 allow tcp from any to any established > > 03100 allow ip from any to any frag > > 03200 allow tcp from any to me dst-port 22 setup > > 03300 allow tcp from any to me dst-port 25 setup > > 03400 allow tcp from any to me dst-port 465 setup > > 03500 allow tcp from any to me dst-port 587 setup > > 03600 allow tcp from any to me dst-port 80 setup > > 03700 allow tcp from any to me dst-port 443 setup > > 03800 deny log logamount 5 ip4 from any to any in via ue0 setup proto tcp > > 03900 allow tcp from any to any setup > > 04000 allow udp from me to any dst-port 53 keep-state > > 04100 allow udp from me to any dst-port 123 keep-state > > 04200 allow ip from any to any dst-port 22 recv ue0 > > 65535 deny ip from any to any > > > > If I remove rule 10 it will NOT work with ue0, the ruleset without rule > 10 > > DOES work with re0. > > > > Found an older PR about em or fxp having trouble with natd when > > rxcsum/txcsum was enabled, that is why I started fiddling with > > rxcsum/txcsum and found that the NIC would be unusable without > > rxcsum/txcsum enabled. If only I could find that PR now > (kern/170081???)... > > Was fixed in base... > > If you don't use ipfw/natd, checksum offloading of axe(4) work? > If yes, you'd get better answer from ipfw mailing list. > > > > > Some other post reported fake AX88772A chips (32-pin packaging vs 64 in > the > > original) on cheap USB NICs so I checked the hardware as well and could > not > > AX88772A does not support TX/RX checksum offloading. > > > see an issue (64-pin packaging). > > > > # ifconfig ue0 > > ue0: flags=8802 metric 0 mtu 1500 > > options=8000b > > ether 00:60:6e:42:5b:53 > > nd6 options=21 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > # dhclient ue0 > > DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 > > DHCPOFFER from 172.17.2.1 > > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > > DHCPACK from 172.17.2.1 > > bound to 172.17.2.111 -- renewal in 43200 seconds. > > > > # ifconfig ue0 > > ue0: flags=8843 metric 0 mtu 1500 > > options=8000b > > ether 00:60:6e:42:5b:53 > > inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7 > > inet 172.17.2.111 netmask 0xff00 broadcast 172.17.2.255 > > nd6 options=21 > > media: Ethernet autoselect (100baseTX ) > > status: active > > I can see TX/RX checksum offloading is active and it successfully > got a IP address via DHCP. > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:14 AM, YongHyeon PYUN > wrote: > > > > > On Mon, Apr 08, 2013 at 08:45:58PM +0200, Spil Oss wrote: > > > > Hi YongHyeon, > > > > > > > > output from verbose boot > > > > > > > > ugen3.2: at usbus3 > > > > axe0: on usbus3 > > > > axe0: PHYADDR 0xe0:0x10 > > > > miibus1: on axe0 > > > > ukphy0: PHY 16 on miibus1 > > > > ukphy0: OUI 0x007063, model 0x0008, rev. 1 > > > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > > > > auto-flow > > > > ue0: on a
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Thu, Jan 17, 2013 at 7:24 AM, Kimmo Paasiala wrote:
> On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin wrote:
>> 2012/12/26 Kimmo Paasiala :
>>
>>> I've revised the patch again and updated it at gihub,
>>> https://gist.github.com/4362018. It can now be applied at top level
>>> of sources (/usr/src typically). It now does the deconfiguration in
>>> reverse order of the configuration, meaning the aliases configured
>>> with ipv6_addrs_IF are removed before the ones configured with
>>> ifconfig_IF_aliasN="inet6 ...".
>>
>> Adapted for FreeBSD 8.2, works fine:
>>
>> --- network.subr.orig 2011-02-17 05:19:39.0 +0300
>> +++ network.subr2012-12-28 00:46:38.0 +0400
>> @@ -312,6 +312,12 @@ afexists()
>> # 1 otherwise.
>> ipv6if()
>> {
>> + # Test for $ipv6_addrs_IF. If it exists then the
>> + # interface should be configured for IPv6
>> + _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
>> + if [ -n "${_tmpargs}" ]; then
>> + return 0
>> + fi
>> if ! checkyesno ipv6_enable; then
>> return 1
>> fi
>> @@ -948,7 +954,12 @@ network6_interface_setup()
>> rtsol_interface=no
>> ifconfig $i inet6 ${ipv6_ifconfig} alias
>> fi
>> -
>> + ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
>> + if [ -n "${ipv6_addrs}" ]; then
>> + rtsol_available=no
>> + rtsol_interface=no
>> + ipv6_addrs_common ${i} alias
>> + fi
>> # Wireless NIC cards are virtualized through the wlan
>> interface
>> if ! is_wired_interface ${i}; then
>> case "${i}" in
>> @@ -1178,3 +1189,39 @@ network6_getladdr()
>> esac
>> done
>> }
>> +
>> +ipv6_addrs_common()
>> +{
>> + local _ret _if _action _ip6prefix _ip6prefixes
>> + local _ip6addr _prefixlen
>> + local _range _ip6net _ip6low _ip6high
>> + _ret=1
>> + _if=$1
>> + _action=$2
>> + # get the prefixes from ipv6_addrs_IF variable
>> + _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
>> + for _ip6prefix in ${_ip6prefixes}; do
>> + _ip6addr=${_ip6prefix%%/*}
>> + _prefixlen=${_ip6prefix##*/}
>> + _range=${_ip6addr##*:}
>> + _ip6net=${_ip6addr%:*}
>> + _ip6low=${_range%-*}
>> + _ip6high=${_range#*-}
>> + # If deleting an alias, set _prefixlen to null string.
>> + if [ "${_action}" = "-alias" ]; then
>> + _prefixlen=""
>> + else
>> + _prefixlen="prefixlen $_prefixlen"
>> + fi
>> + _ip6high=$(("0x${_ip6high}"))
>> + _ip6count=$(("0x${_ip6low}"))
>> + while [ "${_ip6count}" -le "${_ip6high}" ]; do
>> + # Re-uses the _ip6addr variable from above
>> + _ip6addr=$(printf "%x" "${_ip6count}")
>> + eval "ifconfig ${_if} inet6
>> ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}"
>> + _ip6count=$((${_ip6count}+1))
>> + _ret=0
>> + done
>> + done
>> + return $_ret
>> +}
>>
>>
>> --
>> Non nobis Domine non nobis sed Nomini Tuo da gloriam
>> Phil Kulin
>
> I don't have an 8.X system to test but I guess it's fine.
>
> Any more interest in this? I'd love to see this added, not because I
> wrote it but because I want to contribute in any way I can.
>
> -Kimmo
Sorry to resurrect this thread but since nothing has happened in about
three months I have to ask: What can I do to have this commited to
HEAD? I'd be even willing to become a src committer if that's what is
required. I feel that I'm compentent enough. Who can I contact?
-Kimmo
___
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: ipfilter(4) needs maintainer
On Sat, Apr 13, 2013 at 3:03 PM, Scott Long wrote: > > On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote: > >> On 2013/04/12, at 22:31, Scott Long wrote: >> >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > Lack of maintainer in a near future would lead to bitrot due to changes > in other areas of network stack, kernel APIs, etc. This already happens, > many changes during 10.0-CURRENT cycle were only compile tested wrt > ipfilter. If we fail to find maintainer, then a correct decision would be > to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said "I'm still using ipfilter!" and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. >>> >>> One thing that FreeBSD is bad about (and this really applies to many open >>> source projects) when deprecating something is that the developer and >>> release engineering groups rarely provide adequate, if any, tools to help >>> users transition and cope with the deprecation. The fear of deprecation >>> can be largely overcome by giving these users a clear and comprehensive >>> path forward. Just announcing "ipfilter is going away. EOM" is inadequate >>> and leads to completely justified complaints from users. >> >> I agree with the deprecation path, but given the amount of changes that >> happened in the last 6 months, I'm not even sure ipfilter is working fine in >> FreeBSD CURRENT, but I haven't tested it. >> > > You target audience for this isn't people who track CURRENT, it's people who > are on 7, 8, or 9 and looking to update to 10.x sometime in the future. > >>> So with that said, would it be possible to write some tutorials on how to >>> migrate an ipfilter installation to pf? Maybe some mechanical syntax docs >>> accompanied by a few case studies? Is it possible for a script to automate >>> some of the common mechanical changes? Also essential is a clear document >>> on what goes away with ipfilter and what is gained with pf. Once those >>> tools are written, I suggest announcing that ipfilter is available but >>> deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. >>> Certain people will still pitch a fit about it departing, but if the tools >>> are there to help the common users, you'll be successful in winning >>> mindshare and general support. >> >> >> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but >> I'm not sure automated tools exist. I'm also not convinced we need to write >> them and I think the issue can be deal with by writing a bunch of examples >> on how to do it manually. Then we can give people 1y to switch. >> > > Please believe me that no matter how trivial you think the switch is, a > migration guide still needs to be written. > > Scott > \ The migration guide is best written by the current users of ipfilter, not those who have no interest in doing so because their interests are completely elsewhere. Please don't try to defer to an authority that does not exist here. -Kimmo ___ 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: ipfilter(4) needs maintainer
On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote: > On 2013/04/12, at 22:31, Scott Long wrote: > >> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >> >>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>> Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. >>> >>> This has been discussed in the past. Every time someone came up and said >>> "I'm still using ipfilter!" and the idea to remove it dies with it. >>> I've been saying we should remove it for 4 years now. Not only it's >>> outdated but it also doesn't not fit well in the FreeBSD roadmap. Then >>> there's the question of maintainability. We gave the author a commit bit so >>> that he could maintain it. That doesn't happen anymore and it sounds like >>> he has since moved away from FreeBSD. I cannot find any reason to burden >>> another FreeBSD developer with maintaining ipfilter. >>> >> >> One thing that FreeBSD is bad about (and this really applies to many open >> source projects) when deprecating something is that the developer and >> release engineering groups rarely provide adequate, if any, tools to help >> users transition and cope with the deprecation. The fear of deprecation can >> be largely overcome by giving these users a clear and comprehensive path >> forward. Just announcing "ipfilter is going away. EOM" is inadequate and >> leads to completely justified complaints from users. > > I agree with the deprecation path, but given the amount of changes that > happened in the last 6 months, I'm not even sure ipfilter is working fine in > FreeBSD CURRENT, but I haven't tested it. > You target audience for this isn't people who track CURRENT, it's people who are on 7, 8, or 9 and looking to update to 10.x sometime in the future. >> So with that said, would it be possible to write some tutorials on how to >> migrate an ipfilter installation to pf? Maybe some mechanical syntax docs >> accompanied by a few case studies? Is it possible for a script to automate >> some of the common mechanical changes? Also essential is a clear document >> on what goes away with ipfilter and what is gained with pf. Once those >> tools are written, I suggest announcing that ipfilter is available but >> deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. >> Certain people will still pitch a fit about it departing, but if the tools >> are there to help the common users, you'll be successful in winning >> mindshare and general support. > > > It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but > I'm not sure automated tools exist. I'm also not convinced we need to write > them and I think the issue can be deal with by writing a bunch of examples on > how to do it manually. Then we can give people 1y to switch. > Please believe me that no matter how trivial you think the switch is, a migration guide still needs to be written. Scott \ ___ 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: CURRENT ( > r249381): can't find boot partition on GPT disk
On 13.04.2013 12:07 (UTC+2), Marcus Reid wrote: > On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote: >> Trying to boot a kernel > r249381 fails and I see on the console the >> loader prompt at "mountroot". Obviously, the bootloader doesn't find >> the root/boot partition. > > Same problem observed here. r249435, gpt zfs root. Entering > "zfs:zroot" at the mountroot prompt allows system to continue booting. Same here without gtp and zfs, but with ufs. Seems to be solved for me with r249436. Rainer > Marcus ___ 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: CURRENT ( > r249381): can't find boot partition on GPT disk
On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote: > Trying to boot a kernel > r249381 fails and I see on the console the > loader prompt at "mountroot". Obviously, the bootloader doesn't find > the root/boot partition. Same problem observed here. r249435, gpt zfs root. Entering "zfs:zroot" at the mountroot prompt allows system to continue booting. Marcus ___ 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 armv6/arm
TB --- 2013-04-13 04:30:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-13 04:30:26 - 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-04-13 04:30:26 - starting HEAD tinderbox run for armv6/arm TB --- 2013-04-13 04:30:26 - cleaning the object tree TB --- 2013-04-13 04:38:06 - /usr/local/bin/svn stat /src TB --- 2013-04-13 04:38:09 - At svn revision 249434 TB --- 2013-04-13 04:38:10 - building world TB --- 2013-04-13 04:38:10 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 04:38:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 04:38:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 04:38:10 - SRCCONF=/dev/null TB --- 2013-04-13 04:38:10 - TARGET=arm TB --- 2013-04-13 04:38:10 - TARGET_ARCH=armv6 TB --- 2013-04-13 04:38:10 - TZ=UTC TB --- 2013-04-13 04:38:10 - __MAKE_CONF=/dev/null TB --- 2013-04-13 04:38:10 - cd /src TB --- 2013-04-13 04:38:10 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 13 04:38:14 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 Apr 13 07:47:24 UTC 2013 TB --- 2013-04-13 07:47:24 - generating LINT kernel config TB --- 2013-04-13 07:47:24 - cd /src/sys/arm/conf TB --- 2013-04-13 07:47:24 - /usr/bin/make -B LINT TB --- 2013-04-13 07:47:24 - cd /src/sys/arm/conf TB --- 2013-04-13 07:47:24 - /usr/sbin/config -m LINT TB --- 2013-04-13 07:47:24 - skipping LINT kernel TB --- 2013-04-13 07:47:24 - cd /src/sys/arm/conf TB --- 2013-04-13 07:47:24 - /usr/sbin/config -m AC100 TB --- 2013-04-13 07:47:24 - building AC100 kernel TB --- 2013-04-13 07:47:24 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 07:47:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 07:47:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 07:47:24 - SRCCONF=/dev/null TB --- 2013-04-13 07:47:24 - TARGET=arm TB --- 2013-04-13 07:47:24 - TARGET_ARCH=armv6 TB --- 2013-04-13 07:47:24 - TZ=UTC TB --- 2013-04-13 07:47:24 - __MAKE_CONF=/dev/null TB --- 2013-04-13 07:47:24 - cd /src TB --- 2013-04-13 07:47:24 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Sat Apr 13 07:47:24 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 >>> Kernel build for AC100 completed on Sat Apr 13 07:50:02 UTC 2013 TB --- 2013-04-13 07:50:02 - cd /src/sys/arm/conf TB --- 2013-04-13 07:50:02 - /usr/sbin/config -m ARMADAXP TB --- 2013-04-13 07:50:02 - building ARMADAXP kernel TB --- 2013-04-13 07:50:02 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 07:50:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 07:50:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 07:50:02 - SRCCONF=/dev/null TB --- 2013-04-13 07:50:02 - TARGET=arm TB --- 2013-04-13 07:50:02 - TARGET_ARCH=armv6 TB --- 2013-04-13 07:50:02 - TZ=UTC TB --- 2013-04-13 07:50:02 - __MAKE_CONF=/dev/null TB --- 2013-04-13 07:50:02 - cd /src TB --- 2013-04-13 07:50:02 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP >>> Kernel build for ARMADAXP started on Sat Apr 13 07:50:02 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 >>> Kernel build for ARMADAXP completed on Sat Apr 13 07:53:54 UTC 2013 TB --- 2013-04-13 07:53:54 - cd /src/sys/arm/conf TB --- 2013-04-13 07:53:54 - /usr/sbin/config -m ATMEL TB --- 2013-04-13 07:53:54 - skipping ATMEL kernel TB --- 2013-04-13 07:53:54 - cd /src/sys/arm/conf TB --- 2013-04-13 07:53:54 - /usr/sbin/config -m AVILA TB --- 2013-04-13 07:53:54 - skipping AVILA kernel TB --- 2013-04-13 07:53:54 - cd /src/sys/arm/conf TB --- 2013-04-13 07:53:54 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-04-13 07:53:54 - building BEAGLEBONE kernel TB --- 2013-04-13 07:53:54 - CROSS_BUILD_TESTING=YES TB --- 2013-04-13 07:53:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-13 07:53:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-13 07:53:54 - SRCCONF=/dev/null TB --- 2013-04-13 07:53:54 - TARGET=arm TB --- 2013-04-13 07:53:54 - TARGET_ARCH=armv6 TB --- 2013-04-13 07:53:54 - TZ=UTC TB --- 2013-04-13 07:53:54 - __MAKE_CONF=/dev/null TB --- 2013-04-13 07:53:54 - cd /src TB --- 2013-04-13 07:53:54 - /usr/bin/make -B buildkernel KERNCONF=BEAGLEBONE >>> Kernel build for BEAGLEBONE started on Sat Apr 13 07:53:54 UTC 2013 >>> st
CURRENT ( > r249381): can't find boot partition on GPT disk
Trying to boot a kernel > r249381 fails and I see on the console the loader prompt at "mountroot". Obviously, the bootloader doesn't find the root/boot partition. On all FreeBSD 10 boxes I have this phenomenon is the same, all boxes have GPT (UFS) partitions to boot from and set GPT labels to address the partitions: /etc/fstab looks like # DeviceMountpoint FStype Options DumpPass# /dev/gpt/root / ufs rw 1 1 /dev/gpt/swap noneswapsw 0 0 tmpfs /tmptmpfs rw,size=4294967296 0 0 /dev/gpt/var/varufs rw 2 2 tmpfs /var/runtmpfs rw,size=4294967296 0 0 /dev/gpt/var.tmp/var/tmpufs rw 2 2 /dev/gpt/compat /compat ufs rw 2 2 /dev/gpt/usr/usrufs rw 2 2 /dev/gpt/usr.src/usr/srcufs rw 2 2 /dev/gpt/usr.obj/usr/objufs rw 2 2 /dev/gpt/usr.local /usr/local ufs rw 2 2 Booting the old kernel works fine. regards, Oliver signature.asc Description: This is a digitally signed message part
