Re: installing 7.0-release from .isos: endless mfi status msgs on console
FreeBSD wrote: Jacob Yocom-Piatt a écrit : am setting up a new fileserver on a poweredge 1950 and installing from the freebsd 7.0-release .isos but can't read anything on the console since the PERC 5/i or 5/e card(s) are dumping status messages to the console non-stop (~1000 lines / minute). What are exactly those messages? I have the same server with FreeBSD 7.0-Release too and I don't get any annoying messages. I would be tempted to say that there is something wrong... martin, they are status messages of some sort that are coming from the two PERC cards installed in the machine, a 5/i for the SAS disks inside it and a 5/e for the MD1000 disk array attached to it via a SAS cable. since i don't have a console attached at this machine's location, i can't easily dump the messages here. suffice it to say that i get similar messages on my other freebsd fileserver running on essentially the same hardware (amd64 on poweredge 1950 + MD1000 enclosure). if you really want to see them, i can acquire them from the console whenever i reboot the machine but only after i have the console reading out. if i wait 5-10 minutes, the messages 'settle' and the installer gets further along, but the amd64 installer seizes whereas the i386 one gets to the usual install menu, i.e. 'choose your country', etc. if the amd64 installer is seizing up, can anyone recommend a workaround? i'm not about to install a 32-bit arch onto this machine since it needs to do ZFS which is known to have additional problems with 32-bit arches. cheers, jake Martin is there any way to disable these status messages so that i can get freebsd installed? AFAICT there is nothing broken with the battery on either of the PERC 5/i or 5/e cards installed. cheers, jake ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
installing 7.0-release from .isos: endless mfi status msgs on console
am setting up a new fileserver on a poweredge 1950 and installing from the freebsd 7.0-release .isos but can't read anything on the console since the PERC 5/i or 5/e card(s) are dumping status messages to the console non-stop (~1000 lines / minute). is there any way to disable these status messages so that i can get freebsd installed? AFAICT there is nothing broken with the battery on either of the PERC 5/i or 5/e cards installed. cheers, jake ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ssh + kerberos: problems w/ -current to openbsd 4.2 KDC
have most of the machines here doing ssh authentication via kerberos against a heimdal KDC running openbsd 4.2-release. the freebsd 7.0beta4 host i recently installed will not allow machines to ssh into it using kerberos credentials but it (freebsd host) does successfully get and use tickets from the KDC when [gssapi] correct_des3_mic = host/[EMAIL PROTECTED] is added to /etc/krb5.conf. nothing notable shows up in the KDC logs and the following appears in /var/log/auth.log on the freebsd host: Dec 31 12:46:48 databank1 sshd[24658]: error: ssh_msg_send: write Dec 31 12:50:14 databank1 sshd[24690]: error: ssh_msg_send: write the changes made on the freebsd host to accommodate kerberos authentication were in /etc/ssh/sshd_config and /etc/pam.d/sshd, respectively: KerberosAuthentication yes KerberosOrLocalPasswd yes KerberosTicketCleanup yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes authsufficient pam_krb5.so no_warn try_first_pass account requiredpam_krb5.so passwordsufficient pam_krb5.so no_warn try_first_pass where the lines in /etc/pam.d/sshd were simply uncommented and in the original order. debugging outputs from a client trying to ssh into the freebsd host are not very enlightening: ... debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive debug1: Next authentication method: gssapi-with-mic debug1: Delegating credentials debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive debug1: Next authentication method: publickey ... any clues as to what needs to be done to get this to work correctly would be appreciated. cheers, jake -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: zfs-geli-zfs: opinions/suggestions
Hugo Silva wrote: Jacob Yocom-Piatt wrote: lo all, have a freebsd 7.0-beta4 machine attached to an external disk enclosure and would like feedback on the following setup: have RAID-Z on 4 disks, ZFS volume that takes up entire RAID-Z, use ZVOL from volume for encryption via geli, use .eli (decrypted) device to make another ZFS pool. the idea being "no time/resources wasted doing fscks plus encryption sans hardware RAID". Unless I'm misunderstanding your objective, geli'ing the disks and creating a pool ontop of the encrypted disks (zpool create secure raidz da0.eli da1.eli da2.eli da3.eli) would also work, and would be far easier to maintain. Your data would still be encrypted and you would still need to provide the passphrase to make the pool accessible. this is a fine idea and removes a ZFS layer but i expect it will require a short sh script (read input and pipe into loop over disks) unless i want to enter a passphrase per disk. if anybody's already got such a script, would be nice to have since my script skills are kinda weak. will geli each of the disks and test it out to see if it is more stable than the original config. thanks for your input, hugo! cheers, jake Best regards, Hugo translated to commands this reads: # zpool create p_a raidz /dev/mfid1 /dev/mfid2 /dev/mfid3 /dev/mfid4 # zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT p_a2.72T 4.02G 2.71T 0% ONLINE - # zfs create -V 2048g p_a/vol # geli init -K /root/p_a.key -s 4096 -l 256 /dev/zvol/p_a/vol # geli attach -k /root/p_a.key /dev/zvol/p_a/vol # zpool create a /dev/zvol/p_a/vol.eli i got a reboot while scp-ing some files to /a (only got ~3 GB in) from another machine with the above setup. am currently waiting far too long for a rm -R to complete under /a. will test if any of this behavior is repeatable. i welcome opinions or suggestions on the stability of such a setup (ZFS-geli-ZFS) and if this is not stable, as the reboot i just experienced would indicate, suggestions on alternative configurations that allow use of geli and minimize or eliminate fsck time. i do have a preference for no hardware RAID since it ties us to a particular card. will furnish a proper bug report if the reboots are repeatable in the aforementioned scenario. NOTE: please CC me since i am not yet subscribed to this list cheers, jake ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
zfs-geli-zfs: opinions/suggestions
lo all, have a freebsd 7.0-beta4 machine attached to an external disk enclosure and would like feedback on the following setup: have RAID-Z on 4 disks, ZFS volume that takes up entire RAID-Z, use ZVOL from volume for encryption via geli, use .eli (decrypted) device to make another ZFS pool. the idea being "no time/resources wasted doing fscks plus encryption sans hardware RAID". translated to commands this reads: # zpool create p_a raidz /dev/mfid1 /dev/mfid2 /dev/mfid3 /dev/mfid4 # zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT p_a2.72T 4.02G 2.71T 0% ONLINE - # zfs create -V 2048g p_a/vol # geli init -K /root/p_a.key -s 4096 -l 256 /dev/zvol/p_a/vol # geli attach -k /root/p_a.key /dev/zvol/p_a/vol # zpool create a /dev/zvol/p_a/vol.eli i got a reboot while scp-ing some files to /a (only got ~3 GB in) from another machine with the above setup. am currently waiting far too long for a rm -R to complete under /a. will test if any of this behavior is repeatable. i welcome opinions or suggestions on the stability of such a setup (ZFS-geli-ZFS) and if this is not stable, as the reboot i just experienced would indicate, suggestions on alternative configurations that allow use of geli and minimize or eliminate fsck time. i do have a preference for no hardware RAID since it ties us to a particular card. will furnish a proper bug report if the reboots are repeatable in the aforementioned scenario. NOTE: please CC me since i am not yet subscribed to this list cheers, jake -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"