Re: bad hash in repo
> Looking up update.FreeBSD.org >> Applying patches... done. >> Fetching 2 files... >> 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has >> incorrect hash. > Do you have a transparent proxy in your network or at your ISP raw nekkid global ip space, aka the internet :) randy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bad hash in repo
On Sat., 18 Aug. 2018, 01:45 Randy Bush, wrote: > seeing a lot of these > > Looking up update.FreeBSD.org > Applying patches... done. > Fetching 2 files... > 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has > incorrect hash. > Do you have a transparent proxy in your network or at your ISP as I have seen similar when those have been present. Bypassing these may fix your issue. > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Managed Service Providers (MSPs)
Hi, I just wanted to check if you would be interested in a list of Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)? We also have the data intelligence of: • Managed Service Providers (MSP’s) • Managed Security Service Providers (MSSP’s • IT Decision Makers – 6million across all industry • Business Decision Makers – 10 million across all industry • Value Added Resellers- VARs • Independent Software Vendors- ISVs • System Integrators- SIs • VoIP Service Providers. • Telecommunications Service Providers (TSPs) • Application Service Providers (ASPs) • IT Managed Services Providers (ITMSP) • Storage Service Providers (SSPs) Kindly review and let me know if I can share more information on this. I look forward to hearing from you. Regards, Selina Marketing Specialist If you don't want to include yourself in our mailing list, please reply back “Leave Out" in a subject line ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
bad hash in repo
seeing a lot of these Looking up update.FreeBSD.org mirrors... 2 mirrors found. Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. Fetching 2 patches.. done. Applying patches... done. Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has incorrect hash. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Portas Abertas SENAI | Porto Alegre | 25 de agosto
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kern.geom.eli.boot_passcache doesn't work anymore in 11.2-RELEASE for additional disks
I have a geli-encrypted zroot which was created with Auto (ZFS) Guided Root-on-ZFS during fresh installation of 11.1-RELEASE. No bootpool anymore, Partition scheme GPT (BIOS) The additional disks were prepared with 'geli init -b' to set only the BOOT-flag and the same password as the disks for zroot. Worked as expected: bootloader asked only one time for password and during boot every encrypted disk was attached. Since upgrading to 11.2-RELEASE geli asks during boot a second time for the password when it tries to attach the additional disks. This is like the old style, when this line gets lost between other boot-messages. The system won't boot further at this point. Typing the password 'blind' and geli will attach every additional disk. So far no any other errors. Being irritated, I did a complete reinstall with a 11.2 image from usb-stick, but geli asks still twice for the password. Some input: sysctl -a | grep kern.geom.eli kern.geom.eli.key_cache_misses: 0 kern.geom.eli.key_cache_hits: 0 kern.geom.eli.key_cache_limit: 8192 kern.geom.eli.boot_passcache: 1 kern.geom.eli.batch: 0 kern.geom.eli.threads: 0 kern.geom.eli.overwrites: 5 kern.geom.eli.visible_passphrase: 0 kern.geom.eli.tries: 3 kern.geom.eli.debug: 0 kern.geom.eli.version: 7 zpool status zroot pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p3.eli ONLINE 0 0 0 ada1p3.eli ONLINE 0 0 0 ada2p3.eli ONLINE 0 0 0 errors: No known data errors geli list ada0p3.eli Geom name: ada0p3.eli State: ACTIVE EncryptionAlgorithm: AES-XTS KeyLength: 256 Crypto: hardware Version: 7 UsedKey: 0 Flags: BOOT, GELIBOOT KeysAllocated: 67 KeysTotal: 67 Providers: 1. Name: ada0p3.eli Mediasize: 285711790080 (266G) Sectorsize: 4096 Mode: r1w1e1 Consumers: 1. Name: ada0p3 Mediasize: 285711794176 (266G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 geli list da0.eli Geom name: da0.eli State: ACTIVE EncryptionAlgorithm: AES-XTS KeyLength: 256 Crypto: hardware Version: 7 UsedKey: 0 Flags: BOOT KeysAllocated: 466 KeysTotal: 466 Providers: 1. Name: da0.eli Mediasize: 2000398929920 (1.8T) Sectorsize: 4096 Mode: r1w1e2 Consumers: 1. Name: da0 Mediasize: 2000398934016 (1.8T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64
On 07/08/2018 15:58, Mark Martinec wrote: Collected, here it is: https://www.ijs.si/usr/mark/tmp/dtrace-cmd.out.bz2 2018-08-14 11:18, Andriy Gapon wrote: I see one memory leak, not sure if it's the only one. It looks like vdev_geom_read_config() leaks all parsed vdev nvlist-s but the last. The problems seems to come from r316760. Before that commit the function would return upon finding the first valid config, but now it keeps iterating. The memory leak should not be a problem when vdev-s are probed sufficiently rarely, but it appears that with an unhealthy pool the probing can happen much more frequently (e.g., every time pools are listed). Superb, thanks!!! I have opened a bug report now: Bug 230704: All the memory eaten away by ZFS 'solaris' malloc https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230704 Mark ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
