Second Call for 2016Q3 quarterly status reports
Dear FreeBSD Community Ten days remain in the submission period -- plase send in your entries for the 2016Q3 report! More details quoted below. -Ben (on behalf of monthly@) On Wed, 7 Sep 2016, Benjamin Kaduk wrote: > Dear FreeBSD Community, > > The deadline for the next FreeBSD Quarterly Status update is October 7, > 2016, for work done in July through September. > > Status report submissions do not have to be very long. They may be about > anything happening in the FreeBSD project and community, and provide a > great way to inform FreeBSD users and developers about what you're working > on. Submission of reports is not restricted to committers. Anyone doing > anything interesting and FreeBSD-related can -- and should -- write one! > > The preferred and easiest submission method is to use the XML generator > [1] with the results emailed to the status report team at monthly at > FreeBSD.org . There is also an XML template [2] which can be filled out > manually and attached if preferred. For the expected content and style, > please study our guidelines on how to write a good status report [3]. > You can also review previous issues [4][5] for ideas on the style and > format. > > We are looking forward to all of your 2016Q3 reports! > > Thanks, > > Ben (on behalf of monthly@) > > [1] https://www.FreeBSD.org/cgi/monthly.cgi > [2] https://www.FreeBSD.org/news/status/report-sample.xml > [3] https://www.FreeBSD.org/news/status/howto.html > [4] https://www.FreeBSD.org/news/status/report-2016-01-2016-03.html > [4] https://www.FreeBSD.org/news/status/report-2016-04-2016-06.html > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[REVISED] [HEADS-UP] 11.0-RELEASE status update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: [Corrected the date.] Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirrors as a result of a few last-minute security fixes we feel are imperative to include in the final release. FreeBSD users already running 11.0-RELEASE will be given instructions on how to safely upgrade systems to the 11.0-RELEASE-p1 in the final announcement email. Those building from source code can obtain the latest security updates from the releng/11.0 branch in Subversion: svn://svn.freebsd.org/base/releng/11.0 As the FreeBSD Project strives to provide the best possible product, the Release Engineering team decided to build an updated release to include the fixes. At present, we expect to have the final release available Wednesday, October 5th. If you have not yet downloaded 11.0-RELEASE, please wait for the official release announcement. Thank you in advance for your patience waiting for 11.0-RELEASE, and of course for understanding the reasons behind the updated release. Glen On behalf of: re@ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJX7FPNAAoJEAMUWKVHj+KT2joP/0/0AOYfTbFUgZeEUXlmdfew 7nS31bQrBCXi7dgPicfSavdvDfqi4sgiw2/+HY3MxpfLWFJ/WNGveiwryGSiapkA V3BJ9MCOZb3ZZTbp0JlwbRk1NyGg4ur0S4L6zD+MXuHE95Kts3m/ON8CiGtNUE+1 rzE7Yr10tsU2Zu1Bvtv8rJa9SfLCln8k2FXtG0pxVWO+cK2xo6v84bjOJdExrB4t eXYoMSoxIyZd1Kv2nLbL1mG7RrLQFVm4TrurMwALI39hVr+IWIvElmo6wndDhTly XE8aMtpgUMp9b4PrQM+BgFVooR4ihFl0cslHfDuBGuiVJMQoa63agUfGAkclc9Na nwiJiwcQStOdHcRAnZNBms9DTeNXDD0whq30JoY45kFRI74wjjqP8oNUCUWEd6e8 n1puD2Zr2fqX0NziwtRg3Hy0EHM+9rQTEDtyHCG05sqTncyU7p6tkd49FfndXqaq h/JkHTP1iyQYsq07GZzyhPA04e/i3N8Djwm+WoRgOlSrItJiPQ/FuqKV0cSERvPR XZm3DPPRt04aOFe7XGrl2IHi+J6LZ5uwYEXiHFb+fPQMuROZ+IJC0Wu56HI2LHGL f5wyPiNE1NJIeYLzIgk3UUrENaylsW4/NsgLFj6TW//24ekF2NR+Nk8u7mvoJuXq vcLDdPW7mReqF13WLzh/ =RcJK -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zpool (online|replace|labelclear) issues, -f option also failing
> Hi, > As a start you can use these in /boot/loader.conf to prevent the confusion about gptid or disk_ident. I disabled gptid at my computer. But if > I understand you would like to disable disk_ident. For ZFS it should not matter what you use. > $ sysctl kern.geom.label > kern.geom.label.disk_ident.enable: 1 > kern.geom.label.gptid.enable: 0 > kern.geom.label.gpt.enable: 1 > kern.geom.label.ufs.enable: 1 > kern.geom.label.ufsid.enable: 1 > kern.geom.label.reiserfs.enable: 1 > kern.geom.label.ntfs.enable: 1 > kern.geom.label.msdosfs.enable: 1 > kern.geom.label.iso9660.enable: 1 > kern.geom.label.ext2fs.enable: 1 > kern.geom.label.debug: 0 Thanks for that, this would probably work, but I don't understand why it would change in the first place. I know that when it occurred it was offline and I think it came back online when the system was rebooted. I'm not positive tho. My guess is the scan found it on diskid before dptid, but then why is gptid first for the others? I'm just going to replace the drive with itself with gptid because I'v already wiped some data with dd. (even tho a scrub would prob be good enough) > Further. Does ZFS see 14989197580381994958 and gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 as the same disk? Zpool replace also has an option to replace the disk 'with itself'. Just provide it one parameter like this: > # zpool replace tank 14989197580381994958 > or > # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > Does that help? I actually didn't realize this. However the same error persists. # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool replace -f tank /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' > Oh, while I read your mail again. You have 2 GB swap configured on the disk so wiping 2MB at the start of the disk does not wipe the freebsd-zfs metadata of the da14p2 partition. Try wiping 3GB from the start and end of the disk and repartition it. Thanks for pointing this out! It would probably help if the correct area on the disk is wiped. Although it still seems that labelclear isn't up for the task. I really think the force (-f) flag needs a bump in power (for both replace and labelclear). Am I misunderstanding the use for the labelclear command? It clears the label that zdb will show for possibly similar circumstances that i'm encountering? # zpool labelclear -f gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is a member (ACTIVE) of pool "tank" Apologies, I failed to mention labelclear in my original post. It is providing similar output as the replace command. As the device is offline from the pool. Is this the correct behavior to show being an (ACTIVE) member of the pool? After wiping the correct area on the disk via dd, the replace successfully added the drive back to the pool! Thanks for pointing out my error. Thanks for taking a look at this Ronald and Allan! Ultima ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[HEADS-UP] 11.0-RELEASE status update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirrors as a result of a few last-minute security fixes we feel are imperative to include in the final release. FreeBSD users already running 11.0-RELEASE will be given instructions on how to safely upgrade systems to the 11.0-RELEASE-p1 in the final announcement email. Those building from source code can obtain the latest security updates from the releng/11.0 branch in Subversion: svn://svn.freebsd.org/base/releng/11.0 As the FreeBSD Project strives to provide the best possible product, the Release Engineering team decided to build an updated release to include the fixes. At present, we expect to have the final release available Wednesday, October 3rd. If you have not yet downloaded 11.0-RELEASE, please wait for the official release announcement. Thank you in advance for your patience waiting for 11.0-RELEASE, and of course for understanding the reasons behind the updated release. Glen On behalf of: re@ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJX7EaGAAoJEAMUWKVHj+KTtrgP/iaIozjqDQ2poH1i7J+BewmE wov+vRcfmGmBvCFLxGPWDsXsYWYw8HCUNrloBesNlUZNe7BoFKliVrBp7KAN5YRE R+l9AQU8u7UhYoKbM1epB28nDYdLH/veKMpkhyEr2mPglmRDJoJa1JL3xcnRXDj+ yFeeCH5He/jH/ILiO8ChfY8e3aA+K/qMOSicVENW5M2kGs/q0m/i5UZK2LZ+gT7R /eMl0USfW2B5LebHViv3a6GRArfTzBYZKYdoxXH7vUZ1zgb9CcEPfhYBxu41RMe3 I+HquvqzWKPNwG3GhwqPmKfwQt4PHlATkZwddGosIgSmUZRhhD4eR0DWdXD6k/oS iSi7QR8lef6ALcVTjt65JNqzPF/9eUJsZikcI0Ov6I0TkV2yzAGnUNneZQ6+22AS //ZhqWkIu7w1hePJ+Af+SZJDzVdUWzVNiAyMmSFkfW3mFaidyhjR0OULnquG6kSS kdPOdl/RwJzfP3wkFjt56I8YTyk7YQdwNEcEBQUlXlyZOC/NvUH5eebPJ1Va5UDV q0FHFaYiATKvQyZUO3Ne9eLzBdYQhmaPSrvTGXrZw53hgShIBOEnwkJYiEGgySL3 vCDro397boLkRL89HUXwuCFurZp/7g/V+I3w4X45y2/GpC/w7isPX/5YYJloETnR VLGBedKpJbR/5LUJH8Bw =t8IC -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Destroy GPT partition scheme absolutely, how?
On 28/09/2016 21:08, Andrey V. Elsukov wrote: > This is very strange problem, how did you created MBR if you have not > destroyed GPT? :) Using a tool that's not aware of GPT at all? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freeze during booting of ASUS F2A85-M motherboard with Coreboot
Problem is, my serial console cable (USB<->RS232, because I don't have RS232 port in my computers), seems to be broken, so I'm only attaching verbose boot log from stock UEFI. I have also found a great website ( https://review.coreboot.org/cgit/board-status.git/tree/ ) which seems to contain working Coreboot configs. I am going to try it tomorrow. On 09/27/16 10:45 PM, John Baldwin wrote: > On Tuesday, September 27, 2016 10:31:24 PM Piotr Kubaj wrote: >> No, I get only messages about allocating window. >> >> On 09/26/16 22:48, John Baldwin wrote: >>> On Wednesday, September 21, 2016 11:19:05 AM Piotr Kubaj wrote: I'm trying to boot the ASUS F2A85-M board with flashed Coreboot 4.4 and SeaBIOS 1.9.1 as a payload. This board works nicely with stock UEFI, it can also boot Slackware 14.2 from Coreboot with SeaBIOS without any issues. But it seems to have problems with FreeBSD (I've tried 11.0-RC3 and later 12.0-CURRENT). That's why I'm posting it here, instead of Coreboot mailing lists. Booting freezes after printing: pcib1: failed to allocate initial I/O port window: 0x1000-0x1fff >>> >>> Do you get this message in a verbose dmesg with the stock UEFI? >>> > > Are you able to capture a full verbose dmesg via a serial console or the like > that would really help as it may be that we are seeing a resource conflict > with the way Coreboot sets up the PCI bridge windows and then disabling > an I/O window that happens to break something. A verbose dmesg from the > stock UEFI would also be useful, though it is less important. > Table 'FACP' at 0xdd765e60 [1] Table 'APIC' at 0xdd765f70 [1] APIC: Found table at 0xdd765f70 [1] APIC: Using the MADT enumerator. [1] MADT: Found CPU APIC ID 16 ACPI ID 1: enabled [1] SMP: Added CPU 16 (AP) [1] MADT: Found CPU APIC ID 17 ACPI ID 2: enabled [1] SMP: Added CPU 17 (AP) [1] MADT: Found CPU APIC ID 18 ACPI ID 3: enabled [1] SMP: Added CPU 18 (AP) [1] MADT: Found CPU APIC ID 19 ACPI ID 4: enabled [1] SMP: Added CPU 19 (AP) [1] Copyright (c) 2013-2016 The HardenedBSD Project. [1] Copyright (c) 1992-2016 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 11.0-BETA4-HBSD #10 887e989(hardened/11-stable/master-libressl): Fri Aug 12 18:02:38 CEST 2016 [1] root@DESKTOP1:/usr/obj/usr/src/sys/DESKTOP1 amd64 [1] FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) [1] Table 'FACP' at 0xdd765e60 [1] Table 'APIC' at 0xdd765f70 [1] Table 'FPDT' at 0xdd765fe8 [1] Table 'MCFG' at 0xdd766030 [1] Table 'SSDT' at 0xdd766ee8 [1] Table 'HPET' at 0xdd7660c8 [1] Table 'IVRS' at 0xdd766100 [1] Table 'BGRT' at 0xdd766170 [1] Table 'SSDT' at 0xdd7661a8 [1] ACPI: No SRAT table found [1] PPIM 0: PA=0xf900, VA=0x8221, size=0x30, mode=0x1 [1] VT(efifb): resolution 1024x768 [1] HBSD: initialize and check HardenedBSD features (version 46). [1] [HBSD ASLR] status: opt-out [1] [HBSD ASLR] mmap: 30 bit [1] [HBSD ASLR] exec base: 30 bit [1] [HBSD ASLR] stack: 42 bit [1] [HBSD ASLR] vdso: 28 bit [1] [HBSD ASLR] map32bit: 18 bit [1] [HBSD ASLR] disallow MAP_32BIT mode mmap: opt-out [1] [HBSD HARDENING] procfs hardening: enabled [1] [HBSD HARDENING] randomize pids: enabled [1] [HBSD HARDENING] unset insecure init variables: enabled [1] [HBSD ASLR (compat)] status: opt-out [1] [HBSD ASLR (compat)] mmap: 14 bit [1] [HBSD ASLR (compat)] exec base: 14 bit [1] [HBSD ASLR (compat)] stack: 14 bit [1] [HBSD ASLR (compat)] vdso: 8 bit [1] [HBSD LOG] logging to system: enabled [1] [HBSD LOG] logging to user: disabled [1] [HBSD PAGEEXEC] status: opt-out [1] [HBSD MPROTECT] status: opt-out [1] [HBSD SEGVGUARD] status: opt-in [1] [HBSD SEGVGUARD] expiry: 120 sec [1] [HBSD SEGVGUARD] suspension: 600 sec [1] [HBSD SEGVGUARD] maxcrahes: 5 [1] Preloaded elf kernel "/boot/kernel/kernel" at 0x820b7000. [1] Preloaded /boot/entropy "/boot/entropy" at 0x820b9068. [1] Preloaded elf obj module "/boot/kernel/linprocfs.ko" at 0x820b90b8. [1] Preloaded elf obj module "/boot/kernel/linux_common.ko" at 0x820b95e8. [1] Preloaded elf obj module "/boot/kernel/zfs.ko" at 0x820b9c98. [1] Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0x820ba300. [1] Preloaded ada0p4:geli_keyfile0 "/boot/geli/ada2p4.key" at 0x820ba8b0. [1] Preloaded elf obj module "/boot/modules/nvidia.ko" at 0x820ba910. [1] Preloaded elf obj module "/boot/kernel/linux.ko" at 0x820baf38. [1] Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0x820bb620. [1] Calibrating TSC clock ... TSC clock: 3951498125 Hz [1] CPU: AMD Athlon(tm) X4 750K Quad Core Processor (3951.50-MHz K8-class CPU) [1] Origin="AuthenticAMD" Id=0x610f01 Family=0x15 Model=0x10 Stepping=1 [1] Feat
Re: Destroy GPT partition scheme absolutely, how?
On 28.09.2016 22:02, Allan Jude wrote: > I wonder if this issue is related at all to the new 'auto resize' gpart > bits. That leaves the 'uncommitted' transaction pending, and may require > a 'gpart undo' before the other commands will work correctly. All other commands that do any changes will issue 'commit', so they will work correctly. I think you are confusing 'auto resize' with 'recovery needed'. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Destroy GPT partition scheme absolutely, how?
On Wed, Sep 28, 2016 at 1:02 PM, Allan Jude wrote: > On 2016-09-27 01:58, Warner Losh wrote: >> On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel >> wrote: >>> On 27 Sep 2016, at 14:28, Warner Losh wrote: dd of 2MB of zeros to the start and end of the disk. That will destroy pretty much everything. For SSDs, sometimes you can do the same with TRIMs only faster (other times they are slower or unreliable). >>> >>> Yeah, but it would be nicer to not have to know that particular magic >>> incarnation :) >> >> Disk formatting has always been 3 parts magic, 2 parts luck and 1 part skill >> :) >> >> It doesn't fit nicely into geom because metadata can live elsewhere. >> >> I forgot to add the caveat not to try this on a disk that is part of a >> RAID volume. >> >> Warner >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > > I wonder if this issue is related at all to the new 'auto resize' gpart > bits. That leaves the 'uncommitted' transaction pending, and may require > a 'gpart undo' before the other commands will work correctly. > > I wonder if something like 'zpool labelclear', but for gpart would be > useful, that just nukes the first and last few MB of the disk. I know in > the installer we jump through a number of hoops to try to clear out old > stuff, and having one command would be better. I thought the auto resize stuff was backed out, precisely because it left bogons around... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Destroy GPT partition scheme absolutely, how?
On 2016-09-27 01:58, Warner Losh wrote: > On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel wrote: >> >>> On 27 Sep 2016, at 14:28, Warner Losh wrote: >>> dd of 2MB of zeros to the start and end of the disk. That will destroy >>> pretty much everything. For SSDs, sometimes you can do the same with >>> TRIMs only faster (other times they are slower or unreliable). >> >> Yeah, but it would be nicer to not have to know that particular magic >> incarnation :) > > Disk formatting has always been 3 parts magic, 2 parts luck and 1 part skill > :) > > It doesn't fit nicely into geom because metadata can live elsewhere. > > I forgot to add the caveat not to try this on a disk that is part of a > RAID volume. > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I wonder if this issue is related at all to the new 'auto resize' gpart bits. That leaves the 'uncommitted' transaction pending, and may require a 'gpart undo' before the other commands will work correctly. I wonder if something like 'zpool labelclear', but for gpart would be useful, that just nukes the first and last few MB of the disk. I know in the installer we jump through a number of hoops to try to clear out old stuff, and having one command would be better. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Destroy GPT partition scheme absolutely, how?
On 26.09.2016 23:51, John Baldwin wrote: >> Why not just use "gpart destroy -F provider"? > > That doesn't always work. In particular, if a disk was partitioned with GPT > and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the > MBR will leave most of the GPT intact and the disk will come up with the old > GPT partitions, not as a raw disk. If you would did `gpart destroy -F` for GPT, then it would not have appeared again. This is very strange problem, how did you created MBR if you have not destroyed GPT? :) After this commit it seems very unlikely to reproduce https://svnweb.freebsd.org/base?view=revision&revision=292057 Described problem can be reproduced with BSD label. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: zpool (online|replace|labelclear) issues, -f option also failing
On 2016-09-27 16:53, Ultima wrote: > Hello, > > I am currently trying to replace a disk that was offlined and getting the > following error: > > # zpool replace tank 14989197580381994958 > gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > invalid vdev specification > use '-f' to override the following errors: > /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool > 'tank' > zdb -l /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 Will tell you about the ZFS label that is on that disk. The subject mentions labelclear, but you didn't indicate how you tried to use it. > # zpool replace -f tank 14989197580381994958 > gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 > invalid vdev specification > the following errors must be manually repaired: > /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool > 'tank' > > # zpool status tank > pool: tank > state: DEGRADED > status: One or more devices has been taken offline by the administrator. > Sufficient replicas exist for the pool to continue functioning in a > degraded state. > action: Online the device using 'zpool online' or replace the device with > 'zpool replace'. > scan: resilvered 1.10T in 9h4m with 0 errors on Tue Sep 20 00:33:32 2016 > config: > > NAMESTATE READ WRITE CKSUM > tankDEGRADED 0 0 0 > raidz2-0 ONLINE 0 0 0 >gptid/8bdbd180-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8c4df91d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8ccf21a3-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8d5521cb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8de13b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8e842f92-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > raidz2-1 DEGRADED 0 0 0 >gptid/8bba4a82-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8c26d491-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8ca3fea6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >14989197580381994958OFFLINE 0 0 0 > was /dev/diskid/DISK-p2 >gptid/8db26351-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8e4bfa70-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > raidz2-2 ONLINE 0 0 0 >gptid/8b957b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8c0340da-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8c77ddcb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8cf6b7f1-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8d84b31e-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8e146dad-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > raidz2-3 ONLINE 0 0 0 >gptid/8ebb39df-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8ef49770-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/2f94035d-7e9f-11e6-abe9-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8f69cf08-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8fa7c0a6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 >gptid/8fe7816d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 > logs > gptid/683dc146-f531-11e5-90c5-fcaa14edc6a6ONLINE 0 0 0 > > errors: No known data errors > > # glabel status | grep da14 > gptid/24a57a9b-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p1 > gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p2 > diskid/DISK- N/A da14 > > # gpart show da13 da14 > =>40 7814037088 da13 GPT (3.6T) > 40 4194304 1 freebsd-swap (2.0G) > 4194344 7809842784 2 freebsd-zfs (3.6T) > > =>40 7814037088 da14 GPT (3.6T) > 40 4194304 1 freebsd-swap (2.0G) > 4194344 7809842784 2 freebsd-zfs (3.6T) > > # uname -a > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r306300: Sat Sep 24 > 14:24:23 EDT 2016 > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > amd64 > > I recently offlined the device and after onlining it the label changed to > geom. After a few reboots the pool started importing by diskid. After > attempting to offline/online by gptid, would continue to fail with an > error. I decided try to replace it and is also failing with the error > above. I also wiped the first & last 2MB of the disk without success. Is > they're a known issue or perhaps I'm missing something obvious? zpool > labelclear is also providing a similar error. The -f options are not > helping. > > > Any ideas what my issue maybe? The error sugge
Re: zpool (online|replace|labelclear) issues, -f option also failing
Hi, As a start you can use these in /boot/loader.conf to prevent the confusion about gptid or disk_ident. I disabled gptid at my computer. But if I understand you would like to disable disk_ident. For ZFS it should not matter what you use. $ sysctl kern.geom.label kern.geom.label.disk_ident.enable: 1 kern.geom.label.gptid.enable: 0 kern.geom.label.gpt.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.ext2fs.enable: 1 kern.geom.label.debug: 0 Further. Does ZFS see 14989197580381994958 and gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 as the same disk? Zpool replace also has an option to replace the disk 'with itself'. Just provide it one parameter like this: # zpool replace tank 14989197580381994958 or # zpool replace tank gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 Does that help? Oh, while I read your mail again. You have 2 GB swap configured on the disk so wiping 2MB at the start of the disk does not wipe the freebsd-zfs metadata of the da14p2 partition. Try wiping 3GB from the start and end of the disk and repartition it. Success. Ronald. On Tue, 27 Sep 2016 22:53:27 +0200, Ultima wrote: Hello, I am currently trying to replace a disk that was offlined and getting the following error: # zpool replace tank 14989197580381994958 gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification use '-f' to override the following errors: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool replace -f tank 14989197580381994958 gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 invalid vdev specification the following errors must be manually repaired: /dev/gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 is part of active pool 'tank' # zpool status tank pool: tank state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: resilvered 1.10T in 9h4m with 0 errors on Tue Sep 20 00:33:32 2016 config: NAMESTATE READ WRITE CKSUM tankDEGRADED 0 0 0 raidz2-0 ONLINE 0 0 0 gptid/8bdbd180-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c4df91d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8ccf21a3-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8d5521cb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8de13b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8e842f92-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 raidz2-1 DEGRADED 0 0 0 gptid/8bba4a82-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c26d491-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8ca3fea6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 14989197580381994958OFFLINE 0 0 0 was /dev/diskid/DISK-p2 gptid/8db26351-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8e4bfa70-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 raidz2-2 ONLINE 0 0 0 gptid/8b957b47-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c0340da-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8c77ddcb-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8cf6b7f1-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8d84b31e-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8e146dad-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 raidz2-3 ONLINE 0 0 0 gptid/8ebb39df-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8ef49770-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/2f94035d-7e9f-11e6-abe9-fcaa14edc6a6 ONLINE 0 0 0 gptid/8f69cf08-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8fa7c0a6-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 gptid/8fe7816d-f52a-11e5-90c5-fcaa14edc6a6 ONLINE 0 0 0 logs gptid/683dc146-f531-11e5-90c5-fcaa14edc6a6ONLINE 0 0 0 errors: No known data errors # glabel status | grep da14 gptid/24a57a9b-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p1 gptid/31be0527-84f0-11e6-bbbc-fcaa14edc6a6 N/A da14p2 diskid/DISK- N/A da14 # gpart show da13 da14 =>40 7814037088 da13 GPT (3.6T) 40 4194304 1 freebsd-swap (2.0G) 4194344 7809842784 2
Re: should aarch64 cross-build work at amd64?
On Fri, 23 Sep 2016 22:19:15 +, Glenn Barber wrote: On Sat, Sep 24, 2016 at 12:54:05AM +0300, Boris Samorodov wrote: > 24.09.2016 00:44, Boris Samorodov ?: > > 24.09.2016 00:39, Glen Barber ?: > >> On Sat, Sep 24, 2016 at 12:35:30AM +0300, Boris Samorodov wrote: > >>> make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177: > >>> In-tree binutils does not support the aarch64 architecture. Install the > >>> aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX. > >> > >> These lines are relevant. > > > > Ops. Thank you. > > The error when aarch64-binutils are installed: > - > % sudo poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m > svn+https -J 8 Try with 'arm64.aarch64'. Glen Glen, The more I read this, the less I understand. I've built and install'd aarch64-binutils on my poud box, then created an "-x -a arm64.aarch64 -m svn" jail - which worked fine - but that jail won't build anything. No /usr/bin/ld, so toolchain is borked, so can't build ports-mgmt/pkg. What utterly obvious thing have I missed? I've spent hours trying to fake out the nxb-bin stuff, or to find some other point of entry, no joy. FreeBSD aubey2.bogons 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r306286: Fri Sep 23 21:32:37 MDT 2016 toor@aubey2.bogons:/usr/obj/usr/src/sys/GENERIC amd64 poudriere-devel-3.1.99.20160624_2 qemu-user-static-2.6.90.g20160728 aarch64-binutils-2.25.1_3,1 # /usr/sbin/binmiscctl lookup aarch64 name: aarch64 interpreter: /usr/local/bin/qemu-aarch64-static flags: ENABLED USE_MASK magic size: 20 magic offset: 0 magic: 0x7f 0x45 0x4c 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0xb7 0x00 mask: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xfe 0xff 0xff 0xff failing jail is "11-stab-arm64 11.0-PRERELEASE r306344 arm64.aarch64 svn 2016-09-26 18:54:15 /usr/local/pd/jails/11-stab-arm64" advance thanks, Ross -- Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, r...@athabascau.ca "Plato's scheme of folly, which would have the philosophers take over the management of affairs, has been turned on its head; the men of affairs have taken over the direction and pursuit of knowledge." -- Thorstein Veblen, _The Higher Learning in America_ -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: should aarch64 cross-build work at amd64?
28.09.2016 07:22, Glen Barber пишет: > On Tue, Sep 27, 2016 at 09:46:29PM -0600, Ross Alexander wrote: >> On Fri, 23 Sep 2016 22:19:15 +, Glenn Barber wrote: >> >>> On Sat, Sep 24, 2016 at 12:54:05AM +0300, Boris Samorodov wrote: 24.09.2016 00:44, Boris Samorodov ?: > 24.09.2016 00:39, Glen Barber ?: >> On Sat, Sep 24, 2016 at 12:35:30AM +0300, Boris Samorodov wrote: >>> make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177: >>> In-tree binutils does not support the aarch64 architecture. Install the >>> aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX. >> >> These lines are relevant. > > Ops. Thank you. The error when aarch64-binutils are installed: - % sudo poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m svn+https -J 8 >>> >>> Try with 'arm64.aarch64'. >>> Glen >> >> Glen, >> >> The more I read this, the less I understand. I've built and install'd >> aarch64-binutils on my poud box, then created an "-x -a arm64.aarch64 -m svn" >> jail - which worked fine - but that jail won't build anything. No >> /usr/bin/ld, so toolchain is borked, so can't build ports-mgmt/pkg. >> What utterly obvious thing have I missed? I've spent hours trying to >> fake out the nxb-bin stuff, or to find some other point of entry, no >> joy. >> >> FreeBSD aubey2.bogons 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r306286: >> Fri Sep 23 21:32:37 MDT 2016 >> toor@aubey2.bogons:/usr/obj/usr/src/sys/GENERIC amd64 >> >> poudriere-devel-3.1.99.20160624_2 >> >> qemu-user-static-2.6.90.g20160728 >> >> aarch64-binutils-2.25.1_3,1 >> >> # /usr/sbin/binmiscctl lookup aarch64 >> name: aarch64 >> interpreter: /usr/local/bin/qemu-aarch64-static >> flags: ENABLED USE_MASK >> magic size: 20 >> magic offset: 0 >> magic: 0x7f 0x45 0x4c 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 >>0x00 0x00 0x00 0x00 0x02 0x00 0xb7 0x00 >>mask: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0xff 0xff 0xff 0xff >> 0xff 0xff 0xff 0xff 0xfe 0xff 0xff 0xff >> >> failing jail is "11-stab-arm64 11.0-PRERELEASE r306344 arm64.aarch64 svn >> 2016-09-26 18:54:15 /usr/local/pd/jails/11-stab-arm64" >> > > You should not need to use binmiscctl and QEMU. Try: > > # poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m \ > svn+https Last time I tried the needed option for arch was "-a arm64.aarch64". Glen, it was you who helped me to fugure out the option. :-) -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve signature.asc Description: OpenPGP digital signature
