Re: [rfc] removing the NDISulator
I'd like to remove the NDISulator. I've had many requests to update it to the latest NDIS version and support more of the 64 bit wifi drivers. But, to be perfectly honest, I have no desire to keep hacking at this. The world has changed quite a bit - we can port/reimplement drivers from Linux and other BSDs. So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and target to have it removed by 11.0-RELEASE. I'd rather see more of an effort writing new drivers and porting drivers from other operating systems. Thanks, -adrian I too would like to see more effort writing new Ethernet and wifi drivers and porting from other operating systems. But I would like to keep the NDISulator/NDISwrapper as a fallback. There are still wifi adapters, Ethernet too, where there is no FreeBSD driver (AR9271 for instance), or the FreeBSD driver is buggy. Realtek 8111E on MSI Z77 MPOWER motherboard is one case in point: good with NetBSD-current and Linux but not OpenBSD 5.3 LiveUSB or FreeBSD. I see FreeBSD 10.0-to-be has a bigger selection of drivers than 9.2. I don't see improvements so far in 11-HEAD over 10.0-BETA1, but that's because 11-HEAD is at a very early stage. Regarding NDISulator, I see that it seems nowadays that many MS-Windows driver packages, when unzipped, have setup.exe, some .ini files, some .cab and .hdr files but no .inf and .sys files necessary for the NDISulator. Presumably these files are created/unpacked when the driver is installed in MS-Windows. Tom ___ 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-10-19 03:35:27 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 03:35:27 - 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-10-19 03:35:27 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-10-19 03:35:27 - cleaning the object tree TB --- 2013-10-19 03:35:27 - /usr/local/bin/svn stat /src TB --- 2013-10-19 03:35:30 - At svn revision 256751 TB --- 2013-10-19 03:35:31 - building world TB --- 2013-10-19 03:35:31 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 03:35:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 03:35:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 03:35:31 - SRCCONF=/dev/null TB --- 2013-10-19 03:35:31 - TARGET=powerpc TB --- 2013-10-19 03:35:31 - TARGET_ARCH=powerpc TB --- 2013-10-19 03:35:31 - TZ=UTC TB --- 2013-10-19 03:35:31 - __MAKE_CONF=/dev/null TB --- 2013-10-19 03:35:31 - cd /src TB --- 2013-10-19 03:35:31 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 03:35:38 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 Oct 19 06:19:41 UTC 2013 TB --- 2013-10-19 06:19:41 - generating LINT kernel config TB --- 2013-10-19 06:19:41 - cd /src/sys/powerpc/conf TB --- 2013-10-19 06:19:41 - /usr/bin/make -B LINT TB --- 2013-10-19 06:19:41 - cd /src/sys/powerpc/conf TB --- 2013-10-19 06:19:41 - /usr/sbin/config -m LINT TB --- 2013-10-19 06:19:41 - building LINT kernel TB --- 2013-10-19 06:19:41 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 06:19:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 06:19:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 06:19:41 - SRCCONF=/dev/null TB --- 2013-10-19 06:19:41 - TARGET=powerpc TB --- 2013-10-19 06:19:41 - TARGET_ARCH=powerpc TB --- 2013-10-19 06:19:41 - TZ=UTC TB --- 2013-10-19 06:19:41 - __MAKE_CONF=/dev/null TB --- 2013-10-19 06:19:41 - cd /src TB --- 2013-10-19 06:19:41 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Oct 19 06:19:41 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/geom/geom_vfs.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/geom/geom_vol_ffs.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/geom/journal/g_journal.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
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-10-19 05:13:24 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 05:13:24 - 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-10-19 05:13:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-10-19 05:13:24 - cleaning the object tree TB --- 2013-10-19 05:13:24 - /usr/local/bin/svn stat /src TB --- 2013-10-19 05:13:27 - At svn revision 256751 TB --- 2013-10-19 05:13:28 - building world TB --- 2013-10-19 05:13:28 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 05:13:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 05:13:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 05:13:28 - SRCCONF=/dev/null TB --- 2013-10-19 05:13:28 - TARGET=sparc64 TB --- 2013-10-19 05:13:28 - TARGET_ARCH=sparc64 TB --- 2013-10-19 05:13:28 - TZ=UTC TB --- 2013-10-19 05:13:28 - __MAKE_CONF=/dev/null TB --- 2013-10-19 05:13:28 - cd /src TB --- 2013-10-19 05:13:28 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 05:13:36 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 Oct 19 06:21:30 UTC 2013 TB --- 2013-10-19 06:21:30 - generating LINT kernel config TB --- 2013-10-19 06:21:30 - cd /src/sys/sparc64/conf TB --- 2013-10-19 06:21:30 - /usr/bin/make -B LINT TB --- 2013-10-19 06:21:31 - cd /src/sys/sparc64/conf TB --- 2013-10-19 06:21:31 - /usr/sbin/config -m LINT TB --- 2013-10-19 06:21:31 - building LINT kernel TB --- 2013-10-19 06:21:31 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 06:21:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 06:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 06:21:31 - SRCCONF=/dev/null TB --- 2013-10-19 06:21:31 - TARGET=sparc64 TB --- 2013-10-19 06:21:31 - TARGET_ARCH=sparc64 TB --- 2013-10-19 06:21:31 - TZ=UTC TB --- 2013-10-19 06:21:31 - __MAKE_CONF=/dev/null TB --- 2013-10-19 06:21:31 - cd /src TB --- 2013-10-19 06:21:31 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Oct 19 06:21:31 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/geom/geom_vfs.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/geom/geom_vol_ffs.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/geom/journal/g_journal.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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2013-10-19 04:49:37 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 04:49:37 - 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-10-19 04:49:37 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-10-19 04:49:37 - cleaning the object tree TB --- 2013-10-19 04:49:37 - /usr/local/bin/svn stat /src TB --- 2013-10-19 04:49:41 - At svn revision 256751 TB --- 2013-10-19 04:49:42 - building world TB --- 2013-10-19 04:49:42 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:49:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:49:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:49:42 - SRCCONF=/dev/null TB --- 2013-10-19 04:49:42 - TARGET=powerpc TB --- 2013-10-19 04:49:42 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 04:49:42 - TZ=UTC TB --- 2013-10-19 04:49:42 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:49:42 - cd /src TB --- 2013-10-19 04:49:42 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 04:49:49 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 stage 5.1: building 32 bit shim libraries World build completed on Sat Oct 19 07:58:17 UTC 2013 TB --- 2013-10-19 07:58:17 - generating LINT kernel config TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/bin/make -B LINT TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/sbin/config -m LINT TB --- 2013-10-19 07:58:17 - skipping LINT kernel TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/sbin/config -m GENERIC TB --- 2013-10-19 07:58:17 - skipping GENERIC kernel TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/sbin/config -m GENERIC64 TB --- 2013-10-19 07:58:17 - building GENERIC64 kernel TB --- 2013-10-19 07:58:17 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 07:58:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 07:58:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 07:58:17 - SRCCONF=/dev/null TB --- 2013-10-19 07:58:17 - TARGET=powerpc TB --- 2013-10-19 07:58:17 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 07:58:17 - TZ=UTC TB --- 2013-10-19 07:58:17 - __MAKE_CONF=/dev/null TB --- 2013-10-19 07:58:17 - cd /src TB --- 2013-10-19 07:58:17 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 Kernel build for GENERIC64 started on Sat Oct 19 07:58:17 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 -g -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_subr.c ctfconvert -L VERSION -g geom_subr.o cc -c -O -pipe -std=c99 -g -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c ctfconvert -L VERSION -g geom_vfs.o cc -c -O -pipe -std=c99 -g -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc
Re: gcc kernel build fail @ SVN r256730
Wiadomość napisana przez Michael Butler i...@protected-networks.net w dniu 18 paź 2013, o godz. 14:15: -current kernel compiled with gcc fails with: cc1: warnings being treated as errors /usr/src/sys/geom/label/g_label.c: In function 'g_label_resize': /usr/src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** [g_label.o] Error code 1 Should be fixed now. Sorry for the breakage. ___ 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: ZFS secondarycache on SSD problem on r255173
Ok. Just right now system rebooted with you patch.
Trim enabled again.
WIll wait some time untile size of used cache grow's.
Steven Hartland wrote:
SH Looking at the l2arc compression code I believe that metadata is always
SH compressed with lz4, even if compression is off on all datasets.
SH
SH This is backed up by what I'm seeing on my system here as it shows a
SH non-zero l2_compress_successes value even though I'm not using
SH compression at all.
SH
SH I think we we may well need the following patch to set the minblock
SH size based on the vdev ashift and not SPA_MINBLOCKSIZE.
SH
SH svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
SH Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
SH ===
SH --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c(revision
256554)
SH +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c(working
copy)
SH @@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr)
SH len = l2hdr-b_asize;
SH cdata = zio_data_buf_alloc(len);
SH csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr-b_tmp_cdata,
SH - cdata, l2hdr-b_asize, (size_t)SPA_MINBLOCKSIZE);
SH + cdata, l2hdr-b_asize, (size_t)(1ULL
l2hdr-b_dev-l2ad_vdev-vdev_ashift));
SH
SH if (csize == 0) {
SH /* zero block, indicate that there's nothing to write */
SH
SH Could you try this patch on your system Vitalij see if it has any effect
SH on the number of l2_cksum_bad / l2_io_error?
SH
SH Regards
SH Steve
SH - Original Message -
SH From: Vitalij Satanivskij sa...@ukr.net
SH To: Steven Hartland kill...@multiplay.co.uk
SH Cc: Vitalij Satanivskij sa...@ukr.net; Dmitriy Makarov
suppor...@ukr.net; Justin T. Gibbs gi...@freebsd.org; Borja
SH Marcos bor...@sarenet.es; freebsd-current@freebsd.org
SH Sent: Friday, October 18, 2013 3:45 PM
SH Subject: Re: ZFS secondarycache on SSD problem on r255173
SH
SH
SH
SH Just right now stats not to actual because of some another test.
SH
SH Test is simply all gpart information destroyed from ssd and
SH
SH They used as raw cache devices. Just
SH 2013-10-18.11:30:49 zpool add disk1 cache /dev/ada1 /dev/ada2 /dev/ada3
SH
SH So sizes at last l2_size and l2_asize in not actual.
SH
SH But heare it is:
SH
SH kstat.zfs.misc.arcstats.hits: 5178174063
SH kstat.zfs.misc.arcstats.misses: 57690806
SH kstat.zfs.misc.arcstats.demand_data_hits: 313995744
SH kstat.zfs.misc.arcstats.demand_data_misses: 37414740
SH kstat.zfs.misc.arcstats.demand_metadata_hits: 4719242892
SH kstat.zfs.misc.arcstats.demand_metadata_misses: 9266394
SH kstat.zfs.misc.arcstats.prefetch_data_hits: 1182495
SH kstat.zfs.misc.arcstats.prefetch_data_misses: 9951733
SH kstat.zfs.misc.arcstats.prefetch_metadata_hits: 143752935
SH kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1057939
SH kstat.zfs.misc.arcstats.mru_hits: 118609738
SH kstat.zfs.misc.arcstats.mru_ghost_hits: 1895486
SH kstat.zfs.misc.arcstats.mfu_hits: 4914673425
SH kstat.zfs.misc.arcstats.mfu_ghost_hits: 14537497
SH kstat.zfs.misc.arcstats.allocated: 103796455
SH kstat.zfs.misc.arcstats.deleted: 40168100
SH kstat.zfs.misc.arcstats.stolen: 20832742
SH kstat.zfs.misc.arcstats.recycle_miss: 15663428
SH kstat.zfs.misc.arcstats.mutex_miss: 1456781
SH kstat.zfs.misc.arcstats.evict_skip: 25960184
SH kstat.zfs.misc.arcstats.evict_l2_cached: 891379153920
SH kstat.zfs.misc.arcstats.evict_l2_eligible: 50578438144
SH kstat.zfs.misc.arcstats.evict_l2_ineligible: 956055729664
SH kstat.zfs.misc.arcstats.hash_elements: 8693451
SH kstat.zfs.misc.arcstats.hash_elements_max: 14369414
SH kstat.zfs.misc.arcstats.hash_collisions: 90967764
SH kstat.zfs.misc.arcstats.hash_chains: 1891463
SH kstat.zfs.misc.arcstats.hash_chain_max: 24
SH kstat.zfs.misc.arcstats.p: 73170954752
SH kstat.zfs.misc.arcstats.c: 85899345920
SH kstat.zfs.misc.arcstats.c_min: 42949672960
SH kstat.zfs.misc.arcstats.c_max: 85899345920
SH kstat.zfs.misc.arcstats.size: 85899263104
SH kstat.zfs.misc.arcstats.hdr_size: 1425948696
SH kstat.zfs.misc.arcstats.data_size: 77769994240
SH kstat.zfs.misc.arcstats.other_size: 6056233632
SH kstat.zfs.misc.arcstats.l2_hits: 21725934
SH kstat.zfs.misc.arcstats.l2_misses: 35876251
SH kstat.zfs.misc.arcstats.l2_feeds: 130197
SH kstat.zfs.misc.arcstats.l2_rw_clash: 110181
SH kstat.zfs.misc.arcstats.l2_read_bytes: 391282009600
SH kstat.zfs.misc.arcstats.l2_write_bytes: 1098703347712
SH kstat.zfs.misc.arcstats.l2_writes_sent: 130037
SH kstat.zfs.misc.arcstats.l2_writes_done: 130037
SH kstat.zfs.misc.arcstats.l2_writes_error: 0
SH kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 375921
SH kstat.zfs.misc.arcstats.l2_evict_lock_retry: 331
SH kstat.zfs.misc.arcstats.l2_evict_reading: 43
SH kstat.zfs.misc.arcstats.l2_free_on_write: 255730
SH kstat.zfs.misc.arcstats.l2_abort_lowmem: 0
SH kstat.zfs.misc.arcstats.l2_cksum_bad: 854359
Re: [rfc] removing the NDISulator
El día Friday, October 18, 2013 a las 02:19:42PM -0700, Adrian Chadd escribió: I'd really like to see bwi/bwn maintained and have support added for the later hardware. Hi Adrian, $ pciconf -vl ndis0@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4312 802.11b/g LP-PHY' class = network I'm using NDIS as well in r250588. Is bwi/bwn the point to start to look into for this chip? Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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] Patch to bsdinstall to support root-on-ZFS and GELI
Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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-10-19 13:21:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 13:21:21 - 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-10-19 13:21:21 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-10-19 13:21:21 - cleaning the object tree TB --- 2013-10-19 13:22:28 - /usr/local/bin/svn stat /src TB --- 2013-10-19 13:22:31 - At svn revision 256765 TB --- 2013-10-19 13:22:32 - building world TB --- 2013-10-19 13:22:32 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 13:22:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 13:22:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 13:22:32 - SRCCONF=/dev/null TB --- 2013-10-19 13:22:32 - TARGET=ia64 TB --- 2013-10-19 13:22:32 - TARGET_ARCH=ia64 TB --- 2013-10-19 13:22:32 - TZ=UTC TB --- 2013-10-19 13:22:32 - __MAKE_CONF=/dev/null TB --- 2013-10-19 13:22:32 - cd /src TB --- 2013-10-19 13:22:32 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 13:22:39 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 Oct 19 14:57:26 UTC 2013 TB --- 2013-10-19 14:57:26 - generating LINT kernel config TB --- 2013-10-19 14:57:26 - cd /src/sys/ia64/conf TB --- 2013-10-19 14:57:26 - /usr/bin/make -B LINT TB --- 2013-10-19 14:57:26 - cd /src/sys/ia64/conf TB --- 2013-10-19 14:57:26 - /usr/sbin/config -m LINT TB --- 2013-10-19 14:57:26 - building LINT kernel TB --- 2013-10-19 14:57:26 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 14:57:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 14:57:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 14:57:26 - SRCCONF=/dev/null TB --- 2013-10-19 14:57:26 - TARGET=ia64 TB --- 2013-10-19 14:57:26 - TARGET_ARCH=ia64 TB --- 2013-10-19 14:57:26 - TZ=UTC TB --- 2013-10-19 14:57:26 - __MAKE_CONF=/dev/null TB --- 2013-10-19 14:57:26 - cd /src TB --- 2013-10-19 14:57:26 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Oct 19 14:57:26 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/geom/geom_vfs.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/geom/geom_vol_ffs.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/geom/journal/g_journal.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
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. -- Allan Jude ___ 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] Patch to bsdinstall to support root-on-ZFS and GELI
On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. -- Allan Jude ___ 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] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? -- 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] Patch to bsdinstall to support root-on-ZFS and GELI
On 19/10/13 17:43, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? Hmmm. Can't believe I didn't do a PgDn. Then againit was pretty late last night when I tested it...tired brain. :) I'll recreate the mirror and see if I can provide a screen shot! /Johan ___ 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] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). -- Devin -- 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
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-19 11:55, Teske, Devin wrote: On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). the error output msgbox is huge, probably 100+ lines (the screen is what, 24 lines high, and with the ok button, top and bottom reserved space etc, can display maybe 18 lines at once) It contains all the shell output from everything we do, creating the gparts, setting up gnop, all of the redundant destroys etc. I don't think the TINY little % in the bottom right is really enough of an indicator to the user that they CAN scroll, let alone HOW to scroll (IIRC the arrow keys do not work, must use page down) -- Allan Jude ___ freebsd-current@freebsd.org mailing list
[head tinderbox] failure on mips64/mips
TB --- 2013-10-19 15:17:14 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 15:17:14 - 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-10-19 15:17:14 - starting HEAD tinderbox run for mips64/mips TB --- 2013-10-19 15:17:14 - cleaning the object tree TB --- 2013-10-19 15:18:47 - /usr/local/bin/svn stat /src TB --- 2013-10-19 15:18:50 - At svn revision 256765 TB --- 2013-10-19 15:18:51 - building world TB --- 2013-10-19 15:18:51 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 15:18:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 15:18:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 15:18:51 - SRCCONF=/dev/null TB --- 2013-10-19 15:18:51 - TARGET=mips TB --- 2013-10-19 15:18:51 - TARGET_ARCH=mips64 TB --- 2013-10-19 15:18:51 - TZ=UTC TB --- 2013-10-19 15:18:51 - __MAKE_CONF=/dev/null TB --- 2013-10-19 15:18:51 - cd /src TB --- 2013-10-19 15:18:51 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 15:18:58 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 Oct 19 16:20:57 UTC 2013 TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m ADM5120 TB --- 2013-10-19 16:20:57 - skipping ADM5120 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m ALCHEMY TB --- 2013-10-19 16:20:57 - skipping ALCHEMY kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP121 TB --- 2013-10-19 16:20:57 - skipping AP121 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP91 TB --- 2013-10-19 16:20:57 - skipping AP91 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP93 TB --- 2013-10-19 16:20:57 - skipping AP93 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP94 TB --- 2013-10-19 16:20:57 - skipping AP94 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP96 TB --- 2013-10-19 16:20:57 - skipping AP96 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-10-19 16:20:57 - skipping AR71XX_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR724X_BASE TB --- 2013-10-19 16:20:57 - skipping AR724X_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-10-19 16:20:57 - skipping AR91XX_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR933X_BASE TB --- 2013-10-19 16:20:57 - skipping AR933X_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR934X_BASE TB --- 2013-10-19 16:20:57 - skipping AR934X_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-10-19 16:20:57 - building BERI_DE4_MDROOT kernel TB --- 2013-10-19 16:20:57 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:20:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:20:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:20:57 - SRCCONF=/dev/null TB --- 2013-10-19 16:20:57 - TARGET=mips TB --- 2013-10-19 16:20:57 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:20:57 - TZ=UTC TB --- 2013-10-19 16:20:57 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:20:57 - cd /src TB --- 2013-10-19 16:20:57 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT Kernel build for BERI_DE4_MDROOT started on Sat Oct 19 16:20:57 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 BERI_DE4_MDROOT completed on Sat Oct 19 16:23:25 UTC 2013 TB --- 2013-10-19 16:23:25 - cd /src/sys/mips/conf TB --- 2013-10-19 16:23:25 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-10-19 16:23:25 - building BERI_DE4_SDROOT kernel TB --- 2013-10-19 16:23:25 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:23:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:23:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:23:25 - SRCCONF=/dev/null TB --- 2013-10-19 16:23:25 - TARGET=mips TB --- 2013-10-19 16:23:25 -
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 19/10/13 18:27, Allan Jude wrote: On 2013-10-19 11:55, Teske, Devin wrote: On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). the error output msgbox is huge, probably 100+ lines (the screen is what, 24 lines high, and with the ok button, top and bottom reserved space etc, can display maybe 18 lines at once) It contains all the shell output from everything we do, creating the gparts, setting up gnop, all of the redundant destroys etc. I don't think the TINY little % in the bottom right is really enough of an indicator to the user that they CAN scroll, let alone HOW to scroll (IIRC the arrow keys do not work, must use page down) I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 19, 2013, at 9:27 AM, Allan Jude wrote: On 2013-10-19 11:55, Teske, Devin wrote: On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ freebsd-current@freebsd.org mailing list https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/listinfo/freebsd-currentk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=AnourZYCpeybP9aMxTFH%2B4GBOf0xikQ2jpEi%2BPFWcKo%3D%0As=fec708d91fa0976a0e297ef3628851168f36e9cb34727dc7935e26ae190e90da To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ freebsd-current@freebsd.org mailing list https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/listinfo/freebsd-currentk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=AnourZYCpeybP9aMxTFH%2B4GBOf0xikQ2jpEi%2BPFWcKo%3D%0As=fec708d91fa0976a0e297ef3628851168f36e9cb34727dc7935e26ae190e90da To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). the error output msgbox is huge,
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-10-19 15:22:09 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 15:22:09 - 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-10-19 15:22:09 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-10-19 15:22:09 - cleaning the object tree TB --- 2013-10-19 15:23:19 - /usr/local/bin/svn stat /src TB --- 2013-10-19 15:23:22 - At svn revision 256765 TB --- 2013-10-19 15:23:23 - building world TB --- 2013-10-19 15:23:23 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 15:23:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 15:23:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 15:23:23 - SRCCONF=/dev/null TB --- 2013-10-19 15:23:23 - TARGET=powerpc TB --- 2013-10-19 15:23:23 - TARGET_ARCH=powerpc TB --- 2013-10-19 15:23:23 - TZ=UTC TB --- 2013-10-19 15:23:23 - __MAKE_CONF=/dev/null TB --- 2013-10-19 15:23:23 - cd /src TB --- 2013-10-19 15:23:23 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 15:23:30 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 Oct 19 18:07:00 UTC 2013 TB --- 2013-10-19 18:07:00 - generating LINT kernel config TB --- 2013-10-19 18:07:00 - cd /src/sys/powerpc/conf TB --- 2013-10-19 18:07:00 - /usr/bin/make -B LINT TB --- 2013-10-19 18:07:00 - cd /src/sys/powerpc/conf TB --- 2013-10-19 18:07:00 - /usr/sbin/config -m LINT TB --- 2013-10-19 18:07:00 - building LINT kernel TB --- 2013-10-19 18:07:00 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 18:07:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 18:07:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 18:07:00 - SRCCONF=/dev/null TB --- 2013-10-19 18:07:00 - TARGET=powerpc TB --- 2013-10-19 18:07:00 - TARGET_ARCH=powerpc TB --- 2013-10-19 18:07:00 - TZ=UTC TB --- 2013-10-19 18:07:00 - __MAKE_CONF=/dev/null TB --- 2013-10-19 18:07:00 - cd /src TB --- 2013-10-19 18:07:00 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Oct 19 18:07:00 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/geom/geom_vfs.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/geom/geom_vol_ffs.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/geom/journal/g_journal.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
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-10-19 16:57:39 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 16:57:39 - 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-10-19 16:57:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-10-19 16:57:39 - cleaning the object tree TB --- 2013-10-19 16:58:36 - /usr/local/bin/svn stat /src TB --- 2013-10-19 16:58:39 - At svn revision 256765 TB --- 2013-10-19 16:58:40 - building world TB --- 2013-10-19 16:58:40 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:58:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:58:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:58:40 - SRCCONF=/dev/null TB --- 2013-10-19 16:58:40 - TARGET=sparc64 TB --- 2013-10-19 16:58:40 - TARGET_ARCH=sparc64 TB --- 2013-10-19 16:58:40 - TZ=UTC TB --- 2013-10-19 16:58:40 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:58:40 - cd /src TB --- 2013-10-19 16:58:40 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 16:58:47 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 Oct 19 18:07:00 UTC 2013 TB --- 2013-10-19 18:07:00 - generating LINT kernel config TB --- 2013-10-19 18:07:00 - cd /src/sys/sparc64/conf TB --- 2013-10-19 18:07:00 - /usr/bin/make -B LINT TB --- 2013-10-19 18:07:00 - cd /src/sys/sparc64/conf TB --- 2013-10-19 18:07:00 - /usr/sbin/config -m LINT TB --- 2013-10-19 18:07:00 - building LINT kernel TB --- 2013-10-19 18:07:00 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 18:07:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 18:07:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 18:07:00 - SRCCONF=/dev/null TB --- 2013-10-19 18:07:00 - TARGET=sparc64 TB --- 2013-10-19 18:07:00 - TARGET_ARCH=sparc64 TB --- 2013-10-19 18:07:00 - TZ=UTC TB --- 2013-10-19 18:07:00 - __MAKE_CONF=/dev/null TB --- 2013-10-19 18:07:00 - cd /src TB --- 2013-10-19 18:07:00 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Oct 19 18:07:00 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/geom/geom_vfs.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/geom/geom_vol_ffs.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/geom/journal/g_journal.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
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: On 19/10/13 18:27, Allan Jude wrote: On 2013-10-19 11:55, Teske, Devin wrote: On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). the error output msgbox is huge, probably 100+ lines (the screen is what, 24 lines high, and with the ok button, top and bottom reserved space etc, can display maybe 18 lines at once) It contains all the shell output from everything we do, creating the gparts, setting up gnop, all of the redundant destroys etc. I don't think the TINY little % in the bottom right is really enough of an indicator to the user that they CAN scroll, let alone HOW to scroll (IIRC the arrow keys do
[head tinderbox] failure on powerpc64/powerpc
TB --- 2013-10-19 16:36:54 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 16:36:54 - 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-10-19 16:36:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-10-19 16:36:54 - cleaning the object tree TB --- 2013-10-19 16:38:32 - /usr/local/bin/svn stat /src TB --- 2013-10-19 16:38:37 - At svn revision 256765 TB --- 2013-10-19 16:38:38 - building world TB --- 2013-10-19 16:38:38 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:38:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:38:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:38:38 - SRCCONF=/dev/null TB --- 2013-10-19 16:38:38 - TARGET=powerpc TB --- 2013-10-19 16:38:38 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 16:38:38 - TZ=UTC TB --- 2013-10-19 16:38:38 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:38:38 - cd /src TB --- 2013-10-19 16:38:38 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Oct 19 16:38:45 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 stage 5.1: building 32 bit shim libraries World build completed on Sat Oct 19 19:45:29 UTC 2013 TB --- 2013-10-19 19:45:29 - generating LINT kernel config TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/bin/make -B LINT TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/sbin/config -m LINT TB --- 2013-10-19 19:45:29 - skipping LINT kernel TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/sbin/config -m GENERIC TB --- 2013-10-19 19:45:29 - skipping GENERIC kernel TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/sbin/config -m GENERIC64 TB --- 2013-10-19 19:45:29 - building GENERIC64 kernel TB --- 2013-10-19 19:45:29 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 19:45:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 19:45:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 19:45:29 - SRCCONF=/dev/null TB --- 2013-10-19 19:45:29 - TARGET=powerpc TB --- 2013-10-19 19:45:29 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 19:45:29 - TZ=UTC TB --- 2013-10-19 19:45:29 - __MAKE_CONF=/dev/null TB --- 2013-10-19 19:45:29 - cd /src TB --- 2013-10-19 19:45:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 Kernel build for GENERIC64 started on Sat Oct 19 19:45:29 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 -g -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_subr.c ctfconvert -L VERSION -g geom_subr.o cc -c -O -pipe -std=c99 -g -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c ctfconvert -L VERSION -g geom_vfs.o cc -c -O -pipe -std=c99 -g -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 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
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: http://212.181.212.146/bsdinstall I've added a patch to fix debugging in the zfsboot script... http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ 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. -- 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] Patch to bsdinstall to support root-on-ZFS and GELI
On 19/10/13 20:52, Teske, Devin wrote: On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: On 19/10/13 18:27, Allan Jude wrote: On 2013-10-19 11:55, Teske, Devin wrote: On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). the error output msgbox is huge, probably 100+ lines (the screen is what, 24 lines high, and with the ok button, top and bottom reserved space etc, can display maybe 18 lines at once) It contains all the shell output from everything we do, creating the gparts, setting up gnop, all of the redundant destroys etc. I don't think the TINY little % in the bottom right is really enough of an indicator to the user that they CAN scroll, let alone HOW to scroll (IIRC the arrow keys do not work, must use page down) I recreated the graid mirror on ada2
