zpool on a zvol inside zpool
Hi. I'm moving some of my geli installation to a new machine. On an old machine it was running UFS. I use ZFS on a new machine, but I don't have an encrypted main pool (and I don't want to), so I'm kinda considering a way where I will make a zpool on a zvol encrypted by geli. Would it be completely insane (should I use UFS instead ?) or would it be still valid ? Thanks. Eugene. ___ 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
stopping amd causes a freeze
Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. # uname -a FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r253413: Wed Jul 17 13:12:46 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-91/amd64/usr/src/sys/HP6510b-91 amd64 That's amd's starting message: Jul 22 11:32:28 mobileKamikaze amd[8176]/info: no logfile defined; using stderr Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AM-UTILS VERSION INFORMATION: Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1997-2006 Erez Zadok Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 Jan-Simon Pendry Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 Imperial College of Science, Technology Medicine Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 The Regents of the University of California. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: am-utils version 6.1.5 (build 901505). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Report bugs to https://bugzilla.am-utils.org/ or am-ut...@am-utils.org. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Configured by David O'Brien obr...@freebsd.org on date 4-December-2007 PST. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Built by root@mobileKamikaze.norad. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: cpu=amd64 (little-endian), arch=amd64, karch=amd64. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: full_os=freebsd9.2, os=freebsd9, osver=9.2, vendor=undermydesk, distro=The FreeBSD Project. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: domain=norad, host=mobileKamikaze, hostd=mobileKamikaze.norad. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Map support for: root, passwd, union, nis, ndbm, file, exec, error. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, ufs, cdfs, Jul 22 11:32:28 mobileKamikaze amd[8176]/info:pcfs, auto, direct, toplvl, error, inherit. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: FS: cd9660, nfs, nfs3, nullfs, msdosfs, ufs, unionfs. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 1: wire=192.168.1.0 (netnumber=192.168.1). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 2: wire=192.168.0.0 (netnumber=192.168). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: My ip addr is 127.0.0.1 amd is called with the flags -r -p -a -c 4 -w 2 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: stopping amd causes a freeze
On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. Are you sure that the machine did not paniced ? Do you have serial console ? The amd(8) locks itself into memory, most likely due to the fear of deadlock. There are some known issues with user wirings in stable/9. If the problem you see is indeed due to wiring, you might try to apply r253187-r253191. pgpsPkzdjccIf.pgp Description: PGP signature
Re: zpool on a zvol inside zpool
Am 22.07.2013 10:04, schrieb Eugene M. Zheganin: Hi. I'm moving some of my geli installation to a new machine. On an old machine it was running UFS. I use ZFS on a new machine, but I don't have an encrypted main pool (and I don't want to), so I'm kinda considering a way where I will make a zpool on a zvol encrypted by geli. Would it be completely insane (should I use UFS instead ?) or would it be still valid ? I have configured a system in just that way, a few weeks ago. It seems to work just fine. This is a workgroup server for a small company, which is meant to provide secure storage for documents. The system has a separate boot/root pool and a large pool for data (both as ZFS mirrors). On the data pool there is a ZVOL which is GELI encrypted to provide a disk for the encrypted ZFS that holds the documents. The system is running headless in some datacenter. It must boot multi-user and start a SSHD for remote entry of the passphrase, therefore solutions where a GELI key is on a USB key or entered via a console during boot were not possible. Performance is reasonable and far exceeds the 100Mbit/s Ethernet port ordered in the data-center, so I did not bother to measure throughput of this ZFS on GELI encrypted ZPOOL. For low load scenarios, this seems to be the easiest configuration. If you have hardware crypto or expect high load, then a ZFS mirror of GELI encrypted disks may show better performance, though. Regards, STefan ___ 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
Current problem reports assigned to freebsd-stable@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o i386/179112 stable 9.1 installer panics with a kmem_malloc() failure on i 1 problem total. ___ 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: stopping amd causes a freeze
On 22/07/2013 12:07, Konstantin Belousov wrote: On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. Are you sure that the machine did not paniced ? Do you have serial console ? No, I don't have one. All that I can tell is that everything freezes (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a reaction. And the system doesn't respond to ICMP queries. The amd(8) locks itself into memory, most likely due to the fear of deadlock. There are some known issues with user wirings in stable/9. If the problem you see is indeed due to wiring, you might try to apply r253187-r253191. From head? That may be worth a try. It would be better for testing if I managed to reproduce the problem reliably, before I test patches. I see it's scheduled for MFC, soon. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: stopping amd causes a freeze
On Mon, 22 Jul 2013 14:19:44 +0200, Dominic Fandrey kamik...@bsdforen.de wrote: On 22/07/2013 12:07, Konstantin Belousov wrote: On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. Are you sure that the machine did not paniced ? Do you have serial console ? No, I don't have one. All that I can tell is that everything freezes (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a reaction. And the system doesn't respond to ICMP queries. The amd(8) locks itself into memory, most likely due to the fear of deadlock. There are some known issues with user wirings in stable/9. If the problem you see is indeed due to wiring, you might try to apply r253187-r253191. From head? That may be worth a try. It would be better for testing if I managed to reproduce the problem reliably, before I test patches. I see it's scheduled for MFC, soon. Did you try a run with the INVARIANTS, etc. options in the kernel? That enables more sanity checking for locks which is too slow for production. Ronald. ___ 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: stopping amd causes a freeze
On 22/07/2013 14:35, Ronald Klop wrote: On Mon, 22 Jul 2013 14:19:44 +0200, Dominic Fandrey kamik...@bsdforen.de wrote: On 22/07/2013 12:07, Konstantin Belousov wrote: On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. Are you sure that the machine did not paniced ? Do you have serial console ? No, I don't have one. All that I can tell is that everything freezes (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a reaction. And the system doesn't respond to ICMP queries. The amd(8) locks itself into memory, most likely due to the fear of deadlock. There are some known issues with user wirings in stable/9. If the problem you see is indeed due to wiring, you might try to apply r253187-r253191. From head? That may be worth a try. It would be better for testing if I managed to reproduce the problem reliably, before I test patches. I see it's scheduled for MFC, soon. Did you try a run with the INVARIANTS, etc. options in the kernel? That enables more sanity checking for locks which is too slow for production. No I didn't, but I managed to reproduce it in combination with heavy tmpfs load. So now I've got a working test case and will be able to determine whether the suggested fix works. I suppose INVARIANTS would be the next step. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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 9.2-BETA1 now available
The first BETA build of the 9.2-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and ia64 architectures. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.2/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use stable/9. Please be aware that cvsup and CVS are both deprecated, and are not supported methods of updating the src/ tree. Important note to freebsd-update(8) users: Due to a last minute problem found in the 9.2-BETA1 freebsd-update(8) builds, freebsd-update(8) is NOT supported for 9.2-BETA1 upgrades. Please do not use freebsd-update(8) to upgrade to 9.2-BETA1. Checksums: amd64: SHA256 (FreeBSD-9.2-BETA1-amd64-bootonly.iso) = b458c7080d9b8938e50def7c4ee296fda656ad41a25b41af05963872733bd550 SHA256 (FreeBSD-9.2-BETA1-amd64-disc1.iso) = 4593581e7e3dc066170ed4f5f228082317f7284737e5834e1d0c2da2d58c4532 SHA256 (FreeBSD-9.2-BETA1-amd64-memstick.img) = 6cff61f5d6074286757d6f8f0160c051f15c1e970f7ff9187603afad92993a84 MD5 (FreeBSD-9.2-BETA1-amd64-bootonly.iso) = 504f8709da876df27388c2bac1eeb1e1 MD5 (FreeBSD-9.2-BETA1-amd64-disc1.iso) = 06b2150ba9c83496acb74e7b15392f41 MD5 (FreeBSD-9.2-BETA1-amd64-memstick.img) = a308cfb3d409a6806e974e5394e9740f i386: SHA256 (FreeBSD-9.2-BETA1-i386-bootonly.iso) = ae8393fdeea97be1abe29a3119349360b1c1f896a736b715c256b0e59972bbb1 SHA256 (FreeBSD-9.2-BETA1-i386-disc1.iso) = 3eff3de4f245237970b743bbc85eaa4f6ce65d7ecbe9d5b96f2e19c11e9f0e81 SHA256 (FreeBSD-9.2-BETA1-i386-memstick.img) = a934ded850fba472a10b2e869a02d717a041a6771398958e82400dcb6c0bd6d7 MD5 (FreeBSD-9.2-BETA1-i386-bootonly.iso) = 58f6be4a3edb9235bf81cef4bb9d0a8e MD5 (FreeBSD-9.2-BETA1-i386-disc1.iso) = aac3a0ad51a9cc4b5f003616effd73f5 MD5 (FreeBSD-9.2-BETA1-i386-memstick.img) = e0d8c8139dcf1eae1eb6a33d58c4dd7f ia64: SHA256 (FreeBSD-9.2-BETA1-ia64-bootonly.iso) = 88b3350e4bbd522855029b4ece284a5ffb363be098c7d08d9b4006917e4474a4 SHA256 (FreeBSD-9.2-BETA1-ia64-disc1.iso) = fd401b1f7f9bf301a72d2bd03c8a83d6aa5d1f2e037370968ca6af0577e7d9b4 SHA256 (FreeBSD-9.2-BETA1-ia64-memstick.img) = dac5a9f712cb46fffcfd2f8db7fe4e50848f5401a9b9841cf8e533a7996350d3 MD5 (FreeBSD-9.2-BETA1-ia64-bootonly.iso) = fb1e4d7ce557b22564bb788d5bd0540f MD5 (FreeBSD-9.2-BETA1-ia64-disc1.iso) = b1fbe310909e5c6f9bb8315b24a7f00b MD5 (FreeBSD-9.2-BETA1-ia64-memstick.img) = a71c2ef0f5ccfe6b3f015f1a79129ad4 Glen pgpW5lzEMAUls.pgp Description: PGP signature
Re: zpool on a zvol inside zpool
On 22/07/2013 19:54, Stefan Esser wrote: Am 22.07.2013 10:04, schrieb Eugene M. Zheganin: Hi. I will make a zpool on a zvol encrypted by geli. I have configured a system in just that way, a few weeks ago. It seems to work just fine. It sounds like a fix may exist in head but if you want to use snapshots you may want to read kern/161968 first ___ 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
[REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel
I have a KERNCONF that previously had PS/2 support compiled into the kernel. If I comment out the following lines like so: # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard then I'm able to mount root again (it was failing with ENOXDEV). The working kernel was as follows: $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA gcc version 4.2.1 20070831 patched [FreeBSD] FreeBSD 9.1-STABLE BAYONETTA $ cd /usr/src; git log 0304216 commit 03042167f73c213732b44218a24d8e1bbea00f8c Merge: 2edcad2 974abfb Author: Garrett Cooper yaneg...@gmail.com Date: Mon Jun 24 19:00:45 2013 -0700 Merge remote-tracking branch 'upstream/stable/9' into stable/9 The working kernel [with atkbdc] was as follows: FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA amd64 $ git log c178034 commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 Author: avg a...@freebsd.org Date: Tue Jul 9 08:30:31 2013 + zfsboottest.sh: remove checks for things that are not strictly required MFC after: 10 days (Yes, I had to backport some things because they are busted on stable/9 due to other incomplete/missing MFCs). I can test out patches, but I don't have time to bisect the actual commit that caused the failure. That being said my intuition says it's this commit should be looked at first: commit 28f961058b0667841d7e9d8639bfd02ed8689faa Author: jhb j...@freebsd.org Date: Wed Jul 17 14:04:18 2013 + MFC 252576: Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Approved by:re (marius) More data spew follows. Thanks, -Garrett hostb0@pci0:0:0:0: class=0x06 card=0x836b1043 chip=0x34058086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub to ESI Port' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x836b1043 chip=0x34088086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 1' class = bridge subclass = PCI-PCI pcib4@pci0:0:3:0: class=0x060400 card=0x836b1043 chip=0x340a8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 3' class = bridge subclass = PCI-PCI pcib5@pci0:0:7:0: class=0x060400 card=0x836b1043 chip=0x340e8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 7' class = bridge subclass = PCI-PCI none0@pci0:0:20:0: class=0x08 card=0x chip=0x342e8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub System Management Registers' class = base peripheral subclass = interrupt controller none1@pci0:0:20:1: class=0x08 card=0x chip=0x34228086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers' class = base peripheral subclass = interrupt controller none2@pci0:0:20:2: class=0x08 card=0x chip=0x34238086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub Control Status and RAS Registers' class = base peripheral subclass = interrupt controller none3@pci0:0:20:3: class=0x08 card=0x chip=0x34388086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub Throttle Registers' class = base peripheral subclass = interrupt controller uhci0@pci0:0:26:0: class=0x0c0300 card=0x82d41043 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x82d41043 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus
ZFS: can't read MOS of pool
Hi, I've got a problem with booting zfs-on-root FreeBSD 9.2-PRERELEASE. I'm getting: ZFS: i/o error - all block copies unavailable ZFS: can't read MOS of pool klawisz gptzfsboot: failed to mount default pool klawisz Machine is VM running under KVM on Proxmox 2.3-13. VM has 8 GB of RAM, 400 GB of local storage with SCSI Controller type: Default (lsi). I'm not sure what I did to make this VM unbootable. I've installed 9.2-PRERELEASE, did source based upgrade to r253470, mergemaster, reinstalled bootcode and rebooted. To this point VM was bootable. Then I did installworld from /usr/src to ezjail's basejail (ezjail-admin update -i), did mergemaster for jails, install some ports - none of this should mess with booting. I rebooted VM and got unbootable system. When I boot from liveCD I can import this pool (scrub shows no errors), mount it, chroot to it, and work with it. I just can't get it to boot. Some information about the system: http://pastie.org/private/mtfhkx0wx0vve29xn0plw I've tried to downgrade to r252316 - no luck, system is still unbootable. Any hints how to go from here? -- best regards, Lukasz Wasikowski ___ 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: zpool on a zvol inside zpool
On 22-07-2013 10:04, Eugene M. Zheganin wrote: Hi. I'm moving some of my geli installation to a new machine. On an old machine it was running UFS. I use ZFS on a new machine, but I don't have an encrypted main pool (and I don't want to), so I'm kinda considering a way where I will make a zpool on a zvol encrypted by geli. Would it be completely insane (should I use UFS instead ?) or would it be still valid ? Hello, I've used this setup for a while on several servers, it works but it is slow. I am migrating my servers to have two zpools instead, a small one with the base system and nothing else, the other one on top of a geli device. This performs much better and is IMO a better solution. YMMV :) I have this method documented on my wiki here: http://wiki.tyk.nu/index.php?title=Ezjail_host#Further_disk_configuration Best regards, Thomas Steen Rasmussen ___ 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: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel
On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: I have a KERNCONF that previously had PS/2 support compiled into the kernel. If I comment out the following lines like so: # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard then I'm able to mount root again (it was failing with ENOXDEV). The working kernel was as follows: $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA gcc version 4.2.1 20070831 patched [FreeBSD] FreeBSD 9.1-STABLE BAYONETTA $ cd /usr/src; git log 0304216 commit 03042167f73c213732b44218a24d8e1bbea00f8c Merge: 2edcad2 974abfb Author: Garrett Cooper yaneg...@gmail.com Date: Mon Jun 24 19:00:45 2013 -0700 Merge remote-tracking branch 'upstream/stable/9' into stable/9 The working kernel [with atkbdc] was as follows: FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA amd64 $ git log c178034 commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 Author: avg a...@freebsd.org Date: Tue Jul 9 08:30:31 2013 + zfsboottest.sh: remove checks for things that are not strictly required MFC after: 10 days (Yes, I had to backport some things because they are busted on stable/9 due to other incomplete/missing MFCs). I can test out patches, but I don't have time to bisect the actual commit that caused the failure. That being said my intuition says it's this commit should be looked at first: commit 28f961058b0667841d7e9d8639bfd02ed8689faa Author: jhb j...@freebsd.org Date: Wed Jul 17 14:04:18 2013 + MFC 252576: Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Approved by:re (marius) I strongly doubt that this is related. It would be most helpful if you could obtain a dmesg from the new kernel however (perhaps via a serial console) to rule it out. All you would need to see is if the new kernel sees more pcib devices than the old one to see if this change even has an effect on your system. -- 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: [REGRESSION] Root zpool mounting broken between 06/30/2013 and 07/21/2013 when PS/2 support compiled into the kernel
On Jul 22, 2013, at 9:08 AM, John Baldwin j...@freebsd.org wrote: On Monday, July 22, 2013 10:30:32 am Garrett Cooper wrote: I have a KERNCONF that previously had PS/2 support compiled into the kernel. If I comment out the following lines like so: # atkbdc0 controls both the keyboard and the PS/2 mouse #device atkbdc # AT keyboard controller #device atkbd # AT keyboard then I'm able to mount root again (it was failing with ENOXDEV). The working kernel was as follows: $ strings /boot/kernel.WORKING/kernel | grep -B 2 -A 2 BAYONETTA @(#)FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 FreeBSD 9.1-STABLE #7 r+0304216: Sun Jun 30 15:22:55 PDT 2013 gcooper@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA gcc version 4.2.1 20070831 patched [FreeBSD] FreeBSD 9.1-STABLE BAYONETTA $ cd /usr/src; git log 0304216 commit 03042167f73c213732b44218a24d8e1bbea00f8c Merge: 2edcad2 974abfb Author: Garrett Cooper yaneg...@gmail.com Date: Mon Jun 24 19:00:45 2013 -0700 Merge remote-tracking branch 'upstream/stable/9' into stable/9 The working kernel [with atkbdc] was as follows: FreeBSD bayonetta.local 9.2-BETA1 FreeBSD 9.2-BETA1 #12 r+c178034: Sun Jul 21 20:19:38 PDT 2013 root@bayonetta.local:/usr/obj/scratch/git/github/yaneurabeya-freebsd-stable-9/sys/BAYONETTA amd64 $ git log c178034 commit c17803445f4ffb97e1a46a1be5f7ea04692793f0 Author: avg a...@freebsd.org Date: Tue Jul 9 08:30:31 2013 + zfsboottest.sh: remove checks for things that are not strictly required MFC after: 10 days (Yes, I had to backport some things because they are busted on stable/9 due to other incomplete/missing MFCs). I can test out patches, but I don't have time to bisect the actual commit that caused the failure. That being said my intuition says it's this commit should be looked at first: commit 28f961058b0667841d7e9d8639bfd02ed8689faa Author: jhb j...@freebsd.org Date: Wed Jul 17 14:04:18 2013 + MFC 252576: Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Approved by:re (marius) I strongly doubt that this is related. It would be most helpful if you could obtain a dmesg from the new kernel however (perhaps via a serial console) to rule it out. All you would need to see is if the new kernel sees more pcib devices than the old one to see if this change even has an effect on your system. Unfortunately the USB keyboard is broken as well at the mount root prompt and the workstation doesn't have a uart on it that I can play with (it's my home box), so I'm dead in the water when it panics at the mount root prompt right now. I guess I can revert this and a handful of other amd64/ata_cam/zfs commits to see if this goes away, but I won't be getting to that before next Sunday probably as this is my file server and DNS server now. Thanks! ___ 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: stopping amd causes a freeze
On Mon, Jul 22, 2013 at 2:50 AM, Dominic Fandrey kamik...@bsdforen.dewrote: Occasionally stopping amd freezes my system. It's a rare occurrence, and I haven't found a reliable way to reproduce it. It's also a real freeze, so there's no way to get into the debugger or grab a core dump. I only can perform the 4 seconds hard shutdown to revive the system. I run amd through sysutils/automounter, which is a scripting solution that generates an amd.map file based on encountered devices and devd events. The SIGHUP it sends to amd to tell it the map file was updated does not cause problems, only a SIGKILL may cause the freeze. Nothing was mounted (by amd) during the last freeze. amd itself is a primitive NFS server as far as system is concerned and amd mount points are mounted from it. If you just KILL it without giving it a chance to clean things up you'll potentially end up in a situation similar to mounting from remote NFS server that's unresponsive. From mount_nfs(8): If the server becomes unresponsive while an NFS file system is mounted, any new or outstanding file operations on that file system will hang uninterruptibly until the server comes back. To modify this default be- haviour, see the intr and soft options. I don't see any angle to tackle this, but I'm throwing it out here any way, in the hopes that someone actually has an idea how to approach the issue. Don't use KILL or make sure that nobody tries to use amd mountpoints until new instance starts. Manually unmounting them before killing amd may help. Why not let amd do it itself with /etc/rc.d/amd stop ? --Artem # uname -a FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r253413: Wed Jul 17 13:12:46 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-91/amd64/usr/src/sys/HP6510b-91 amd64 That's amd's starting message: Jul 22 11:32:28 mobileKamikaze amd[8176]/info: no logfile defined; using stderr Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AM-UTILS VERSION INFORMATION: Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1997-2006 Erez Zadok Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 Jan-Simon Pendry Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 Imperial College of Science, Technology Medicine Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Copyright (c) 1990 The Regents of the University of California. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: am-utils version 6.1.5 (build 901505). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Report bugs to https://bugzilla.am-utils.org/ or am-ut...@am-utils.org. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Configured by David O'Brien obr...@freebsd.org on date 4-December-2007 PST. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Built by root@mobileKamikaze.norad. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: cpu=amd64 (little-endian), arch=amd64, karch=amd64. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: full_os=freebsd9.2, os=freebsd9, osver=9.2, vendor=undermydesk, distro=The FreeBSD Project. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: domain=norad, host=mobileKamikaze, hostd=mobileKamikaze.norad. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Map support for: root, passwd, union, nis, ndbm, file, exec, error. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, ufs, cdfs, Jul 22 11:32:28 mobileKamikaze amd[8176]/info:pcfs, auto, direct, toplvl, error, inherit. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: FS: cd9660, nfs, nfs3, nullfs, msdosfs, ufs, unionfs. Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 1: wire=192.168.1.0 (netnumber=192.168.1). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: Network 2: wire=192.168.0.0 (netnumber=192.168). Jul 22 11:32:28 mobileKamikaze amd[8176]/info: My ip addr is 127.0.0.1 amd is called with the flags -r -p -a -c 4 -w 2 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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
FreeBSD LVS replacement
Hello, I'm looking for a functional FreeBSD replacement of the Linux LVS software? There is an LVS port for FreeBSD but it looks deat since 2005. Is there anything comparable or better? All best, mjb ___ 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 LVS replacement
On 07/22/2013 2:13 pm, Maciej Jan Broniarz wrote: Hello, I'm looking for a functional FreeBSD replacement of the Linux LVS software? There is an LVS port for FreeBSD but it looks deat since 2005. Is there anything comparable or better? All best, mjb ___ 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 Perhaps CARP is what you are looking for http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/carp.html -- Thanks, Dean E. Weimer http://www.dweimer.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: FreeBSD LVS replacement
On Mon, Jul 22, 2013 at 12:47 PM, dweimer dwei...@dweimer.net wrote: Perhaps CARP is what you are looking for http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/carp.html Not even remotely close to the same thing. LVS is a kernel level load balancer/director. Combined with some userspace to keep the table of live real servers up to date it makes a very robust, very high speed load balancer for HTTP and non HTTP applications. IDK of any kernel side stuff in FreeBSD, and I don't know that there are any general purpose replacements like LVS is but for HTTP - varnish, nginx, and HAProxy. HAProxy can also do things other than HTTP. But these are all user space proxies. Not lower level like LVS where it doe packet rewriting/NAT. -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ 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 LVS replacement
Hi Maciej, you may also want to take a look at the OpenBSD relayd port (net/relayd). Cheers, mm On 2013-07-22 21:13, Maciej Jan Broniarz wrote: Hello, I'm looking for a functional FreeBSD replacement of the Linux LVS software? There is an LVS port for FreeBSD but it looks deat since 2005. Is there anything comparable or better? All best, mjb ___ 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: FreeBSD LVS replacement
On 22 Jul 2013, at 20:54, Michael Loftis mlof...@wgops.com wrote: On Mon, Jul 22, 2013 at 12:47 PM, dweimer dwei...@dweimer.net wrote: Perhaps CARP is what you are looking for http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/carp.html Not even remotely close to the same thing. LVS is a kernel level load balancer/director. Combined with some userspace to keep the table of live real servers up to date it makes a very robust, very high speed load balancer for HTTP and non HTTP applications. IDK of any kernel side stuff in FreeBSD, and I don't know that there are any general purpose replacements like LVS is but for HTTP - varnish, nginx, and HAProxy. HAProxy can also do things other than HTTP. But these are all user space proxies. Not lower level like LVS where it doe packet rewriting/NAT. The combination of FreeBSD pf and the FreeBSD port of relayd should buy you what you're looking for. I believe the FreeBSD version of pf and relayd are close enough to the following tutorial assumptions. https://calomel.org/relayd.html You can drop CARP into the mix to get redundancy for the load balancer itself, i.e as a pair. To be honest, it's simpler to just install a pfsense installation for the whole package though. - Mark ___ 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 and PERC H200
I got a Dell T110-II server on 2013-July-19. It has two 1Tbyte drives that the PERC H200 controls, RAID 1. I tried to install FreeBSD-9.1-RELEASE from a DVD from FreebsdMall. The autopart segfaulted, evidently because it could not find any disks. I think there is a PR about the segfaulting (bad bug, no messages). I worked around the problem by going to the loader prompt when the initial boot choice screen came up; it's option 2. I gave the commands: load mps.ko boot Install went fine. I had to create (last bsdinstall screen, shell option) the file /boot/loader.conf, containing the single line: mps_load=YES The system boots, and seems to be OK. The 9.1-Release kernel does not contain the mps module, so the above installs it, and the probe finds it as it should. I hope this helps. Karl Dunn kd...@acm.org For reference, this message was the last of a thread posted 2012-May-21: Message: 5 Date: Mon, 21 May 2012 14:27:50 -0500 From: Efra?n D?ctor efraindec...@motumweb.com Subject: Re: FreeBSD 9 and PERC H200 To: freebsd-stable@freebsd.org Cc: Ollivier Robert robe...@keltia.net Message-ID: 2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC Content-Type: text/plain; format=flowed; charset=UTF-8; reply-type=original -Mensaje original- From: Ollivier Robert Sent: Monday, May 21, 2012 10:53 AM To: Efra??n D??ctor Cc: Ollivier Robert ; freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 and PERC H200 Le 21 mai 2012 ?? 16:51, Efra??n D??ctor efraindec...@motumweb.com a ??crit Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is compatible with PERC H200?. It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should work -Mensaje original- Cool, I'll give it a try. Thank you so much. ___ 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 and PERC H200
mps has been in FreeBSD for years surely older than 9.1 are you sure you have a generic kernel? Regards Steve - Original Message - From: Karl Dunn kd...@acm.org To: freebsd-stable@freebsd.org Sent: Monday, July 22, 2013 11:22 PM Subject: Re: FreeBSD 9 and PERC H200 I got a Dell T110-II server on 2013-July-19. It has two 1Tbyte drives that the PERC H200 controls, RAID 1. I tried to install FreeBSD-9.1-RELEASE from a DVD from FreebsdMall. The autopart segfaulted, evidently because it could not find any disks. I think there is a PR about the segfaulting (bad bug, no messages). I worked around the problem by going to the loader prompt when the initial boot choice screen came up; it's option 2. I gave the commands: load mps.ko boot Install went fine. I had to create (last bsdinstall screen, shell option) the file /boot/loader.conf, containing the single line: mps_load=YES The system boots, and seems to be OK. The 9.1-Release kernel does not contain the mps module, so the above installs it, and the probe finds it as it should. I hope this helps. Karl Dunn kd...@acm.org For reference, this message was the last of a thread posted 2012-May-21: Message: 5 Date: Mon, 21 May 2012 14:27:50 -0500 From: Efra?n D?ctor efraindec...@motumweb.com Subject: Re: FreeBSD 9 and PERC H200 To: freebsd-stable@freebsd.org Cc: Ollivier Robert robe...@keltia.net Message-ID: 2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC Content-Type: text/plain; format=flowed; charset=UTF-8; reply-type=original -Mensaje original- From: Ollivier Robert Sent: Monday, May 21, 2012 10:53 AM To: Efra??n D??ctor Cc: Ollivier Robert ; freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 and PERC H200 Le 21 mai 2012 ?? 16:51, Efra??n D??ctor efraindec...@motumweb.com a ??crit Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is compatible with PERC H200?. It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should work -Mensaje original- Cool, I'll give it a try. Thank you so much. ___ 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 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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 and PERC H200
On 22/07/2013 23:35, Steven Hartland wrote: mps has been in FreeBSD for years surely older than 9.1 are you sure you have a generic kernel? Regards Steve Its certainly in GENERIC for 9.1-RELEASE in amd64 http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808view=markup but not in the i386 GENERIC http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808view=markup as per the svn log http://svnweb.freebsd.org/base?view=revisionrevision=212420 Vince - Original Message - From: Karl Dunn kd...@acm.org To: freebsd-stable@freebsd.org Sent: Monday, July 22, 2013 11:22 PM Subject: Re: FreeBSD 9 and PERC H200 I got a Dell T110-II server on 2013-July-19. It has two 1Tbyte drives that the PERC H200 controls, RAID 1. I tried to install FreeBSD-9.1-RELEASE from a DVD from FreebsdMall. The autopart segfaulted, evidently because it could not find any disks. I think there is a PR about the segfaulting (bad bug, no messages). I worked around the problem by going to the loader prompt when the initial boot choice screen came up; it's option 2. I gave the commands: load mps.ko boot Install went fine. I had to create (last bsdinstall screen, shell option) the file /boot/loader.conf, containing the single line: mps_load=YES The system boots, and seems to be OK. The 9.1-Release kernel does not contain the mps module, so the above installs it, and the probe finds it as it should. I hope this helps. Karl Dunn kd...@acm.org For reference, this message was the last of a thread posted 2012-May-21: Message: 5 Date: Mon, 21 May 2012 14:27:50 -0500 From: Efra?n D?ctor efraindec...@motumweb.com Subject: Re: FreeBSD 9 and PERC H200 To: freebsd-stable@freebsd.org Cc: Ollivier Robert robe...@keltia.net Message-ID: 2C8021092BC947138DAE0EADF1A2C0BB@CMOTUM25PC Content-Type: text/plain; format=flowed; charset=UTF-8; reply-type=original -Mensaje original- From: Ollivier Robert Sent: Monday, May 21, 2012 10:53 AM To: Efra??n D??ctor Cc: Ollivier Robert ; freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 and PERC H200 Le 21 mai 2012 ?? 16:51, Efra??n D??ctor efraindec...@motumweb.com a ??crit Thanks for your answer, does anyone know if FreeBSD 8.3-RELEASE is compatible with PERC H200?. It has been merge to stable/8 after 8.2-RELEASE so yes, mpt in 8.3 should work -Mensaje original- Cool, I'll give it a try. Thank you so much. ___ 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 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: FreeBSD 9 and PERC H200
- Original Message - From: Vincent Hoffman vi...@unsane.co.uk On 22/07/2013 23:35, Steven Hartland wrote: mps has been in FreeBSD for years surely older than 9.1 are you sure you have a generic kernel? Regards Steve Its certainly in GENERIC for 9.1-RELEASE in amd64 http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808view=markup but not in the i386 GENERIC http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808view=markup as per the svn log http://svnweb.freebsd.org/base?view=revisionrevision=212420 Ahh I never user i386 ;-) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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 and PERC H200
On Tue, 23 Jul 2013, Steven Hartland wrote: - Original Message - From: Vincent Hoffman vi...@unsane.co.uk On 22/07/2013 23:35, Steven Hartland wrote: mps has been in FreeBSD for years surely older than 9.1 are you sure you have a generic kernel? Regards Steve Its certainly in GENERIC for 9.1-RELEASE in amd64 http://svnweb.freebsd.org/base/release/9.1.0/sys/amd64/conf/GENERIC?revision=243808view=markup but not in the i386 GENERIC http://svnweb.freebsd.org/base/release/9.1.0/sys/i386/conf/GENERIC?revision=243808view=markup as per the svn log http://svnweb.freebsd.org/base?view=revisionrevision=212420 Ahh I never user i386 ;-) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. Indeed: root@newserver#/root(1)# uname -a FreeBSD newserver.kad-hg.org 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Thanks for the clarification. I didn't try 9.1-release amd64. I have no intention of using amd64 because of past trouble with alignment in some ports. No need anyway: I am using 8.1-release i386 on our current T105, and am essentially going to clone all the functionality for the T110, and then abandon the T105. I am about halfway through that effort so far, no trouble at all. It will serve a LAN with about 20 clients. The T105 is hardly loaded at all; the T110 is replacing it for two reasons: T105 is six years old and has had two major failures recently (PS quit, and a drive wore out); needed more HD space. So bought a new machine. I do run 8.2-release amd64 on my laptop - a Dell E6520. Nice. Karl Dunn kd...@acm.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
kern.geom.conftxt broken in the presence of geom_raid
I am trying to write a script which generates a list of devices to install on (hopefully with some vaguely descriptive message next to it) and I noticed that kern.geom.conftxt is mangled when there is a graid volume present, eg.. root@test92:/root # sysctl kern.geom.conftxt | less kern.geom.conftxt: 0 DISK ada2 500107862016 512 hd 16 sc 63 1 RAID raid/r0 500104691712 512(null)descrIntel RAID1 volume/descr (null)LabelVolume0/Label (null)RAIDLevelRAID1/RAIDLevel (null)TransformationRAID1/Transformation (null)Components2/Components (null)Strip65536/Strip (null)StateOPTIMAL/State (null)DirtyNo/Dirty (null)Subdisksada1 (ACTIVE), ada2 (ACTIVE)/Subdisks 2 PART raid/r0p6 471372660736 512 i 6 o 27917370368 ty freebsd-ufs xs GPT xt 516e7cb6-6ecf-11d6-8ff8-00022d09712b 3 LABEL gptid/821a18d0-efb3-11e2-855b-002590d071b5 471372660736 512 i 0 o 0 3 LABEL ufsid/51e7fdbd167c3fbb 471372660736 512 i 0 o 0 2 PART raid/r0p5 21474836480 512 i 5 o 6442533888 ty freebsd-ufs xs GPT xt 516e7cb6-6ecf-11d6-8ff8-00022d09712b It looks like the config tag has been pushed in where it shouldn't be. So, I guess I'll have to find some other way to generate my list :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
