Re: mod_auth_kerb2 broken in 8-STABLE? Or is it heimdal to blame?
On 02/10/2012 02:08, George Mamalakis wrote:
> On 04/07/11 14:08, George Mamalakis wrote:
>> On 06/04/2011 18:29, George Mamalakis wrote:
>>> Dear all,
>>>
>>> I installed mod_auth_kerb2 on my FreeBSD 8-STABLE machine and tried
>>> to use it. After the installation (which was successful(?!?)), the
>>> server refused to start giving the error:
>>>
>>> # /usr/local/etc/rc.d/apache22 start
>>> Performing sanity check on apache22 configuration:
>>> httpd: Syntax error on line 103 of
>>> /usr/local/etc/apache22/httpd.conf: Cannot load
>>> /usr/local/libexec/apache22/mod_auth_kerb.so into server:
>>> /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
>>> "gsskrb5_register_acceptor_identity"
>>> Starting apache22.
>>> httpd: Syntax error on line 103 of
>>> /usr/local/etc/apache22/httpd.conf: Cannot load
>>> /usr/local/libexec/apache22/mod_auth_kerb.so into server:
>>> /usr/local/libexec/apache22/mod_auth_kerb.so: Undefined symbol
>>> "gsskrb5_register_acceptor_identity"
>>> /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
>>>
>>> but ldd showed:
>>>
>>> # ldd /usr/local/libexec/apache22/mod_auth_kerb.so
>>> /usr/local/libexec/apache22/mod_auth_kerb.so:
>>> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800c0)
>>> libheimntlm.so.10 => /usr/lib/libheimntlm.so.10 (0x800d0a000)
>>> libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x800e0f000)
>>> libhx509.so.10 => /usr/lib/libhx509.so.10 (0x800f7e000)
>>> libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8010be000)
>>> libcrypto.so.6 => /lib/libcrypto.so.6 (0x8011c)
>>> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x801461000)
>>> libroken.so.10 => /usr/lib/libroken.so.10 (0x8015e3000)
>>> libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016f5000)
>>> libc.so.7 => /lib/libc.so.7 (0x800647000)
>>>
>>> which showed that everything should have been fine. I googled it a
>>> bit and found this thread regarding my error message:
>>> http://forum.nginx.org/read.php?23,88476 , which started on May 2010,
>>> and pointed to this PR:
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=147454 , which started on
>>> June 2010. What is stated, is that heimdal-1.1 was broken in FreeBSD,
>>> and that it should be fixed at some moment in the future. (I tested
>>> mod_auth_kerb2 on another machine running heimdal from ports (1.4_1)
>>> and I had exactly the same problem).
>>>
>>> I searched to find where this notorious function
>>> (gsskrb5_register_acceptor_identity) was located, and I found its
>>> declaration in: /usr/include/gssapi/gssapi_krb5.h, and its definition
>>> in: /usr/lib/libgssapi_krb5.so.
>>>
>>> So, I added -lgssapi_krb5 in KRB5_LDFLAGS variable of
>>> /usr/ports/www/mod_auth_kerb2/work/mod_auth_kerb-5.4/Makefile , since
>>> this where the location of gsskrb5_register_acceptor_identity
>>> originally seemed to be, and reinstalled the port using gmake this
>>> time (inside the port's work directory). After that, the module works
>>> just fine. The initial content of this line was:
>>>
>>> KRB5_LDFLAGS = -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509
>>> -lcom_err -lcrypto -lasn1 -lroken -lcrypt
>>>
>>> I've sent an analogous email to the port maintainer, but I am not
>>> sure if it is their "fault". Hence, I decided to send this email to
>>> the stable list for two reasons: First, someone else may be having a
>>> similar problem and wants to find a rough solution. Secondly, there
>>> are people reading this list that know heimdal's code, so somebody
>>> may know another (much more elegant) way to fix this bug.
>>>
>>> Thank you all for your time in advance,
>>>
>>> Regards,
>>>
>>> mamalos.
>>>
>>
>> OK,
>>
>> I spoke with the maintainer who confirmed the problem. He also
>> suggested to change line 96 of /usb/bin/krb5-config to include
>> gssapi_krb5 among its libraries. He also gave me the relevant patch,
>> and asked me to send a PR to FreeBSD. The patch is as follows:
>>
>> --- /usr/bin/krb5-config.orig 2011-02-17 03:18:57.0 +0100
>> +++ /usr/bin/krb5-config2011-04-06 23:41:31.0 +0200
>> @@ -93,7 +93,7 @@
>> lib_flags="-L${libdir}"
>> case $library in
>> gssapi)
>> - lib_flags="$lib_flags -lgssapi -lheimntlm"
>> + lib_flags="$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm"
>> ;;
>> kadm-client)
>> lib_flags="$lib_flags -lkadm5clnt"
>>
>>
>>
>> And the relevant PR is:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=156245
>>
>> Thank you all for your time,
>>
>> mamalos
>>
> Hi all,
>
> I am bringing this matter back again because the same things hold for my
> current system too (/usr/bin/krb5-config does not seem to link
> gssapi-things properly):
>
> # uname -a
> FreeBSD example.com 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jun 18
> 21:04:14 EEST 2012 r...@example.com:/usr/obj/usr/src/sys/FILESRV amd64
> # pkg_info -Ix apache kerb
> ap22-mod_auth_kerb-5.4_3 An Apache module for authenticating users with
> Kerberos v5
> apache22-2.2.22_8 Version 2.2
Re: Problem with IPMI KCS driver
On Thu, Oct 18, 2012 at 01:44:59PM +0400, Anton Yuzhaninov wrote:
| On 28.09.2012 16:48, John Baldwin wrote:
| >>kcs_wait_for_obf() at kcs_wait_for_obf+0xb6 point to
| >>> /usr/src/sys/dev/ipmi/ipmi_kcs.c:94
| >>>
| >>> 91 while (ticks - start< MAX_TIMEOUT&&
| >>> 92 !(status& KCS_STATUS_OBF)) {
| >>> 93 DELAY(100);
| >>> 94 status = INB(sc, KCS_CTL_STS);
| >>> 95 }
| >Hummm. I'm a bit out of ideas then. Even the volatile change is a bug
| >that
| >could have been confirmed (to see if volatile was preventing the compiler
| >from caching the value of 'ticks') by examining the assembly.
| >
| >Well, maybe this. This just avoids using 'ticks' altogether and depends on
| >DELAY(100) doing what it says:
|
| New patch also don't solve my problem.
|
| My guess was wrong. Loop in kcs_wait_for_obf() is not endless, at least
| with last patch.
| Whole function called in some loop, but because loop in kcs_wait_for_obf()
| takes much CPU time, backtrace always point to loop kcs_wait_for_obf().
Yep, the IPMI local interfaces are polled so they use a lot of CPU
so it pretty much always going to be checking "are you done yet"
once a command is submitted. We have local patches here that changes
the DELAY into a tsleep when the system is running. It has the bad
feature of making it a lot slower but uses far less CPU. So for us
it is a good trade off. One reason to put it into a loop is
so things happen in order and are not interrupted. I guess a different
approach might be to do a "big" lock around the entire submit and
get response code fargment. Then it would be expensed against the
application thread running in the kernel.
We also have local changes to all it to run in polled mode without
the kernel thread when we are dumping a kernel backtrace into the
IPMI system event log. That's nice when the kernel core hasn't
worked on a remote machine but we see the back trace in SEL.
| This problem need further investigation.
It might be good to instrument the code in ipmi.c in which it
sending a command and then getting status. If that is actually
looking okay then maybe some application is doing something bad.
Doug A.
___
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 9.1-RC2 Available...
Updated two 9.1-RC1 machines (both R210, dual GEOM MIRRORED disk) 1 went OK; 1 went belly up (see attachment) (after the 1st reboot) - Invalid format - BTX halted. Any ideas why ? (need to upgrade more machines without KVM access ) -AJ- ___ 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: Thinkpad X61s cannot boot 9.1-BETA1
On Sat, Sep 15, 2012 at 01:48:02PM +0200, Lars Engels wrote: > On Fri, Sep 14, 2012 at 03:15:04PM +0300, Andriy Gapon wrote: > > on 14/09/2012 11:17 Lars Engels said the following: > > > Here's are some more dmesgs: > > > > > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9.works # PCBSD 9.1-RC1 > > > successuful boot on AC power > > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works # FreeBSD 10-CURRENT > > > successful boot on battery > > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9_10.diff # Their diff > > > > > > > Is it possible to produce two verbose dmesgs for 10 - one on AC power and > > one on > > battery? > > I think that now you can complete booting in both cases. > > Yes, they're here: > > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10_i8254.works > http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10_eventtimer.diff > > It shows also that with i8254 I'm having USB problems. Any news here? There's another one who has this issue on a different notebook: http://www.freebsd.org/cgi/query-pr.cgi?pr=171193 pgpuw9afsB31h.pgp Description: PGP signature
Re: 9.1-RC2 - could it be that the installer does not write the MBR?
On 10/18/12 11:44, Rainer Duffner wrote: Am Thu, 18 Oct 2012 11:31:56 -0500 schrieb Chuck Burns : On 10/18/2012 11:05 AM, Brandon Allbery wrote: On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: Such question does not make sense if the disk is GPT partitioned which is the default now. The boot loader is installed on a separate freebsd-boot partition and the MBR of the disk contains a special "protective MBR". And what is supposed to happen if the disk has an existing MBR and existing partitions? Besides which.. Do you want FreeBSD to overwrite the MBR? Yes. I've long since given up on FreeBSD for workstations - I simply don't have the time to get everything right. Thus erasing grub when someone is attempting to install FreeBSD alongside Linux? How many people actually do that, now that there are so many virtualization-options? If you do not want GRUB, you must remove GRUB and revert to a proper MBR. And how do you remove GRUB? The original OS did no longer boot in my case Do I need to file a PR for this? Simply zero out first few MB of the drive, when you create a new partition map, a new MBR is created. Chuck ___ 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.1-RC2 - could it be that the installer does not write the MBR?
jb gmail.com> writes: > ... > I installed RC2 yesterday and noticed that there was no question asked where > to install boot loader (MBR or FB root slice/partition). > That's something needing a fix. > jb I filed a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/172847 jb ___ 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.1-RC2 - could it be that the installer does not write the MBR?
Am Thu, 18 Oct 2012 11:31:56 -0500 schrieb Chuck Burns : > On 10/18/2012 11:05 AM, Brandon Allbery wrote: > > On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala > > wrote: > > > >> Such question does not make sense if the disk is GPT partitioned > >> which is the default now. The boot loader is installed on a > >> separate freebsd-boot partition and the MBR of the disk contains a > >> special "protective MBR". > > > > > > And what is supposed to happen if the disk has an existing MBR and > > existing partitions? > > > > Besides which.. Do you want FreeBSD to overwrite the MBR? Yes. I've long since given up on FreeBSD for workstations - I simply don't have the time to get everything right. > Thus > erasing grub when someone is attempting to install FreeBSD alongside > Linux? How many people actually do that, now that there are so many virtualization-options? > If you do not want GRUB, you must remove GRUB and revert to a proper > MBR. And how do you remove GRUB? The original OS did no longer boot in my case Do I need to file a PR for this? ___ 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"
Fwd: Re: 9.1-RC2 - could it be that the installer does not write the MBR?
On 10/18/2012 11:05 AM, Brandon Allbery wrote: On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: Such question does not make sense if the disk is GPT partitioned which is the default now. The boot loader is installed on a separate freebsd-boot partition and the MBR of the disk contains a special "protective MBR". And what is supposed to happen if the disk has an existing MBR and existing partitions? With a -proper- existing MBR, it doesn't matter, since it will still pass boot off to the proper partition. But when you install an MBR partition manager that overrides the standard MBR code, you must also then uninstall it when you want to revert back to an OS that knows how to boot with a normal MBR. -- Chuck Burns -- Chuck Burns ___ 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.1-RC2 - could it be that the installer does not write the MBR?
On 10/18/2012 11:05 AM, Brandon Allbery wrote: On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: Such question does not make sense if the disk is GPT partitioned which is the default now. The boot loader is installed on a separate freebsd-boot partition and the MBR of the disk contains a special "protective MBR". And what is supposed to happen if the disk has an existing MBR and existing partitions? Besides which.. Do you want FreeBSD to overwrite the MBR? Thus erasing grub when someone is attempting to install FreeBSD alongside Linux? If you do not want GRUB, you must remove GRUB and revert to a proper MBR. -- Chuck Burns ___ 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.1-RC2 - could it be that the installer does not write the MBR?
On Thu, Oct 18, 2012 at 5:31 AM, Kimmo Paasiala wrote: > Such question does not make sense if the disk is GPT partitioned which > is the default now. The boot loader is installed on a separate > freebsd-boot partition and the MBR of the disk contains a special > "protective MBR". And what is supposed to happen if the disk has an existing MBR and existing partitions? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ 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: mpt irq timeout problem after reboot - only if non-verbose booting !?!
On Wednesday, October 17, 2012 3:14:52 pm Harald Schmalzbauer (mobil) wrote: > -Ursprüngliche Nachricht- > > Von: John Baldwin > > An: freebsd-stable@freebsd.org > > Cc: h.schmalzba...@omnilan.de > > Gesendet: 17.10.'12, 20:46 > > > > On Tuesday, October 16, 2012 5:24:44 am Harald Schmalzbauer wrote: > >> Hello, > >> > >> I have 9.1-RC2 running in an ESXi 5.1 guest. > >> I use 'lsisas' as virtual SCSI-Controller and mpt attaches and finds 1068E. > >> > >> Everything is working fine until the first 'shutdown -r now': > >> The second boot pauses for ~2 minutes after probing disks and continues > >> with this error: > >> mpt0: Timedout requests already complete. Interrupts may not be > >> functioning. > > > > To be clear, you only see this at the end of reboot, and the hardware is > > fine > > once the machine is back up? > . > > Thanks for your attention! > The timeout occurs after the first 'shutdown -r' while device probing during > second boot process. Perhaps this is amd64 specific. Today I had a new i386 > setup which doesn't exhibit this timeout. But it's on different hardware and > hv-host was 5.0 inestead 5.1. So not really representative... Hmmm, ok. In that case my patch is not relevant. It would only fix that message occuring during the shutdown. -- John Baldwin ___ 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.1-RC2 ixgbe lagg problems
Hi, what fbsd version... what uname -a shows, what driver version do you have? Sami On Wed, Oct 17, 2012 at 8:48 PM, Garrett Wollman < woll...@hergotha.csail.mit.edu> wrote: > In article > , > wynnwil...@gmail.com writes: > > >I've tried the 2.4.4 driver from Intel's site, but it still has the > >same problems. Is a lagg using lacp with the ix interfaces working for > >anyone else? > > You bet. > > lagg0: flags=8943 > metric 0 mtu 9120 > > options=401bb > ether 04:7d:7b:a5:88:f0 > inet 128.30.3.34 netmask 0xff00 broadcast 128.30.3.255 > nd6 options=29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: ix1 flags=1c > laggport: ix0 flags=1c > > Configured with: > > cloned_interfaces="lagg0" > ifconfig_ix0="mtu 9120 up" > ifconfig_ix1="mtu 9120 up" > ifconfig_lagg0="laggproto lacp laggport ix0 laggport ix1" > ipv4_addrs_lagg0="128.30.x.x/24" > > -GAWollman > > ___ > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ 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: Problem with IPMI KCS driver
On 28.09.2012 16:48, John Baldwin wrote:
kcs_wait_for_obf() at kcs_wait_for_obf+0xb6 point to
> /usr/src/sys/dev/ipmi/ipmi_kcs.c:94
>
> 91 while (ticks - start< MAX_TIMEOUT&&
> 92 !(status& KCS_STATUS_OBF)) {
> 93 DELAY(100);
> 94 status = INB(sc, KCS_CTL_STS);
> 95 }
Hummm. I'm a bit out of ideas then. Even the volatile change is a bug that
could have been confirmed (to see if volatile was preventing the compiler
from caching the value of 'ticks') by examining the assembly.
Well, maybe this. This just avoids using 'ticks' altogether and depends on
DELAY(100) doing what it says:
New patch also don't solve my problem.
My guess was wrong. Loop in kcs_wait_for_obf() is not endless, at least with
last patch.
Whole function called in some loop, but because loop in kcs_wait_for_obf() takes
much CPU time, backtrace always point to loop kcs_wait_for_obf().
This problem need further investigation.
--
Anton Yuzhaninov
___
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.1-RC2 - could it be that the installer does not write the MBR?
On Thu, Oct 18, 2012 at 11:05 AM, jb wrote: > Brandon Allbery gmail.com> writes: > >> >> On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner > ultra-secure.de>wrote: >> >> > I tried to install 9.1-RC2 amd64 on two disks that previously had some >> > version of Solaris installed (with grub as boot-manager). >> > The installation would always be successful, but it would just boot to >> > grub and then sit there. >> > >> >> RC1 wasn't very good at it either. >> > > I installed RC2 yesterday and noticed that there was no question asked where > to install boot loader (MBR or FB root slice/partition). > That's something needing a fix. > jb > > > > Such question does not make sense if the disk is GPT partitioned which is the default now. The boot loader is installed on a separate freebsd-boot partition and the MBR of the disk contains a special "protective MBR". ___ 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.1-RC2 - could it be that the installer does not write the MBR?
Brandon Allbery gmail.com> writes: > > On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner ultra-secure.de>wrote: > > > I tried to install 9.1-RC2 amd64 on two disks that previously had some > > version of Solaris installed (with grub as boot-manager). > > The installation would always be successful, but it would just boot to > > grub and then sit there. > > > > RC1 wasn't very good at it either. > I installed RC2 yesterday and noticed that there was no question asked where to install boot loader (MBR or FB root slice/partition). That's something needing a fix. jb ___ 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: daily run output misses zpool errors
On Wed, 03 Oct 2012 22:01:49 +0200, Alexander Leidinger wrote: On Tue, 25 Sep 2012 14:56:49 +0200 "Ronald Klop" wrote: Hi, Below my daily report. And here my zpool status -x. It would be nice to see this error in my daily info. I am running with daily_show_info="NO", but this looks more severe than info. Just to make sure: you verified that you have daily_status_zfs_enable=YES in periodic.conf? In the daily mail you provided I've seen several headings without content, but I haven't seen the "Checking status of zfs pools:" part which is supposed to show up when the zfs stats script is run. Bye, Alexander. Yes. My point is that as long as the pool is healthy the daily e-mail tells me that and when the pool is unhealthy it does not show me any info. I setup a test to reproduce this. I broke a mirror by dd-ing /dev/random over one of the md backing files. $ cat /etc/periodic.conf daily_show_info="NO" weekly_show_info="NO" monthly_show_info="NO" daily_status_zfs_enable="YES" daily_scrub_zfs_enable="YES" daily_status_smart_devices="AUTO" daily_clean_hoststat_enable="NO" daily_status_mail_rejects_enable="NO" daily_status_include_submit_mailq="NO" daily_submit_queuerun="NO" $ zpool status test pool: test state: ONLINE status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-4J scan: scrub repaired 0 in 0h0m with 0 errors on Wed Oct 17 14:26:43 2012 config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 mirror-0ONLINE 0 0 0 md0 ONLINE 0 0 0 18290078248358455968 UNAVAIL 0 0 0 was /dev/md1 errors: No known data errors The daily mail before I broke the pool: - Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: /etc/group is fine Backing up package db directory: Rotating accounting logs and gathering statistics: Checking status of zfs pools: NAME SIZE ALLOC FREECAP DEDUP HEALTH ALTROOT extern 298G 161G 137G54% 1.00x ONLINE - tank 292G 215G 77.2G73% 1.00x ONLINE - test95.5M 5.32M 90.2M 5% 1.00x ONLINE - all pools are healthy Network interface status: NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll Drop em01500 00:21:70:46:6c:da 427203 0 0 321583 0 00 em01500 192.168.1.0 sjakie.home 368631 - - 322492 - -- em01500 192.168.1.36/ 192.168.1.36 64146 - - 0 - -- usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 usbus 00 0 0 0 0 00 lo0 16384 20857 0 0 20857 0 00 lo0 16384 localhost ::1 0 - - 0 - -- lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - -- lo0 16384 your-net localhost 34 - - 20857 - -- ipfw0 65536 0 0 0 0 0 00 Security check: (output mailed separately) Checking for denied zone transfers (AXFR and IXFR): Scrubbing of zfs pools: skipping scrubbing of pool 'extern': last scrubbing is 20 days ago, threshold is set to 35 days skipping scrubbing of pool 'tank': last scrubbing is 4 days ago, threshold is set to 35 days skipping scrubbing of pool 'test': last scrubbing is 0 days ago, threshold is set to 35 days -- End of daily output -- The daily mail after I broke the pool: - Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: /etc/group is fine Backing up package db directory: Rotating accounting logs and g
