9.2-RC1 laptop lid cover problem
Hello :-) On my Dell Latitude D620 I have a bla(c/n)k screen after I close display and open it again. I cannot use this machine anymore as it was working on plaintext console (no xorg). What should I do to make screen return after display is closed and opened again? Should I load apm module or something similar or is this the display driver problem? Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.2-BETA2 panics
Hi, this host (used as a zfs server), was working since 8.2, actually was working nicely under 9.1, but after upgrading to the latest 9.2, it panics, 2 days in a row. Appart of being a newer version, it's now dataless while I run it through the loops - which could be the reason for the panics, so while I prepare it to run off a local disk, and see if that mitigates the problem, could someone take a look? Fatal trap 12: page fault while in kernel mode cpuid = 21; apic id = 25 fault virtual address = 0xfcc0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80d17f66 stack pointer = 0x28:0xff8d77b415b0 frame pointer = 0x28:0xff8d77b415f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 89 (txg_thread_enter) trap number = 12 panic: page fault cpuid = 21 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff8d77b41040 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff8d77b41100 panic() at panic+0x1ce/frame 0xff8d77b41200 trap_fatal() at trap_fatal+0x290/frame 0xff8d77b41260 trap_pfault() at trap_pfault+0x211/frame 0xff8d77b412f0 trap() at trap+0x344/frame 0xff8d77b414f0 calltrap() at calltrap+0x8/frame 0xff8d77b414f0 --- trap 0xc, rip = 0x80d17f66, rsp = 0xff8d77b415b0, rbp = 0xff8d77b415f0 --- bcopy() at bcopy+0x16/frame 0xff8d77b415f0 kthread_add() at kthread_add+0xe4/frame 0xff8d77b41710 kproc_kthread_add() at kproc_kthread_add+0xe1/frame 0xff8d77b418c0 spa_sync() at spa_sync+0x8d1/frame 0xff8d77b41990 txg_sync_thread() at txg_sync_thread+0x139/frame 0xff8d77b41aa0 fork_exit() at fork_exit+0x11f/frame 0xff8d77b41af0 fork_trampoline() at fork_trampoline+0xe/frame 0xff8d77b41af0 --- trap 0, rip = 0, rsp = 0xff8d77b41bb0, rbp = 0 --- Uptime: 21h5m46s more info at: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AAC regression in 9.2-BETA
On Fri, Aug 02, 2013 at 10:05:43PM +0200, Marius Strobl wrote: On Fri, Aug 02, 2013 at 02:44:04PM -0400, David Boyd wrote: I have an Adaptec 2820SA (SATA) controller that hangs the system during booting on 9.2-BETA[12]. The only message I see on the console refers to controller aac0 and indicates TIMEOUT 138 SECONDS. This same controller/motherboard works flawlessly with 9.1-RELEASE-p5. I have moved this hardware to testing mode and can rebuild often. I am asking for direction and suggestions as to which commits might be at fault. I am sorry that I didn't detect this problem earlier in the release cycle. Hope we can resolve this before 9.2-RELEASE. That could be due to MSIs being broken with your particular controller or mainboard. Please try whether setting the tunable hw.aac.enable_msi to 0 on the loader prompt before booting makes things work. If it does, please provide a verbose dmesg and the output of `pciconf -lcv`. For the records, between 9.1 and 9.2, aac(4) has been taught to take advantage of MSIs when available. However, 2820SA turned out to have broken MSI support. Thus, in r254004 a quirk blacklisting MSI usage for that model has been introduced. There was also a similar report for 2230S, in which case it was unclear whether that type of controller or the motherboard is the culprit. To be on the safe side, MSIs also have been blacklisted for 2230S in said revision. This change has been MFCed down to releng/9.2, so it will be part of the final 9.2-RELEASE. However, it doesn't seem warranted to generally disable the use of MSIs in aac(4) again. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-BETA2 panics
- Original Message - Hi, this host (used as a zfs server), was working since 8.2, actually was working nicely under 9.1, but after upgrading to the latest 9.2, it panics, 2 days in a row. Appart of being a newer version, it's now dataless while I run it through the loops - which could be the reason for the panics, so while I prepare it to run off a local disk, and see if that mitigates the problem, could someone take a look? Fatal trap 12: page fault while in kernel mode cpuid = 21; apic id = 25 fault virtual address = 0xfcc0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80d17f66 stack pointer = 0x28:0xff8d77b415b0 frame pointer = 0x28:0xff8d77b415f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 89 (txg_thread_enter) trap number = 12 panic: page fault cpuid = 21 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff8d77b41040 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff8d77b41100 panic() at panic+0x1ce/frame 0xff8d77b41200 trap_fatal() at trap_fatal+0x290/frame 0xff8d77b41260 trap_pfault() at trap_pfault+0x211/frame 0xff8d77b412f0 trap() at trap+0x344/frame 0xff8d77b414f0 calltrap() at calltrap+0x8/frame 0xff8d77b414f0 --- trap 0xc, rip = 0x80d17f66, rsp = 0xff8d77b415b0, rbp = 0xff8d77b415f0 --- bcopy() at bcopy+0x16/frame 0xff8d77b415f0 kthread_add() at kthread_add+0xe4/frame 0xff8d77b41710 kproc_kthread_add() at kproc_kthread_add+0xe1/frame 0xff8d77b418c0 spa_sync() at spa_sync+0x8d1/frame 0xff8d77b41990 txg_sync_thread() at txg_sync_thread+0x139/frame 0xff8d77b41aa0 fork_exit() at fork_exit+0x11f/frame 0xff8d77b41af0 fork_trampoline() at fork_trampoline+0xe/frame 0xff8d77b41af0 --- trap 0, rip = 0, rsp = 0xff8d77b41bb0, rbp = 0 --- Uptime: 21h5m46s The serialization in kthread_add() is wrong. It is possible for the oldtd it selects to exit and be reaped before we are able duplicate the copy region. I have a local patch for this, and I talked with julian@ jhb@ about it a few weeks ago but haven't sent them a patch for review. I'll get to that later today. more info at: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-BETA2 panics
- Original Message - Hi, this host (used as a zfs server), was working since 8.2, actually was working nicely under 9.1, but after upgrading to the latest 9.2, it panics, 2 days in a row. Appart of being a newer version, it's now dataless while I run it through the loops - which could be the reason for the panics, so while I prepare it to run off a local disk, and see if that mitigates the problem, could someone take a look? Fatal trap 12: page fault while in kernel mode cpuid = 21; apic id = 25 fault virtual address = 0xfcc0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80d17f66 stack pointer = 0x28:0xff8d77b415b0 frame pointer = 0x28:0xff8d77b415f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 89 (txg_thread_enter) trap number = 12 panic: page fault cpuid = 21 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff8d77b41040 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff8d77b41100 panic() at panic+0x1ce/frame 0xff8d77b41200 trap_fatal() at trap_fatal+0x290/frame 0xff8d77b41260 trap_pfault() at trap_pfault+0x211/frame 0xff8d77b412f0 trap() at trap+0x344/frame 0xff8d77b414f0 calltrap() at calltrap+0x8/frame 0xff8d77b414f0 --- trap 0xc, rip = 0x80d17f66, rsp = 0xff8d77b415b0, rbp = 0xff8d77b415f0 --- bcopy() at bcopy+0x16/frame 0xff8d77b415f0 kthread_add() at kthread_add+0xe4/frame 0xff8d77b41710 kproc_kthread_add() at kproc_kthread_add+0xe1/frame 0xff8d77b418c0 spa_sync() at spa_sync+0x8d1/frame 0xff8d77b41990 txg_sync_thread() at txg_sync_thread+0x139/frame 0xff8d77b41aa0 fork_exit() at fork_exit+0x11f/frame 0xff8d77b41af0 fork_trampoline() at fork_trampoline+0xe/frame 0xff8d77b41af0 --- trap 0, rip = 0, rsp = 0xff8d77b41bb0, rbp = 0 --- Uptime: 21h5m46s The serialization in kthread_add() is wrong. It is possible for the oldtd it selects to exit and be reaped before we are able duplicate the copy region. I have a local patch for this, and I talked with julian@ jhb@ about it a few weeks ago but haven't sent them a patch for review. I'll get to that later today. If you need to have it checked out, I can try it out. thanks, danny more info at: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 thanks, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Change in loader or kernel: won't boot with kfreebsd in grub2
On 12.08.2013 19:39, Thomas Mueller wrote: I still wonder why Super Grub Disk kfreebsd worked until recently. I figure something must have changed in FreeBSD loader or kernel structure since the Super Grub Disk didn't change in that time. For currdev, apparently the big hard drive is just recognized as one big drive with no reference to partitions (lsdev). Can you obtain the following information and send it to me? 1. lsdev output from the loader that works 2. gpart list from booted system 3. lsdev output from the loader that doesn't work -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FYI, Dag-Erling have committed the upstream fix to -HEAD today and we will make sure that this gets merged before 9.2-RELEASE. Author: des Date: Tue Aug 13 09:06:18 2013 New Revision: 254278 URL: http://svnweb.freebsd.org/changeset/base/254278 Log: Apply upstream revision 1.151 (fix relative symlinks) MFC after:3 days Modified: head/crypto/openssh/sftp.c Directory Properties: head/crypto/openssh/ (props changed) Modified: head/crypto/openssh/sftp.c == - --- head/crypto/openssh/sftp.cTue Aug 13 09:04:20 2013 (r254277) +++ head/crypto/openssh/sftp.c Tue Aug 13 09:06:18 2013(r254278) @@ -1328,7 +1328,8 @@ parse_dispatch_command(struct sftp_conn case I_SYMLINK: sflag = 1; case I_LINK: - - path1 = make_absolute(path1, *pwd); + if (!sflag) + path1 = make_absolute(path1, *pwd); path2 = make_absolute(path2, *pwd); err = (sflag ? do_symlink : do_hardlink)(conn, path1, path2); break; Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCgAGBQJSCrEpAAoJEG80Jeu8UPuzOsMIALKkg0+g2IhX5dAxGL9UU6AT 7/f/iEfDIYmTv1QRwZQ1B544Mf02NmSztEmVz5pwQCsSmw+rmF27t6iBbN6q5ipM XUB+A3VsAGRmI8j/2ixwzs3AXTAdC/uhgswVMQyiuS35cYaArGAirZWxUESGIiqk K7Hnc8vYDWZ+hbNIpPFNNvsdunltq42BJ5kHh07X3elqR7lJaGC7qQM8IoHo90nG R4GPagM6tbuXdB/UzrW0ozgRf4VqE+SFCC8UAnnE/E61h7Fb0/GkD0XlsdTFrl3f 0Aadhs+jfwxV7UJgyGvuep9RsFuM/mUMHXAw8K3vuPbF6KA9U7XI1KmS8ym5G3A= =ERoe -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Change in loader or kernel: won't boot with kfreebsd in grub2
On 12.08.2013 19:39, Thomas Mueller wrote: I still wonder why Super Grub Disk kfreebsd worked until recently. I figure something must have changed in FreeBSD loader or kernel structure since the Super Grub Disk didn't change in that time. For currdev, apparently the big hard drive is just recognized as one big drive with no reference to partitions (lsdev). Can you obtain the following information and send it to me? 1. lsdev output from the loader that works 2. gpart list from booted system 3. lsdev output from the loader that doesn't work -- WBR, Andrey V. Elsukov I can provide the gpart list from booted system, but how do I capture lsdev output without copying by pencil and paper? I looked in man loader and man loader.conf. I subsequently added some partitions (6,7,12,13,14) for Linux purposes, but that should have no current effect on booting FreeBSD. gpart show ada0 shows =34 5860533101 ada0 GPT (2.7T) 34 491520 1 efi (240M) 4915541600 2 linux-data (7.6G) 16491554 6- free - (3.0k) 16491560 295768568 3 freebsd-ufs (141G) 312260128 2- free - (1.0k) 312260130 128 8 freebsd-boot (64k) 312260258 209715200 9 freebsd-ufs (100G) 521975458 35651584011 freebsd-ufs (170G) 878491298 6- free - (3.0k) 87849130441943040 4 netbsd-ffs (20G) 920434344 8388608 5 netbsd-swap (4.0G) 92882295241943040 6 !0fc63daf-8483-4772-8e79-3d69d8477de4 (20G) 97076599216777216 7 linux-swap (8.0G) 9875432084194304012 !0fc63daf-8483-4772-8e79-3d69d8477de4 (20G) 1029486248 20971520013 !0fc63daf-8483-4772-8e79-3d69d8477de4 (100G) 1239201448 41943040014 !0fc63daf-8483-4772-8e79-3d69d8477de4 (200G) 1658631848 4192206714- free - (2T) 5850838562 838860810 freebsd-swap (4.0G) 5859227170 1305965- free - (637M) gpart show -l ada0 shows =34 5860533101 ada0 GPT (2.7T) 34 491520 1 WDGreen001 (240M) 4915541600 2 WDGreen002 (7.6G) 16491554 6- free - (3.0k) 16491560 295768568 3 WDGreen003 (141G) 312260128 2- free - (1.0k) 312260130 128 8 WDGreen008 (64k) 312260258 209715200 9 WDGreen009 (100G) 521975458 35651584011 WDGreen011 (170G) 878491298 6- free - (3.0k) 87849130441943040 4 WDGreen004 (20G) 920434344 8388608 5 WDGreen005 (4.0G) 92882295241943040 6 WDGreen006 (20G) 97076599216777216 7 WDGreen007 (8.0G) 9875432084194304012 WDGreen012 (20G) 1029486248 20971520013 WDGreen013 (100G) 1239201448 41943040014 WDGreen014 (200G) 1658631848 4192206714- free - (2T) 5850838562 838860810 WDGreen010 (4.0G) 5859227170 1305965- free - (637M) For the USB stick, gpart show da1 shows = 34 15240509 da1 GPT (7.3G) 34 1281 freebsd-boot (64k) 162 13202 freebsd-ufs (6.3G) 13200162 20403803 freebsd-swap (996M) 15240542 1 - free - (512B) or with labels, gpart show -l da1 shows = 34 15240509 da1 GPT (7.3G) 34 1281 usb64boot (64k) 162 13202 usb64root (6.3G) 13200162 20403803 usb64swap (996M) 15240542 1 - free - (512B) Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-Update + Sendmail
On 6 August 2013, at 09:18, Ted Hatfield t...@io-tx.com wrote: I too have been updating my systems by updating and building from source. To recompile and install sendmail from the /usr/src tree you can run these commands. cd /usr/src/lib/libsm; make clean; make obj; make depend; make cd /usr/src/lib/libsmutil; make clean; make obj; make depend; make cd /usr/src/usr.sbin/sendmail; make clean; make obj; make depend; make; make install This procedure will follow all the /etc/make.conf arguments. FreeBSD zool.lafn.org 9.1-RELEASE-p1 FreeBSD 9.1-RELEASE-p1 #4: Wed Feb 20 22:34:04 PST 2013 d...@zool.lafn.org:/usr/obj/usr/src/sys/LAFN i386 make of sendmail yields: cc -O2 -pipe -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include/sasl -DSASL -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c cc1: warnings being treated as errors /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c: In function 'sm_sasl_init': /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c:141: warning: passing argument 1 of 'sasl_set_alloc' from incompatible pointer type /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c:141: warning: passing argument 2 of 'sasl_set_alloc' from incompatible pointer type /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c:141: warning: passing argument 3 of 'sasl_set_alloc' from incompatible pointer type *** [sasl.o] Error code 1 /etc/make.conf: SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 WITHOUT_X11=yes # added by use.perl 2013-05-22 13:05:04 PERL_VERSION=5.12.4 I can't figure out where cc1 has been configured to treat warnings as errors. This has not happened before to me. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Change in loader or kernel: won't boot with kfreebsd in grub2
On 14.08.2013 05:41, Thomas Mueller wrote: On 12.08.2013 19:39, Thomas Mueller wrote: I still wonder why Super Grub Disk kfreebsd worked until recently. I figure something must have changed in FreeBSD loader or kernel structure since the Super Grub Disk didn't change in that time. For currdev, apparently the big hard drive is just recognized as one big drive with no reference to partitions (lsdev). Can you obtain the following information and send it to me? 1. lsdev output from the loader that works 2. gpart list from booted system 3. lsdev output from the loader that doesn't work -- WBR, Andrey V. Elsukov I can provide the gpart list from booted system, but how do I capture lsdev output without copying by pencil and paper? You can just make a photo. I looked in man loader and man loader.conf. I subsequently added some partitions (6,7,12,13,14) for Linux purposes, but that should have no current effect on booting FreeBSD. An output of `gpart show` contains less information that `gpart list`, it is useless for me :) -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Change in loader or kernel: won't boot with kfreebsd in grub2
I can provide the gpart list from booted system, but how do I capture lsdev output without copying by pencil and paper? You can just make a photo. I looked in man loader and man loader.conf. I subsequently added some partitions (6,7,12,13,14) for Linux purposes, but that should have no current effect on booting FreeBSD. An output of `gpart show` contains less information that `gpart list`, it is useless for me :) -- WBR, Andrey V. Elsukov How do I make a photo when I don't have a digital camera? If I had a digital camera, how would I convert the picture to text? I looked at man gpart and didn't see list in the list of commands: a little deficiency in the man page. Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 732558330 first: 6 entries: 128 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 209715200 (200M) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 1048576 Mode: r0w0e0 rawuuid: de838bc6-0456-46f8-a277-3a627846685f rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b label: MyBook1 length: 209715200 offset: 1048576 type: efi index: 1 end: 51455 start: 256 2. Name: da0p2 Mediasize: 8074035200 (7.5G) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 210763776 Mode: r0w0e0 rawuuid: 1fb90c07-1939-4a80-9e03-c47470f4f555 rawtype: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 label: MyBook2 length: 8074035200 offset: 210763776 type: linux-data index: 2 end: 2022655 start: 51456 3. Name: da0p3 Mediasize: 524288 (512k) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 3989831680 Mode: r0w0e0 rawuuid: 497d10d1-e7ec-4b50-ab0d-77eb5216eae3 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: MyBook3 length: 524288 offset: 8284798976 type: freebsd-boot index: 3 end: 2022783 start: 2022656 4. Name: da0p4 Mediasize: 53687091200 (50G) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 3990880256 Mode: r0w0e0 rawuuid: 1fd5faa9-09cb-40eb-9f9e-90cd2d041016 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: MyBook4 length: 53687091200 offset: 8285847552 type: freebsd-ufs index: 4 end: 15130111 start: 2022912 5. Name: da0p5 Mediasize: 4294967296 (4.0G) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 1843396608 Mode: r0w0e0 rawuuid: 344e66cb-a1be-4562-be82-1350d93d2da2 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: MyBook5 length: 4294967296 offset: 61972938752 type: freebsd-swap index: 5 end: 16178687 start: 15130112 6. Name: da0p6 Mediasize: 214748364800 (200G) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 1843396608 Mode: r0w0e0 rawuuid: 1e45c5ac-3623-47b1-bc66-98b8b972a0b0 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: MyBook6 length: 214748364800 offset: 66267906048 type: freebsd-ufs index: 6 end: 68607487 start: 16178688 7. Name: da0p7 Mediasize: 53687091200 (50G) Sectorsize: 4096 Stripesize: 0 Stripeoffset: 1843396608 Mode: r0w0e0 rawuuid: e39f40a7-415b-4bad-afac-f981378ccbf7 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: MyBook7 length: 53687091200 offset: 281016270848 type: freebsd-ufs index: 7 end: 81714687 start: 68607488 Consumers: 1. Name: da0 Mediasize: 3000558944256 (2.7T) Sectorsize: 4096 Mode: r0w0e0 Geom name: da1 modified: false state: OK fwheads: 255 fwsectors: 63 last: 15240542 first: 34 entries: 128 scheme: GPT Providers: 1. Name: da1p1 Mediasize: 65536 (64k) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0 rawuuid: 9fc8a879-75a4-11e1-8b1f-8c89a5131554 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: usb64boot length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: da1p2 Mediasize: 675840 (6.3G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 82944 Mode: r0w0e0 rawuuid: c5043e60-75a6-11e1-8b1f-8c89a5131554 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: usb64root length: 675840 offset: 82944 type: freebsd-ufs index: 2 end: 13200161 start: 162 3. Name: da1p3 Mediasize: 1044674560 (996M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2463515648 Mode: r0w0e0 rawuuid: e2540349-75a6-11e1-8b1f-8c89a5131554 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: usb64swap length: 1044674560 offset: 6758482944 type: freebsd-swap index: 3 end: 15240541 start: 13200162 Consumers: 1. Name: da1 Mediasize: 7803174912 (7.3G) Sectorsize: 512 Mode: r0w0e0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 5860533134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 251658240 (240M) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 1024 Mode: r0w0e0 rawuuid: 44de8f9c-b9d2-11e0-b041-8c89a5131554 rawtype:
