[head tinderbox] failure on powerpc/powerpc
TB --- 2013-12-27 05:41:13 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-27 05:41:13 - 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-12-27 05:41:13 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-12-27 05:41:13 - cleaning the object tree TB --- 2013-12-27 05:41:13 - /usr/local/bin/svn stat /src TB --- 2013-12-27 05:41:24 - At svn revision 259928 TB --- 2013-12-27 05:41:25 - building world TB --- 2013-12-27 05:41:25 - CROSS_BUILD_TESTING=YES TB --- 2013-12-27 05:41:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-27 05:41:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-27 05:41:25 - SRCCONF=/dev/null TB --- 2013-12-27 05:41:25 - TARGET=powerpc TB --- 2013-12-27 05:41:25 - TARGET_ARCH=powerpc TB --- 2013-12-27 05:41:25 - TZ=UTC TB --- 2013-12-27 05:41:25 - __MAKE_CONF=/dev/null TB --- 2013-12-27 05:41:25 - cd /src TB --- 2013-12-27 05:41:25 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Dec 27 05:41:34 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 Fri Dec 27 08:16:39 UTC 2013 TB --- 2013-12-27 08:16:39 - generating LINT kernel config TB --- 2013-12-27 08:16:39 - cd /src/sys/powerpc/conf TB --- 2013-12-27 08:16:39 - /usr/bin/make -B LINT TB --- 2013-12-27 08:16:39 - cd /src/sys/powerpc/conf TB --- 2013-12-27 08:16:39 - /usr/sbin/config -m LINT TB --- 2013-12-27 08:16:39 - building LINT kernel TB --- 2013-12-27 08:16:39 - CROSS_BUILD_TESTING=YES TB --- 2013-12-27 08:16:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-27 08:16:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-27 08:16:39 - SRCCONF=/dev/null TB --- 2013-12-27 08:16:39 - TARGET=powerpc TB --- 2013-12-27 08:16:39 - TARGET_ARCH=powerpc TB --- 2013-12-27 08:16:39 - TZ=UTC TB --- 2013-12-27 08:16:39 - __MAKE_CONF=/dev/null TB --- 2013-12-27 08:16:39 - cd /src TB --- 2013-12-27 08:16:39 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Dec 27 08:16:40 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/nop/g_nop.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/part/g_part.c awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_if.m -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 g_part_if.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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2013-12-27 05:57:01 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-27 05:57:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-27 05:57:01 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-12-27 05:57:01 - cleaning the object tree TB --- 2013-12-27 05:57:01 - /usr/local/bin/svn stat /src TB --- 2013-12-27 05:57:05 - At svn revision 259928 TB --- 2013-12-27 05:57:06 - building world TB --- 2013-12-27 05:57:06 - CROSS_BUILD_TESTING=YES TB --- 2013-12-27 05:57:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-27 05:57:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-27 05:57:06 - SRCCONF=/dev/null TB --- 2013-12-27 05:57:06 - TARGET=powerpc TB --- 2013-12-27 05:57:06 - TARGET_ARCH=powerpc64 TB --- 2013-12-27 05:57:06 - TZ=UTC TB --- 2013-12-27 05:57:06 - __MAKE_CONF=/dev/null TB --- 2013-12-27 05:57:06 - cd /src TB --- 2013-12-27 05:57:06 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Dec 27 05:57:13 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 Fri Dec 27 09:00:57 UTC 2013 TB --- 2013-12-27 09:00:57 - generating LINT kernel config TB --- 2013-12-27 09:00:57 - cd /src/sys/powerpc/conf TB --- 2013-12-27 09:00:57 - /usr/bin/make -B LINT TB --- 2013-12-27 09:00:57 - cd /src/sys/powerpc/conf TB --- 2013-12-27 09:00:57 - /usr/sbin/config -m LINT TB --- 2013-12-27 09:00:57 - skipping LINT kernel TB --- 2013-12-27 09:00:57 - cd /src/sys/powerpc/conf TB --- 2013-12-27 09:00:57 - /usr/sbin/config -m GENERIC TB --- 2013-12-27 09:00:57 - skipping GENERIC kernel TB --- 2013-12-27 09:00:57 - cd /src/sys/powerpc/conf TB --- 2013-12-27 09:00:57 - /usr/sbin/config -m GENERIC64 TB --- 2013-12-27 09:00:57 - building GENERIC64 kernel TB --- 2013-12-27 09:00:57 - CROSS_BUILD_TESTING=YES TB --- 2013-12-27 09:00:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-27 09:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-27 09:00:57 - SRCCONF=/dev/null TB --- 2013-12-27 09:00:57 - TARGET=powerpc TB --- 2013-12-27 09:00:57 - TARGET_ARCH=powerpc64 TB --- 2013-12-27 09:00:57 - TZ=UTC TB --- 2013-12-27 09:00:57 - __MAKE_CONF=/dev/null TB --- 2013-12-27 09:00:57 - cd /src TB --- 2013-12-27 09:00:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 Kernel build for GENERIC64 started on Fri Dec 27 09:00:58 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_if.m -c ; 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 g_part_if.c ctfconvert -L VERSION -g g_part_if.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/part/g_part_apm.c ctfconvert -L VERSION -g g_part_apm.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
Re: FreeBSD 10.0-RC3 Now Available
On 12/27/13, Mathieu Arnold m...@freebsd.org wrote: +--On 27 décembre 2013 00:42:36 +0100 Zenny garbytr...@gmail.com wrote: | Much awaited release, thanks!. However, does the freebsd-update from | the earlier version bork in case of ZFS on Root? Or is there a safe | way to upgrade without borking. I had a very bad experience when I | upgraded from FreeBSD-10B3 to RC1. Thanks! I upgraded from 9.2 to 10.0-RC1, 10.0-RC2 and 10.0-RC3 with freebsd-update using zfs only boxes, never had any problem. The only thing is, if you run zpool upgrade, do remember to do what it tells you about updating the bootcode. In my case, I didn't receive any instructions to update the bootcode and the bug was acknowledged by the developer. However, can you tell me exactly what did you do exactly to update the bootcode? Appreciate it! -- Mathieu Arnold ___ 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: FreeBSD 10.0-RC3 Now Available
+--On 27 décembre 2013 12:26:49 +0100 Zenny garbytr...@gmail.com wrote: | On 12/27/13, Mathieu Arnold m...@freebsd.org wrote: | +--On 27 décembre 2013 00:42:36 +0100 Zenny garbytr...@gmail.com | wrote: | | Much awaited release, thanks!. However, does the freebsd-update from | | the earlier version bork in case of ZFS on Root? Or is there a safe | | way to upgrade without borking. I had a very bad experience when I | | upgraded from FreeBSD-10B3 to RC1. Thanks! | | I upgraded from 9.2 to 10.0-RC1, 10.0-RC2 and 10.0-RC3 with | freebsd-update using zfs only boxes, never had any problem. The only | thing is, if you run zpool upgrade, do remember to do what it tells you | about updating the bootcode. | | | In my case, I didn't receive any instructions to update the bootcode | and the bug was acknowledged by the developer. | | However, can you tell me exactly what did you do exactly to update the | bootcode? Appreciate it! Well, when you run : # zpool upgrade yourpool it will not print a lot of things, but it will end with : If you boot from pool 'yourpool', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 All you have to do is adapt it to run your particular setup, replacing da0 with the correct disk (and running it for each disk where your pool is, in my case, it was mfid0 and mfid1.) -- Mathieu Arnold ___ 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: FreeBSD 10.0-RC3 Now Available
On Thu, Dec 26, 2013 at 11:25:21AM -0500, Glen Barber wrote: [...] Pre-installed virtual machine images for 10.0-RC3 are also available for amd64 and i386 architectures. The images are located under the 'snapshots' directory on FTP, here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-RC3/ [...] - 10.0-RC3 i386: SHA256 (FreeBSD-10.0-RC3-i386.qcow2.xz) = 057610738176e19eab80b4a127e34ba4a2d1f1e8760c093c016a7f20c7d208d3 SHA256 (FreeBSD-10.0-RC3-i386.vhd.xz) = 4c798503632ae625ddf616a0006ff6039376e3dca0c2ac2375e5980beed99145 SHA256 (FreeBSD-10.0-RC3-i386.vmdk.xz) = 0edc8aaa7b7e968f560fa7dbf5dcad8a5e588f62dd793f0ebbecbc349db85084 MD5 (FreeBSD-10.0-RC3-i386.qcow2.xz) = 5857e8613c3b0685826a2b006d25564a MD5 (FreeBSD-10.0-RC3-i386.vhd.xz) = da0acf0bf5b3412fa4922e625a1c651e MD5 (FreeBSD-10.0-RC3-i386.vmdk.xz) = f4f0d948d4fd3afc3e41bbf511fd5240 An issue with the 10.0-RC3 i386 virtual machine images was brought to our attention. It is still unclear what exactly went wrong, but the images with the checksums above appear to be incomplete. The virtual machine images for i386 have been recreated, and are propagating to FTP now. It may still be a while yet before they are picked up by all mirrors. Checksums for the corrected images are: - 10.0-RC3 i386: SHA256 (FreeBSD-10.0-RC3-i386-20131223-r259778.qcow2.xz) = 76092c843bd91037cf94d48007cd5a054b0ee2744f5475ee50c558ba880520fa SHA256 (FreeBSD-10.0-RC3-i386-20131223-r259778.vhd.xz) = da8632d78cc89e1812c20f18a6aaac727e78ef44f1c3aedd4ffbe9318e50030e SHA256 (FreeBSD-10.0-RC3-i386-20131223-r259778.vmdk.xz) = 137ae9e44e419fc78823ac8f3cc7c9e32bfe5d7a80b7997a96d857dc1f3bd4fb MD5 (FreeBSD-10.0-RC3-i386-20131223-r259778.qcow2.xz) = 936736ff87b11d99408b5b7135c8a025 MD5 (FreeBSD-10.0-RC3-i386-20131223-r259778.vhd.xz) = 770895367a4b22631f54c25d81e11608 MD5 (FreeBSD-10.0-RC3-i386-20131223-r259778.vmdk.xz) = ba62a266ab560711bed0ff53a3177b94 Sorry for the inconvenience to those who have downloaded the incomplete images. Glen pgpQ52lXbeYc2.pgp Description: PGP signature
Re: FreeBSD 10.0-RC3 Now Available
The third RC build of the 10.0-RELEASE release cycle is now available Nice :-) Has someone checked src/ + ports/ has been re-made a seamless functional combination for named/bind ? There were various loose ends earlier (paths, defaults etc), after removal from src/. I'm asking as I think I will not be able to catch up in time to look check before release, ( I'm at RC2 downloading RC3 images rebuilding my svn tree that got corrupt, before I'll svn export make kernel world cd /usr/ports/dns/bind9* ; make install ) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ 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: FreeBSD 10.0-RC3 Now Available
All the examples I've seen for updating bootcode assume GPT. If one has MBR (as I do) and assuming the following basic scheme: gpart show ada0 = 63 976773105 ada0 MBR (466G) 63 976773105 1 freebsd [active] (466G) gpart show ada0s1 =0 976773105 ada0s1 BSD (466G) 0 943218736 1 freebsd-zfs (450G) 943218736 33554369 2 freebsd-swap (16G) would the equivalent bootcode statement be: gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and ada0s1 is the slice on which FreeBSD is installed? Thanks. On Fri, Dec 27, 2013 at 9:33 AM, Mathieu Arnold m...@freebsd.org wrote: +--On 27 décembre 2013 12:26:49 +0100 Zenny garbytr...@gmail.com wrote: | On 12/27/13, Mathieu Arnold m...@freebsd.org wrote: | +--On 27 décembre 2013 00:42:36 +0100 Zenny garbytr...@gmail.com | wrote: | | Much awaited release, thanks!. However, does the freebsd-update from | | the earlier version bork in case of ZFS on Root? Or is there a safe | | way to upgrade without borking. I had a very bad experience when I | | upgraded from FreeBSD-10B3 to RC1. Thanks! | | I upgraded from 9.2 to 10.0-RC1, 10.0-RC2 and 10.0-RC3 with | freebsd-update using zfs only boxes, never had any problem. The only | thing is, if you run zpool upgrade, do remember to do what it tells you | about updating the bootcode. | | | In my case, I didn't receive any instructions to update the bootcode | and the bug was acknowledged by the developer. | | However, can you tell me exactly what did you do exactly to update the | bootcode? Appreciate it! Well, when you run : # zpool upgrade yourpool it will not print a lot of things, but it will end with : If you boot from pool 'yourpool', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 All you have to do is adapt it to run your particular setup, replacing da0 with the correct disk (and running it for each disk where your pool is, in my case, it was mfid0 and mfid1.) -- Mathieu Arnold ___ 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 ___ 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: FreeBSD 10.0-RC3 Now Available
+--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | = 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 | | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 might be ada0s1 and not ada0, or something (please, don't do that unless you're sure you're doing it right.) -- Mathieu Arnold ___ 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: md2 on current and 10.
On Fri, 2013-12-20 at 16:46:42 -0500, Mikhail T. wrote: Thinking more about the MD2, I'd say, FreeBSD should not have removed the algorithm. Although no longer deemed sufficiently secure, it is still in use and people using it on FreeBSD-8.x and 9.x today may wish to continue doing so after upgrading to 10.x In the old Mechanism vs. Policy debate http://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy we erred on the side of policy and it does not seem right... Whether or not to use MD2 is (or should be) left up to the users of FreeBSD. Even if OpenSSL no longer provides it, libmd should continue to. In other words, /if you like your digest algorithm, you can keep it/. Yours, Seconded. What should people use if some of their old data is using MD2 for verification? How can they now easily check that their data (from tape or whatever) still matches the fingerprint? Cheers, Uli ___ 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: FreeBSD 10.0-RC3 Now Available
On Fri, 27 Dec 2013, Mathieu Arnold wrote: +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | = 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 No, the PMBR is for GPT partitioning only. | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode correctly. you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 That will overwrite the MBR partition table. # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 That seems dangerous. I have not tried with zfsboot, but this should be close: # gpart bootcode -b /boot/zfsboot ada0 # gpart bootcode -b /boot/zfsboot ada0s1 Untested! The first one may need to use /boot/mbr. A better way to do this, provided the system does not have a broken BIOS, would be to backup, repartition with GPT, and restore, avoiding the complication of multiple partitioning schemes. ___ 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: FreeBSD 10.0-RC3 Now Available
On Fri, Dec 27, 2013 at 03:33:23PM +0100 I heard the voice of
Mathieu Arnold, and lo! it spake thus:
All you have to do is adapt it to run your particular setup,
replacing da0 with the correct disk (and running it for each disk
where your pool is, in my case, it was mfid0 and mfid1.)
I've taken to just dumping a rewrite-bootcode.sh script in /boot/ on
systems. That way I don't have to remember or re-figure the
invocation, or worry about typos, or whatnot. Makes it easy to just
kick the script after every installworld whether I really need it or
not, without having to think about it.
e.g.,
% cat /boot/rewrite-bootcode.sh
#!/bin/sh -x
for i in /dev/ada0 /dev/ada1; do
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${i}
done
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
___
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: FreeBSD 10.0-RC3 Now Available
+--On 27 décembre 2013 10:17:14 -0600 Matthew D. Fuller fulle...@over-yonder.net wrote: | On Fri, Dec 27, 2013 at 03:33:23PM +0100 I heard the voice of | Mathieu Arnold, and lo! it spake thus: | | All you have to do is adapt it to run your particular setup, | replacing da0 with the correct disk (and running it for each disk | where your pool is, in my case, it was mfid0 and mfid1.) | | I've taken to just dumping a rewrite-bootcode.sh script in /boot/ on | systems. That way I don't have to remember or re-figure the | invocation, or worry about typos, or whatnot. Makes it easy to just | kick the script after every installworld whether I really need it or | not, without having to think about it. You *don't* need it after installworld, or freebsd-update install. You *only* need it if you *explicitly* run zpool upgrade yourzpool. And if you do that, zpool upgrade tells you to run it. If you forget to run zpool upgrade, or you don't run it, you don't need to upgrade the bootcode. -- Mathieu Arnold ___ 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: FreeBSD 10.0-RC3 Now Available
After I posted, it occurred to me to check out the ../bsdinstall/scripts/zfsboot script to see how the boot code was laid down when the MBR was created. It shows only: dd if=/boot/zfsboot of=/dev/ada0s1 count =1 But, adding to my confusion, the FreeBSD wiki for ZFS on root (MBR-style) shows something very close to what Mathieu suggested. Unfortunately, I'm using an iMac with FreeBSD as the only OS. MBR is the only way I can get it to boot after an install. Looks like I've got some testing (and possible system restores) ahead of me. Thanks. On Fri, Dec 27, 2013 at 11:08 AM, Warren Block wbl...@wonkity.com wrote: On Fri, 27 Dec 2013, Mathieu Arnold wrote: +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | = 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 No, the PMBR is for GPT partitioning only. | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode correctly. you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 That will overwrite the MBR partition table. # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 That seems dangerous. I have not tried with zfsboot, but this should be close: # gpart bootcode -b /boot/zfsboot ada0 # gpart bootcode -b /boot/zfsboot ada0s1 Untested! The first one may need to use /boot/mbr. A better way to do this, provided the system does not have a broken BIOS, would be to backup, repartition with GPT, and restore, avoiding the complication of multiple partitioning schemes. ___ 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: FreeBSD 10.0-RC3 Now Available
On Fri, Dec 27, 2013 at 05:21:12PM +0100 I heard the voice of Mathieu Arnold, and lo! it spake thus: You *don't* need it after installworld, or freebsd-update install. You *only* need it if you *explicitly* run zpool upgrade yourzpool. Well, that was my point; by removing the need to have to think about how to do it, I can just do it any time I rebuild bootcode, whether I need it or not. Makes life simpler. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: FreeBSD 10.0-RC3 Now Available
On Friday, December 27, 2013 11:08:08 am Warren Block wrote: On Fri, 27 Dec 2013, Mathieu Arnold wrote: +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | = 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 No, the PMBR is for GPT partitioning only. | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode correctly. you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 That will overwrite the MBR partition table. # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 That seems dangerous. I have not tried with zfsboot, but this should be close: # gpart bootcode -b /boot/zfsboot ada0 # gpart bootcode -b /boot/zfsboot ada0s1 No, the ZFS MBR bootstrap doesn't use the standard boot block areas. The only standard boot block area for ada0 is the MBR itself, but ZFS uses a larger bootloader that installs one part into the MBR and another part a few sectors later in the disk. gpart has no knowledge of that AFAIK. -- John Baldwin ___ 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: FreeBSD 10.0-RC3 Now Available
On Fri, Dec 27, 2013 at 10:08 AM, Warren Block wbl...@wonkity.com wrote: On Fri, 27 Dec 2013, Mathieu Arnold wrote: +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | = 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 No, the PMBR is for GPT partitioning only. | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode correctly. you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 That will overwrite the MBR partition table. # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 That seems dangerous. I have not tried with zfsboot, but this should be close: # gpart bootcode -b /boot/zfsboot ada0 # gpart bootcode -b /boot/zfsboot ada0s1 Untested! The first one may need to use /boot/mbr. A better way to do this, provided the system does not have a broken BIOS, would be to backup, repartition with GPT, and restore, avoiding the complication of multiple partitioning schemes. The correct way to install/update ZFS Boot code on an MBR disk is: Install boot Manager (required on first install) # gpart bootcode -b /boot/boot0 ad0 Note: /boot/mbr could also be used if you are not multibooting Install ZFS boot1 stage # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0s1 count=1 or # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 Install ZFS boot2 stage # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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: FreeBSD 10.0-RC3 Now Available
On Fri, Dec 27, 2013 at 12:15 PM, Scot Hetzel swhet...@gmail.com wrote: The correct way to install/update ZFS Boot code on an MBR disk is: Install boot Manager (required on first install) # gpart bootcode -b /boot/boot0 ad0 Note: /boot/mbr could also be used if you are not multibooting Install ZFS boot1 stage # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0s1 count=1 or # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 Install ZFS boot2 stage # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 This ties everything together nicely for me, especially the part about the first bootcode install, which had me really confused. Thanks. ___ 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
NFS - arm/AVILA problem
Hello I have problem with NFS on current. Timecounters tick every 10.000 msec ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ST640211CF 3.07 CFA-0 device ada0: Serial Number 3ME3GRCZ ada0: 16.700MB/s transfers (PIO4, PIO 8192bytes) ada0: 3906MB (7999488 512 byte sectors: 16H 63S/T 7936C) ada0: Previously was known as ad0 bootpc_init: wired to interface 'npe1' Sending DHCP Discover packet from interface npe1 (00:d0:12:13:59:23) Received DHCP Offer packet on npe1 from 10.42.1.1 (accepted) npe1: link state changed to DOWN Sending DHCP Request packet from interface npe1 (00:d0:12:13:59:23) Received DHCP Ack packet on npe1 from 10.42.1.1 (accepted) (got root path) npe1 at 10.42.1.15 server 10.42.1.1 boot file kernel-avila.nfs subnet mask 255.255.255.0 rootfs 10.42.1.1:/data/freebsd/gateworks rootopts nol Adjusted interface npe1 krpc_call: sosend: 65 krpc_call: sosend: 65 panic: nfs_boot: mount root, error=65 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Full BT dump and boot proces is here : http://pastebin.com/hM8KZNaY Can someone help solve the problem. Beri ___ 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: panic on sparc64 running 10-beta4
On Sun, Dec 08, 2013 at 02:50:23PM +0100, Marius Strobl wrote: On Wed, Dec 04, 2013 at 11:01:30AM -0500, Kurt Lidl wrote: I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 install image today. Installation went fine. I rebooted the machine, and then went to get a fresh ports tree, and the machine panic'd: root@host:/usr/ports # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps 00m22s Extracting snapshot... done. Verifying snapshot integrity... panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 6m59s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... And then it panic'd again when attempting to run 'savecore'! (I typed a ctrl-t after it printed out the line about writing the core file, that's where the load: 0.72 ... line came from...) Hrm, I don't seem to be able to reproduce this with an installation built from sources and also can't remember a commit between BETA3 and BETA4 which should be able to cause this. I currently can't test the 10-BETA4 install image, though. Was the machine in question running FreeBSD before, i. e. is it known good hardware? Did savecore eventually succeed on writing out a dump? FYI, I tried again with a machine installed from the 10.0-RC3 binary image and couldn't reproduce that problem either. Marius ___ 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: Committing PEFS to CURRENT
On Tue, Oct 8, 2013 at 12:12 AM, Gleb Kurtsou gleb.kurt...@gmail.comwrote: On (07/10/2013 21:59), Outback Dingo wrote: On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney j...@funkthat.com wrote: But will the work get done to clean it up after the freeze is over? What happens if it doesn't, will it get removed before 10.1 or will we have to live w/ the code? I still hope not to get hit by bus any time soon.. on a side note, i applied the patch to stable/9 out of curiosity and the kernel failed to build the module however i could install fine from ports. Correct, there is no support for old kernels in the patch. Port will be maintained and will provide support for older versions in case PEFS finds its way to 10.0. Hi, Are there any news about PEFS commit ? Regards, ___ 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: Committing PEFS to CURRENT
Alexandre Biancalana wrote this message on Fri, Dec 27, 2013 at 17:20 -0200: On Tue, Oct 8, 2013 at 12:12 AM, Gleb Kurtsou gleb.kurt...@gmail.comwrote: On (07/10/2013 21:59), Outback Dingo wrote: On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney j...@funkthat.com wrote: But will the work get done to clean it up after the freeze is over? What happens if it doesn't, will it get removed before 10.1 or will we have to live w/ the code? I still hope not to get hit by bus any time soon.. on a side note, i applied the patch to stable/9 out of curiosity and the kernel failed to build the module however i could install fine from ports. Correct, there is no support for old kernels in the patch. Port will be maintained and will provide support for older versions in case PEFS finds its way to 10.0. Are there any news about PEFS commit ? It's definately not going into 10.0, but it could make it in a future release, but... I haven't heard back about plans for moving forward on the project. I'm definately interested in getting this in the tree, but have other work that is higher priority right now. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: NFS - arm/AVILA problem
Berislav Purgar wrote: Hello I have problem with NFS on current. Timecounters tick every 10.000 msec ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ST640211CF 3.07 CFA-0 device ada0: Serial Number 3ME3GRCZ ada0: 16.700MB/s transfers (PIO4, PIO 8192bytes) ada0: 3906MB (7999488 512 byte sectors: 16H 63S/T 7936C) ada0: Previously was known as ad0 bootpc_init: wired to interface 'npe1' Sending DHCP Discover packet from interface npe1 (00:d0:12:13:59:23) Received DHCP Offer packet on npe1 from 10.42.1.1 (accepted) npe1: link state changed to DOWN Sending DHCP Request packet from interface npe1 (00:d0:12:13:59:23) Received DHCP Ack packet on npe1 from 10.42.1.1 (accepted) (got root path) npe1 at 10.42.1.15 server 10.42.1.1 boot file kernel-avila.nfs subnet mask 255.255.255.0 rootfs 10.42.1.1:/data/freebsd/gateworks rootopts nol Adjusted interface npe1 krpc_call: sosend: 65 krpc_call: sosend: 65 panic: nfs_boot: mount root, error=65 Well, 65 is EHOSTUNREACH, but since they appear to be on the same subnet, I don't know why the sosend() into the socket layer would reply that. I'd say it is related to network configuration (or how DHCP is setting up the net interface) and is not really an NFS problem. (ie. The sosend() of an RPC request is failing. NFS can't do anything if packets can't be sent to the server.) You might want to re-post with a subject line mentioning EHOSTUNREACH errors from sosend() after DHCP sets up the interface. (And you might want to post to an ARM related list, because I suspect it might be ARM specific?) rick KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Full BT dump and boot proces is here : http://pastebin.com/hM8KZNaY Can someone help solve the problem. Beri ___ 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 ___ 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: panic on sparc64 running 10-beta4
On 12/27/13 1:42 PM, Marius Strobl wrote: On Sun, Dec 08, 2013 at 02:50:23PM +0100, Marius Strobl wrote: On Wed, Dec 04, 2013 at 11:01:30AM -0500, Kurt Lidl wrote: I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 install image today. Installation went fine. I rebooted the machine, and then went to get a fresh ports tree, and the machine panic'd: root@host:/usr/ports # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps 00m22s Extracting snapshot... done. Verifying snapshot integrity... panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 6m59s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... And then it panic'd again when attempting to run 'savecore'! (I typed a ctrl-t after it printed out the line about writing the core file, that's where the load: 0.72 ... line came from...) Hrm, I don't seem to be able to reproduce this with an installation built from sources and also can't remember a commit between BETA3 and BETA4 which should be able to cause this. I currently can't test the 10-BETA4 install image, though. Was the machine in question running FreeBSD before, i. e. is it known good hardware? Did savecore eventually succeed on writing out a dump? Yes, this machine was successfully running 9/stable before this. Yes, I did ultimately get a successful savecore to run. The trick seems to be not to use ctrl-t to check the status of the machine. I loaded the RC1 build too, and restrained myself to not check via ctrl-t during the installation and unpacking of the OS, and again when doing a portsnap fetch portsnap unpack. I think the problem hinges on ctrl-t corrupting something that causes the panic soon thereafter. FYI, I tried again with a machine installed from the 10.0-RC3 binary image and couldn't reproduce that problem either. I just tried it again with a freshly fetched and burned RC3 image, and was able to get it to panic while verifying the snapshot. My comments are in [square brackets]. root@dna:~ # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Thu Dec 26 19:11:40 EST 2013: [ I did several ctrl-t operations during the fetch, no problem ] Extracting snapshot... [ctrl-t] load: 0.55 cmd: bsdtar 1355 [runnable] 6.33r 1.39u 3.78s 37% 5384k In: 11851934 bytes, compression 23%; Out: 5320 files, 15471104 bytes Current: snap/3d543fc157d97d1617eeb20832bf2cb37d04aeb2bf068bd0a07533e5b67c02fe.gz (1152 bytes) [ctrl-t] load: 0.83 cmd: bsdtar 1355 [runnable] 11.43r 2.36u 6.55s 51% 5384k In: 19288110 bytes, compression 24%; Out: 9299 files, 25624576 bytes Current: snap/1856dcdc8799dd2b5a19d2d4720452bc77b4084088dd9ac5bd190da5ac211c4b.gz (101014 bytes) done. Verifying snapshot integrity... [ a bunch of rapid ctrl-t keystrokes ] load: 2.23 cmd: sha256 1370 [runnable] 0.49r 0.32u 0.00s 3% 2064k load: 2.21 cmd: sh 1539 [runnable] 0.04r 0.00u 0.00s 2% 0k load: 1.93 cmd: sha256 5705 [runnable] 0.02r 0.00u 0.00s 15% 1880k load: 1.93 cmd: sh 5715 [runnable] 0.03r 0.00u 0.00s 15% 3136k load: 1.93 cmd: gunzip 5728 [runnable] 0.01r 0.00u 0.00s 16% 1200k load: 1.93 cmd: gunzip 5737 [runnable] 0.02r 0.00u 0.01s 16% 2144k load: 1.93 cmd: sh 5749 [runnable] 0.00r 0.00u 0.00s 16% 3136k load: 1.93 cmd: sh 1391 [runnable] 68.71r 0.58u 5.18s 15% 3136k panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc0883954 at trap+0x554 Uptime: 1h1m23s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x4000: 1073741824 bytes ... ok chunk at 0x8000: 1073741824 bytes ... ok chunk at 0xc000: 1073741824 bytes ... ok Dump complete Here's the backtrace from the recovered crashdump, 'core.txt.0': Unread portion of the kernel message buffer: panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc0883954 at trap+0x554 Uptime: 1h1m23s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from
Re: iwn trouble
Hi, I just fixed the Intel 6150 support. I'm emailing this from said Intel 6150. Please update to the very latest -HEAD and try! Thanks! -a On 22 December 2013 06:25, Hannes Mehnert han...@mehnert.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Hi, I'm running current and iwn fails to load. branch user/ed/newcons (from github) with latest commit: commit d16cc4039855b100f5b3e966a43dabe2028f2b57 Author: emaste ema...@freebsd.org Date: Fri Dec 6 13:58:23 2013 + Make Newcons options clear in GENERIC on the project branch My intel card is the following (pciconf -lv): iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00898086 rev=0x5e hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N + WiMAX 6250 [Kilmer Peak]' class = network dmesg has the following information: iwn0: Intel Centrino Advanced-N + WiMAX 6250 mem 0xf250-0xf2501fff irq 17 at device 0.0 on pci3 [and after service wpa_supplicant start wlan0] iwn0: iwn_config: could not configure runtime calibration iwn0: iwn_init_locked: could not configure device, error 35 An earlier kernel (from mid November) from the same branch works like a charm. Any hints? Is there more debug output I can provide to track this down? Cheers and thanks, Hannes -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBCQAGBQJStvZUAAoJELyJZYjffCjupYoP/j3SLrU21mSmydo6AxJaaBA3 +1I79QyyGoz6Kp3ea4sxSVMrnuWK3J6NKO5YCf0b10gjISA/iYOoHNh12Vltch3g x30+APbFtOq5IswO66HY816LOzYDo2fXGxMk/CZhspyOhJptC4bZWb9nrSoEQHEI UvjysflDUUDTa+vs/1CQ0Rall7FVmNSr7eeNdTCHhgV0xF7F7IqyUW6JbnDaYQEA mDwi5cxQNVhOeHjMd0wACO5rf09/bMdvo4m4DNnQNWrg9oPtbuWdRLMRtPZ0UC8W 4w+2ETWYgMCMiZO3kmwG76NI2jzXKHYwQO2/RrTahyWWcWuDzeJm5tK5PjxoN+JB B4B7AB/DIUQsUmBUhjZHTvg+U9Qa37wCWYGN5UO3aM4BEp4FTR4lsp80oEbt5/bt axOi1QVtZl1ZPOgZaoCXFiW4SQKA568uAiX8hlxfs2W1yAJ7CU4bfRyCugUVhBBK ZQAS1hX2sxXJHddrJwNNmAJ2/x+5NcYvzf4ij4hSIk5Gw4oP280rp/u2QIzCyhKx x8c5aPpJgIw/UNHYrBjAoHj+t5qHYANtgqLQUk3BEGOAoCsR2LzgBxObIZn+wRLv aS8qjC3NCknZLNuWPWdrQBleQV9EkqlJ7ODcgv82bqFUdNMwSKcmcX4TmLIvigDH CD+7c6uMkJB681a/IHTX =h++r -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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
